Tracking Apache por VirtualHost

Question

Eu tenho um servidor web apache executando muitos VirtualHosts.

Recentemente, tem sido atolado e não responde, e eu estou querendo saber como eu posso determinar quais VirtualHosts estão causando a maior parte do problema. Nós tivemos ocasiões no passado em que um erro no código de um site individual derrubou todo o servidor. Meu objetivo é conseguir diagnosticar essas instâncias rapidamente.

Estou monitorando o servidor com munin e percebo que o número de processos do apache, o uso da memória e a carga tendem a ser muito altos durante os períodos em questão. O problema é que essas estatísticas são para o servidor inteiro, não para VirtualHosts individuais.

Eu escrevi um script para analisar os weblogs do tráfego por VirtualHost , mas está aparecendo que isso não é suficiente. Eu provavelmente preciso determinar quantos processos de apache cada VirtualHost é responsável, ou por quanto tempo eles abrem cada processo - ou talvez quanta memória uso cada é responsável por.

Onde posso encontrar essa informação? Eu não me importo de escrever um script para rastrear esses dados, mas não sei exatamente para onde extraí-los, em primeiro lugar.

    

Answer 1

Eu aprecio que nem sempre seja adequado ter o mod_status disponível e o tempo todo, mas ele e o apachetop são as melhores maneiras de diagnosticar esses problemas. No entanto, existem muitas maneiras de esfolar um gato.

Esse truque é útil em várias circunstâncias e não é específico do Apache. Isso depende de vários fatores, e você precisa saber o que está fazendo para saber suas limitações.

for pid in 'pgrep -u www-data'; do find /proc/${pid}/cwd -printf "%l\n" ; done

Vamos dividi-lo:

• pgrep -u www-data fornece a lista de pids em execução no usuário www-data. Esse é o padrão no Debian / Ubuntu, mude para se adequar ao seu próprio sistema (sistemas baseados em RedHat tendem a usar link , por exemplo, como usuário). Para sistemas sem pgrep, você pode usar ps axuwww | usuário grep | awk '{print $ 2}'
• o * para; Faz; ... loop * done significa que percorremos todas as entradas executando o (s) comando (s) dentro da parte do loop.
• localize / proc / $ {pid} / cwd -printf "% l \ n" simplesmente procura / proc por cada um desses PIDs e cospe o diretório de trabalho atual para aquele processo. O Apache irá chdir () para o VirtualHost por padrão quando servindo arquivos daquele VirtualHost. / proc / PID / cwd é um link simbólico para o diretório no qual o processo apache está sendo executado. o printf "% l \ n" imprime o nó de extremidade para esse link. Veja encontrar (1) para mais informações sobre isso.

Existem duas advertências importantes para esse truque:

1) Se algo rodando sob o mesmo contexto que o processo do Apache faz um chdir () fora do diretório do VirtualHost, seria difícil descobrir isso.

por exemplo. um script PHP sendo executado sob o mod_php (um CGI será diferente, já que o Apache fork é um processo separado, mas estou supondo que CGI não seja um problema ou que você possa rastreá-los mais facilmente).

2) Se você tiver instâncias do Apache, as quais estão muito rapidamente servindo páginas (por exemplo, uma pequena página HTML estática). Isso normalmente não é um problema, mas pode ser possível. Se você está recebendo muitos erros "Nenhum arquivo ou diretório", isso é basicamente uma manifestação disso. Eu esperaria alguns, mas não a maioria, a menos que eles se encaixem nesse caso em particular. Basicamente, isso acontece porque os processos do Apache que você digitalizou com o ps já saíram no momento em que você verificou o / proc. Obviamente, isso significa que eles estão atendendo páginas muito rapidamente.

Com relação aos processos do Apache vinculados à memória, eu uso ps_mem.py para calcular o uso da memória em meus servidores web. Se você tem grandes processos do Apache (em termos de tamanho de memória residente) e eles estão saindo rapidamente, isso é aproximadamente o equivalente a pedir a um cara gordo para continuar executando os sprints de 100m. Se o seu servidor web não for compartilhado, os erros "Não há arquivo ou diretório" são normalmente bons candidatos para mover algum conteúdo para um servidor web menor e leve (por exemplo, nginx / lighttpd) ou iniciar um conteúdo muito cache (por exemplo, verniz / squid).

    

Answer 2

Eu acho que você quer apachetop, ou então mod_status (com ExtendedStatus On ). Ainda estou para ter um problema de desempenho no Apache que não foi iluminado por mod_status e apachetop parece uma ferramenta limpa (que tem algumas limitações irritantes no layout do log).