Медленный перезапуск Apache2 с SSL

Мы запускаем сервер apache2 с несколькими сайтами (каждый имеет собственный домен или субдомен), используя SSL (также несколько сертификатов на одном IP, но в основном сертификат звездочки для субдоменов). Теперь у нас возникла проблема, когда на каждом сервере более 20-30 отдельных сайтов, перезапуск занимает более 20 секунд.

Журналы ничего не показывают, и я не знаю, как понять, почему перезапуск занимает столько времени. Это может быть связано - запуск apache2ctl -S также занимает примерно такое же количество времени (когда я запускаю один перезапуск за другим или один -S за другим, он быстро <1 с, если я подожду минуту или около того, он снова медленно).

Как решить эту проблему? Как определить причину этих медленных перезапусков (нам нужно перезапускать, когда мы добавляем новые сайты, и они постепенно становятся неуправляемыми).

- Обновление -

Итак, спустя все это время, это все еще проблема.

Произошли некоторые изменения, которые могут указать мне правильное направление:

Один из серверов внезапно начал работать так быстро, как я ожидал. Не знаю, почему это произошло, поскольку я не могу определить, когда именно это произошло. Я сравнил конфигурации apache, и они практически идентичны на всех серверах, но один теперь перезагружается быстро, а два других все еще работают медленно (> 2 мин.).

Недавно, при устранении других неполадок, я наткнулся на несколько комментариев о замедлении настройки ipv6 выдача определенного сертификата и т. д. Я протестировал подключение по протоколу ipv6 и обнаружил только одно несоответствие: на быстром сервере, когда я пробую это:

wget -6 https://google.com/

, я получаю следующее:

--2017-06-09 07: 49: 32-- https://google.com/ Разрешение google.com (google.com) ... 2a00: 1450: 4009: 809 :: 200e Подключение к google.com (google.com) | 2a00: 1450: 4009: 809 :: 200e |: 443 ... подключено. HTTP-запрос отправлен, ожидает ответа ... 302 Найдено Расположение: https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYfhKSPR5hfHhPY5mBEsMgNyY24 [follow] --2017-06-09 07:49:33 - https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYNyfhKSPR5hfHhhPY5m Разрешение ipv6.google.com (ipv6.google.com) ... 2a00: 1450: 401b: 802 :: 200e Подключение к ipv6.google.com (ipv6.google.com) | 2a00: 1450: 401b: 802 :: 200e |: 443 ... подключено. HTTP-запрос отправлен, ожидает ответа ... 503 Служба недоступна 2017-06-09 07:49:33 ОШИБКА 503: Служба недоступна.

В то время как на медленных серверах тот же запрос дает следующее:

--2017-06-09 07:50:37--  https://google.com/
Resolving google.com (google.com)... 2404:6800:4003:802::200e
Connecting to google.com (google.com)|2404:6800:4003:802::200e|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.google.com/ [following]
--2017-06-09 07:50:37--  https://www.google.com/
Resolving www.google.com (www.google.com)... 2404:6800:4001:80b::2004
Connecting to www.google.com (www.google.com)|2404:6800:4001:80b::2004|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html'
[ <=>    ] 10,382      --.-K/s   in 0.001s

2017-06-09 07:50:37 (18.4 MB/s) - 'index.html' saved [10382]

Другими словами, похоже, есть некоторая проблема с ipv6, которая может вызывать тайм-аут при попытке перезагрузить апач?

Я также понял следующее - это отключение, которое занимает все время. Если я выключу apache, а затем попытаюсь запустить его, запуск будет быстрым.

Чтобы ответить на предыдущие вопросы:

Шифры оптимизированы (все сайты получают A по ssl-тесту). Трафик не большой. Вот дамп состояния сервера перед двухминутным перезапуском:

Apache Server Status for s3.example.com (via 0.0.0.0)

Server Version: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.21 OpenSSL/1.0.1f
Server MPM: prefork
Server Built: May 9 2017 16:14:10

Current Time: Friday, 09-Jun-2017 08:05:46 UTC
Restart Time: Friday, 09-Jun-2017 07:57:35 UTC
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 8 minutes 10 seconds
Server load: 0.00 0.00 0.00
Total accesses: 15 - Total Traffic: 23 kB
CPU Usage: u0 s0 cu0 cs0
.0306 requests/sec - 48 B/second - 1570 B/request
1 requests currently being processed, 7 idle workers

