Como depurar um erro de tempo limite do apache?

Question

Não tenho certeza se essa pergunta pertence ao ServerFault ou ao StackOverflow, mas como acredito que preciso depurar esse problema no servidor, vou com o ServerFault.

O problema

Estamos executando um servidor de hospedagem compartilhado para alguns de nossos clientes. Tudo está correndo bem, exceto por um cliente seu site. Cerca de 2 a 3 dias por semana, nosso monitor detecta um breve tempo de inatividade porque o apache não está veiculando a página em 30 segundos, mas sim entre 60 e 120 segundos. Eu verifiquei uma vez com a minha própria área de trabalho para confirmar: o site continuou carregando por 80 segundos e, em seguida, de repente carrega. Não há aumento de carga, não há mais solicitações do que o normal e os outros sites no servidor carregam perfeitamente.

Tivemos problemas com um plug-in específico anteriormente: esse plug-in entrou em contato com o servidor do autor para confirmar a chave de licença. Quando este servidor não estava acessível, o Wordpress não pôde continuar carregando e teve os mesmos sintomas de agora. Percebemos isso porque um dia seu servidor ficou inativo por algumas horas e tivemos tempo para desativar e ativar todos os plugins, um por um. De acordo com o autor do plugin, os problemas foram resolvidos agora.

Tenho a strong impressão de que estamos olhando para o mesmo problema novamente, talvez com o mesmo plugin e talvez não. Mas como o tempo de inatividade é tão breve (geralmente não mais que 2 minutos), não tenho idéia de como depurar esse erro de tempo limite.

Coisas que pensei em

Normalmente eu desabilitava os plugins um por um, mas antes de me conectar ao banco de dados para desativar os plugins, o site voltava a funcionar. Como não há padrão no tempo de inatividade, não posso ficar em espera quando isso acontece. Os logs do Apache não mostram nenhum erro: só consigo ver a solicitação dos usuários e ver que não há arquivos servidos por algum tempo.

Meu segundo pensamento foi executar um stacktrace no processo do apache. Tenho certeza que isso revelaria onde o Apache está esperando por tanto tempo. Mas como o servidor está recebendo mais de 30 solicitações por minuto, o arquivo de registro se tornaria muito grande em algumas horas, o que impossibilitaria que encontrássemos as solicitações certas.

Especificações relevantes do servidor

CentOS Linux release 7.0.1406 (Core)
Kernel 3.10.0-123.el7.x86_64

Apache/2.4.12 with mod_ruid2
PHP 5.4.38 (cli)
mysql Ver 15.1 Distrib 5.5.41-MariaDB, for Linux (x86_64) using readline 5.1

All compiled by DirectAdmin 1.48.3

Idéias?

Quem poderia pensar em uma boa maneira de depurar esse problema específico? Qualquer ajuda é muito apreciada!

EDITAR:

• O log de consultas lentas não relata nenhuma consulta lenta durante as solicitações lentas.

Answer 1

Como mencionei, suspeitamos que um dos plug-ins foi a causa do problema em questão. Anteriormente, quando o servidor de licenças estava inoperante, nosso site também estava indisponível. Eles afirmaram que esse problema foi corrigido com uma de suas últimas atualizações, mas como estamos tendo muito tempo de inatividade, eu duvidei disso.

Eventualmente, depuramos da seguinte maneira:

• Fizemos uma solicitação normal, ver como a página é carregada.
• Se esse plug-in fosse o problema, provavelmente entraria em contato com o servidor de licenças via porta TCP 80. Não pensamos nisso antes, mas isso foi o suficiente para nós: bloqueamos essa porta nas tabelas de IP para simule um tempo limite no servidor de licenças (certifique-se de colocar a lista de permissões em 127.0.0.1 nas tabelas de IP, para que não fique um bloqueio permanente) .
• Fizemos um strace novamente e carregamos a página: desta vez, ela não carregou e ficou presa. Fechamos a faixa depois de alguns segundos e visualizamos o arquivo.

A última linha do strace era uma carga do arquivo: /wp-content/plugins/[plugin-name]/[file-of-plugin].php. O Apache não pôde passar este plugin, até que nós desbloqueamos a porta 80 novamente.

Nós excluímos o plug-in e não tivemos nenhum tempo de inatividade desde então. É um problema muito raro, mas espero que minha resposta possa ser útil se alguém estiver passando pelo mesmo problema.

Obrigado por todos os comentários e respostas. Nós realmente apreciamos, isso realmente nos ajudou a pensar em uma solução.

    

Answer 2

Se o Apache ainda estiver acessível, eu pegaria primeiro a página de status estendida para ver quais solicitações estão sendo exibidas agora. Se houver uma solicitação de execução longa, você pode até tentar, pid deve estar visível em status (já que você tem mod_ruid2, acho que você roda o mod_php e prefork MPM, então um processo serviria apenas uma única requisição por vez).

Talvez reconfigure o Customlog e registre o tempo gasto para atender à solicitação, para que mais tarde você possa identificar as solicitações lentas.

Depois de ter as solicitações lentas, veja se pode ser reproduzido. Se sim, então é mais fácil depurar, você pode até adicionar o xdebug para a depuração / depuração do PHP.

Veja também o que as consultas do MySQL estão executando no momento do bloqueio, talvez seja um problema de consulta / bloqueio lento do MySQL.

Também pode ser um problema da API da rede, como você disse.

E quando você ficar sem todas as opções, talvez apenas fale com o chefe e chute o usuário. Dependendo de quantos outros sites estão no servidor, a integridade do servidor pode ser mais importante do que o próprio site.