Você pode usar o utilitário de depuração "strace" com PIDs que sobrecarregam a CPU para ver a causa. Pode apontar para o problema que tem, strace -p <PID>
Estou executando um servidor WHM / cPanel no CentOS 6.6 com o Apache 2.4 e o PHP 5.5. A cada semana aproximadamente, o uso da CPU chegará a 100% em todos os seis núcleos e permanecerá lá até que o Apache seja reiniciado, quando tudo voltará ao normal. Curiosamente, a página server-status do Apache não parece saber que esses processos existem:
Parte superior:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25901 nobody 20 0 1973m 28m 276 R 74.8 0.4 3:39.30 httpd
24861 nobody 20 0 1973m 28m 280 R 74.1 0.4 12:05.31 httpd
25076 nobody 20 0 1973m 28m 276 R 65.8 0.4 10:09.38 httpd
24727 nobody 20 0 1973m 28m 280 R 64.5 0.4 14:37.09 httpd
25874 nobody 20 0 1973m 28m 276 R 64.5 0.4 3:57.69 httpd
24747 nobody 20 0 1973m 28m 276 R 64.1 0.4 15:06.89 httpd
25998 nobody 20 0 1973m 28m 276 R 63.8 0.4 2:40.92 httpd
25624 nobody 20 0 1973m 28m 276 R 61.8 0.4 5:28.76 httpd
25646 nobody 20 0 1973m 28m 276 R 58.8 0.4 5:07.88 httpd
página de status:
Server Version: Apache/2.4.12 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Server MPM: event
Server Built: Mar 27 2015 11:20:11
Current Time: Tuesday, 09-Jun-2015 09:21:07 CDT
Restart Time: Tuesday, 02-Jun-2015 11:38:37 CDT
Parent Server Config. Generation: 12
Parent Server MPM Generation: 11
Server uptime: 6 days 21 hours 42 minutes 30 seconds
Server load: 8.17 7.35 10.46
Total accesses: 461541 - Total Traffic: 10.7 GB
CPU Usage: u111.81 s369.94 cu305989 cs438.15 - 51.4% CPU load
.774 requests/sec - 18.7 kB/second - 24.2 kB/request
7 requests currently being processed, 118 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
21715 1 yes 1 24 0 1 0
4766 0 yes 0 25 0 0 0
10222 0 yes 0 25 0 0 0
10278 6 yes 6 19 0 0 0
10194 0 yes 0 25 0 0 0
Sum 7 7 118 0 1 0
_____________________W__________________________________________
_____________W__W____W____W_W___W___.........................___
______________________
Nenhuma das solicitações relatadas pela página de status do Apache parece ser de algum interesse, o que faz sentido, já que nenhum dos PIDs que consomem CPU está listado. O uso de memória, a E / S de disco e o tráfego de rede permanecem relativamente estáveis e o problema não aparece em uma hora do dia consistente. Existem dezenas de sites pequenos neste servidor, o que dificultaria a pesquisa nos logs de acesso manualmente.
O que poderia estar causando isso? Eu estou apenas entendendo mal a maneira como o Apache relata dados? Existe uma maneira melhor de rastrear o processo responsável e ver o que ele está realmente fazendo?
Você pode usar o utilitário de depuração "strace" com PIDs que sobrecarregam a CPU para ver a causa. Pode apontar para o problema que tem, strace -p <PID>
Existem duas causas possíveis:
Backups - o processo de backup do cPanel é um pouco pesado, então primeiro verifique se o carregamento do Apache começa segundos / minutos após o início do processo de backup.
Atualizações maciças - mais prováveis; a cada dia e semana, o cPanel baixa um grande número de atualizações e verificações diferentes e, durante as atualizações, executa muitos programas estranhos, internos e pesados, incluindo o verificador de licenças, que às vezes causa problemas para alguns usuários.
Infelizmente, o Apache do cPanel está ligado a scripts cPanel CGI de peso pesado, que fazem algumas partes dessas atualizações e verificações. A partir da minha experiência com o cPanel, aposto que exatamente esses scripts CGI são responsáveis por seus problemas com o Apache, devido a deadlocks causados pela interação entre eles e os trabalhos agendados.
Para verificar essas duas causas, desative tarefas agendadas uma a uma executando root:
crontab -e
Tente desativar apenas um serviço de uma vez e aguarde uma semana, até que você veja o próximo uso de CPU alto ou encontre um problema problemático.
Já tentou definir LogLevel debug e verificar {access, error} _log files para quaisquer sugestões?
Recentemente, eu tive que depurar algo no apache2 também. O que me ajudou foi parar o serviço apache2 e iniciá-lo manualmente usando:
# strace -f -s 1024 -o /tmp/httpd.strace /usr/local/apache/bin/httpd -k start -DSSL -X
Eu peguei a linha de comando completa do seu JSFiddle e apenas adicionei a opção -X para ativar o modo de depuração.
Quando atingir a mesma situação, você poderá ver /tmp/httpd.strace para dicas. Pode ser útil usar strace-graph /tmp/httpd.strace para ver quais subprocessos foram invocados durante a execução de strace .
use os PPIDs dos processos errados para rastrear o pai. Eu suspeito que você tenha dois daemons apache diferentes em execução. Parece provável que o CPanel possa fazer isso para poder fazer as coisas como root, mas percebo que os processos não são do usuário. Talvez você tenha um apache leve que lide com pedidos de recebimento e os transmita para um segundo apache executando processos mod_php mais pesados? Talvez haja algo mais acontecendo, mas sua primeira tarefa é descobrir quais são esses processos do apache. Você consegue ver duas configurações apache separadas?
lsof pode ser útil. Você obteria informações como quais arquivos de log estão abertos por um determinado processo do apache e em quais números de porta ele está escutando.
Supondo que estou certo em ouvir provavelmente em uma porta diferente, pode ser útil configurar algo para capturar o tráfego nessa porta, para que você possa ver o que aciona a situação de alta CPU. As chances são de que não é grande coisa apenas deixar o tcpdump escrevendo todo esse tráfego para o arquivo, embora você deva estar monitorando o espaço em disco apenas no caso de ser inesperadamente grande.
É interessante que você reinicie o apache parece funcionar. Talvez eu esteja errado sobre haver dois apaches, ou talvez possa haver solicitações sendo encaminhadas entre as instâncias do apache.
sudo netstat -plnt pode ser interessante. Ele mostrará a você quais processos e pids estão associados a cada porta de escuta. Se houver dois apaches, você os encontrará lá. ps wwuaxf ou pstree também mostrará os processos do apache agrupados pelo processo pai. Você veria os argumentos da linha de comando
EDIT: extra após comentário do OP.
Filhos do processo init são instâncias apache separadas em execução ou, talvez, processos zumbis que, por algum motivo, não estão sendo coletados. Nesse caso, o processo pai morreu, mas as crianças não puderam ser interrompidas e foram movidas para o processo init como pai.
A alta cpu pode ser algo como tentativas repetidas de falar com o processo pai ausente, embora nesse caso presumivelmente aparecesse com strace. Eu observaria de perto o que acontece quando o apache é reiniciado.
Alguns processos antigos estão sendo executados? Você tem um bom registro de quando a alta CPU entra em ação? (talvez use sar, munin e kSar é bom com sar, que de outra forma tem apenas tabelas de texto como saída). Você pode correlacionar isso com quando o apache é reiniciado? (Por exemplo, roll-over de registro noturno ou ações manuais). Talvez você consiga identificar uma conexão quando algo acontecer em seu sistema. Se está acontecendo ao mesmo tempo, isso é muito útil para rastrear as coisas.
Tags apache-2.4