____W___........................................................
................................................................
......................

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Srv PID Acc M   CPU     SS  Req Conn    Child   Slot    Client  VHost   Request
0-0 11047   0/2/2   _   0.00    456 0   0.0 0.00    0.00    77.0.0.0    s3.example.com:80   NULL
2-0 11049   0/3/3   _   0.00    219 0   0.0 0.00    0.00    127.0.0.1   s3.example.com:80   GET /server-status?auto HTTP/1.1
4-0 11051   0/7/7   W   0.00    0   0   0.0 0.01    0.01    77.0.0.0    s3.example.com:443  GET /server-status HTTP/1.1
6-0 11166   0/2/2   _   0.00    35  0   0.0 0.00    0.00    127.0.0.1   s3.example.com:443  \x16\x03\x01
7-0 11167   0/1/1   _   0.00    333 1   0.0 0.00    0.00    77.0.0.0    s3.example.com:443  NULL
Srv Child Server number - generation
PID OS process ID
Acc Number of accesses this connection / this child / this slot
M   Mode of operation
CPU CPU usage, number of seconds
SS  Seconds since beginning of most recent request
Req Milliseconds required to process most recent request
Conn    Kilobytes transferred this connection
Child   Megabytes transferred this child
Slot    Total megabytes transferred this slot
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 0
subcaches: 32, indexes per subcache: 88
index usage: 0%, cache usage: 0%
total entries stored since starting: 0
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 0
total retrieves since starting: 0 hit, 1 miss
total removes since starting: 0 hit, 0 miss
Apache/2.4.7 (Ubuntu) Server at s3.example.com Port 443

Пожалуйста, сообщите ...

2
задан 9 June 2017 в 11:07
3 ответа

Используйте strace при перезапуске httpd: http://man7.org/linux/man-pages/man1/strace.1.html

Он должен сообщить вам, что процесс делает в ожидании период, так что это может дать вам лучшее представление о том, в чем причина.

2
ответ дан 3 December 2019 в 09:59

Подсказка IPv4 / IPv6 напоминает мне о проблеме glibc в Ошибка 459756 - Библиотека преобразователя DNS, похоже, не работает надежно

(также база знаний RH DOC-58626, у меня нет доступа)

Короче говоря, RHEL6 (и Fedora, Centos, Arch) выполняли параллельное разрешение IPv6 и IPv4 DNS и получали непредсказуемые результаты, поскольку развертывание IPv6 иногда было менее надежным.

Возможные обходные пути:

  • добавить «параметры однократное открытие-повторное открытие» в /etc/resolv.conf . Это заставляет запросы A и AAAA совместно использовать сокет. справочная страница resolv.conf здесь
  • запускает локальный кэширующий сервер имен, например [nscd] (или dnsmasq, не входит в комплект) 3
2
ответ дан 3 December 2019 в 09:59

Другие предлагали strace, но не приводили наиболее полезных аргументов, с которых можно было бы начать, учитывая вашу проблему, или не дали более удобную структуру для использования истории оболочки, чтобы повторно вызывать ее снова и снова. .. что довольно распространенный вариант использования. ;)

Этот процесс может показаться чрезмерным, но мне нравится делать все, чтобы сначала собрать мои данные, когда это возможно, а не итеративно выяснять, что я что-то пропустил, потому что я стараюсь действовать слишком быстро, чтобы получить ответ.

Я всегда использую что-то вроде этого (этот пример для демона с именем "httpd", при необходимости настройте):

daemon="httpd"; rm /tmp/strace.* ; service $daemon restart ; (strace -v -a 40 -f -ff -tt -yy -s 128000 -o /tmp/strace -p "`pidof $daemon`" & ) && sleep 1 && service $daemon restart

Затем перейдите в / tmp /. У вас может быть куча файлов "strace. *", Но на самом деле вас, скорее всего, интересуют только те, к которым вы недавно прикасались. Итак,

ls -latr /tmp/

должен указать вам самые интересные файлы для проверки. Ищите очевидные системные ошибки, большие промежутки времени или таймауты. Радоваться, веселиться! :)

0
ответ дан 3 December 2019 в 09:59

Теги

Похожие вопросы