Use strace ao reiniciar seu httpd: link
Ele deve informar a você o que o processo está fazendo no período de espera, para que ele possa lhe dar uma pista melhor sobre qual é a causa.
Nós executamos o servidor apache2 com vários sites (cada um tem seu próprio domínio ou subdomínio) usando SSL (também vários certificados no mesmo IP, mas principalmente um certificado asterisco para subdomínios). Agora, estamos com um problema que, quando há mais de 20 a 30 sites individuais por servidor, a reinicialização leva mais de 20 segundos.
Os logs não mostram nada e não sei como descobrir o que demora tanto para reiniciar. Isso pode estar conectado - executar apache2ctl -S também leva aproximadamente o mesmo período de tempo (quando eu corro um reinicio após o outro ou um -s após o outro é rápido < 1s, se eu esperar um minuto ou mais, novamente lento).
Como posso resolver esse problema? Como determinar o que causa essas reinicializações lentas (precisamos reiniciar quando adicionamos novos sites e está lentamente se tornando incontrolável).
- Atualizar -
Então, depois de todo esse tempo, isso ainda é um problema.
Houve algumas mudanças que podem me apontar na direção certa:
Um dos servidores, de repente, começou a trabalhar tão rápido quanto eu esperava. Não sei por que isso aconteceu, porque eu não posso identificar quando exatamente isso aconteceu. Eu comparei as configurações do apache e eles são praticamente idênticos em todos os servidores, mas um agora é reiniciado rapidamente e outros dois ainda são lentos (> 2min).
Agora, recentemente, quando resolvi alguma coisa, me deparei com alguns comentários sobre a configuração do ipv6, o que diminuiu a emissão de certificados etc. Eu testei a conectividade ipv6 e a única discrepância que encontrei é que em um servidor rápido quando tento isso:
wget -6 https://google.com/
Eu entendo isso:
--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.
Enquanto nos servidores lentos, a mesma solicitação produz isso:
--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]
Então, em outras palavras, parece haver algum problema com o ipv6 que possivelmente causa tempo limite ao tentar reinicializar o apache?
Eu também descobri o seguinte - é um desligamento que leva o tempo todo. Se eu desligar o apache e depois tentar iniciá-lo, a inicialização será rápida.
Para responder a perguntas anteriores:
As cifras são otimizadas (todos os sites obtêm um teste ssl). O tráfego não é ótimo. Aqui está o dump de status do servidor antes de uma reinicialização de 2 min:
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
Por favor avise ...
Use strace ao reiniciar seu httpd: link
Ele deve informar a você o que o processo está fazendo no período de espera, para que ele possa lhe dar uma pista melhor sobre qual é a causa.
A pista IPv4 / IPv6 me remete do problema da glibc no Bug 459756 - a biblioteca de resolução de DNS não parece estar trabalhando de forma confiável
(também RH Knowledgebase DOC-58626, eu não tenho acesso)
Em suma, o RHEL6 (e o Fedora, Centos, Arch) estavam executando a resolução paralela de IPv6 e IPv4 e resultados imprevisíveis, já que a implementação do IPv6 às vezes era menos confiável.
Possíveis soluções alternativas são:
Outros sugeriram strace, mas não preencheram os argumentos mais úteis para começar com o seu problema, ou deram uma estrutura melhor para usar o histórico do shell para reinvocá-lo repetidamente ... o que é bastante comum caso de uso. ;)
Esse processo pode parecer excessivo, mas gosto de fazer tudo para capturar meus dados primeiro quando possível, em vez de descobrir que perdi algo porque tento ir rápido demais para obter uma resposta.
Eu sempre procuro com algo assim (este exemplo é para um daemon chamado "httpd", ajuste conforme necessário):
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
Então, cd para / tmp /. Você pode ter uma tonelada de arquivos "strace. *", Mas provavelmente só está interessado no que foi tocado mais recentemente. Então, um
ls -latr /tmp/
deve informar seus arquivos mais interessantes para inspeção. Procure erros óbvios do sistema, grandes intervalos de tempo ou tempos limite. Diverta-se! :)