Назад | Перейти на главную страницу

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

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

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

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

-- Обновить --

Так что, по прошествии всего этого времени, это все еще проблема.

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

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

Теперь, совсем недавно при устранении неполадок в чем-то еще, я наткнулся на некоторые комментарии о настройке ipv6, замедляющей выдачу определенных сертификатов и т.д.

wget -6 https://google.com/

Я получаю это:

--2017-06-09 07:49:32-- https://google.com/ Resolving google.com (google.com)... 2a00:1450:4009:809::200e Connecting to google.com (google.com)|2a00:1450:4009:809::200e|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYfhKSPR5hfHhPY5mBEsMgNyY24 [following] --2017-06-09 07:49:33-- https://ipv6.google.com/sorry/index?continue=https://google.com/&q=EhAqAX4AAAAAAPA8kf_-iVh9GIym6ckFIhkA8aeDS9iurm4ysYfhKSPR5hfHhPY5mBEsMgNyY24 Resolving ipv6.google.com (ipv6.google.com)... 2a00:1450:401b:802::200e Connecting to ipv6.google.com (ipv6.google.com)|2a00:1450:401b:802::200e|:443... connected. HTTP request sent, awaiting response... 503 Service Unavailable 2017-06-09 07:49:33 ERROR 503: Service Unavailable.

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

--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?

Я также понял следующее - это отключение, которое занимает все время. Если я выключу 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

Пожалуйста, порекомендуйте...

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

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

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

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

  • добавить "варианты единого запроса-повторного открытия" в /etc/resolv.conf. Это заставляет запросы A и AAAA совместно использовать сокет. страница руководства resolv.conf здесь
  • запустить локальный кеширующий сервер имен, например [nscd] (или dnsmasq, не входит в комплект) 3

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

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

Другие предлагали 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/

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