Picos de memória do Apache, possíveis causas?

Question

Na última sexta-feira (10/7/2011), começamos a ter os processos httpd.worker crescendo a partir do memória típica de 10-15M reservada para 10G + (gigabytes) em questão de 1-2 minutos. Isso obviamente faz com que o servidor pare quando ele inicia a troca, etc. Temos que reinicializar o servidor para que ele seja executado novamente. Se conseguirmos pegá-lo a tempo, podemos matar o agressor do httpd.worker e tudo ficará bem por enquanto.

Sistema

• RHEL 5.5
• Apache httpd-2.2.3-45.el5_6.2.x86_64.rpm (corrigido para impedir a vulnerabilidade recente do filtro de intervalo de bytes)
• Usando o trabalhador do Apache MPM (não prefork)
• mod_jk 1.2.28
• mod_rewrite
• OpenSSL (versão mais recente do chapéu vermelho)
• Tomcat / JBoss Web 2.1 (JBoss 5.1.0)
• servidores dedicados (não compartilhados), 12 GB de RAM em cada

Sintomas

• Sob carga normal, de repente, um processo httpd.worker crescerá de 10M para vários Gigs na memória reservada. Tem que matar -9 o processo ou então servidor mói até parar
• Ocasionalmente ocorrem vários processos do httpd.worker no mesmo período
• Uma vez que o (s) processo (s) ofensivo (s) tenha sido eliminado, tudo estará normal novamente (questão de minutos).
• Tem acontecido aprox. a cada 8 - 12 horas desde a última sexta-feira, nenhum padrão claro.
• Sem picos no tráfego de solicitações que levam a ele
• Nenhum tráfego / erros estranhos em access_log e error_log

Notas adicionais

• Nossa carga normal é de ~ 5-10 solicitações / seg em cada servidor, não é loucura.
• Nós definimos (depois disso iniciado) MaxRequestsPerChild para 250 e os trabalhadores estão sendo devidamente reciclados. Implica que o problema é de um único ou pequeno conjunto de solicitações
• Não fizemos alterações na configuração do aplicativo / sistema nas últimas duas semanas.
• Como não é um problema constante (desaparece em questão de minutos), não parece um
• Soa exatamente como a vulnerabilidade do filtro de intervalo de bytes, mas corrigimos e testamos esse link (
  • Eu li vários posts sobre falhas no servidor (e em outros lugares), mas não encontrei nenhum que descreva um único processo de trabalho saindo do controle com a memória

Perguntas

• O que pode fazer com que uma memória de processos individuais do httpd.worker fique fora de controle como essa? Ou até mesmo algo além do valor típico (10m-15m para a nossa configuração)?
• Alguma sugestão para solucionar isso? Estamos assistindo top, server-status, jkstatus, monitorando com cactos, temos o monit instalado e estamos recebendo o logging do mod_jk.

Configuração do Apache / mod_jk / Tomcat (JbossWeb)

De httpd.conf ...

<IfModule worker.c> 
StartServers         2 
MaxClients         500 
MinSpareThreads     25 
MaxSpareThreads    150
ThreadsPerChild     50 
MaxRequestsPerChild  250 
</IfModule>

De worker.properties de mod_jk ...

# Define Node1 worker.node1.port=8009
worker.node1.host=127.0.0.1 worker.node1.type=ajp13
worker.node1.lbfactor=1 worker.node1.connection_pool_timeout=60
worker.node1.connection_pool_size=35 worker.node1.connect_timeout=5000
worker.node1.prepost_timeout=5000

do server.xml do tomcat ...

<Connector protocol="AJP/1.3" port="8009"
address="${jboss.bind.address}" redirectPort="8443" maxThreads="350"
connectionTimeout="60000" enableLookups="false"/>

Gostaria de receber qualquer contribuição!

    

Answer 1

Nós oficializamos e corrigimos o problema, foi simplesmente um loop em nossas regras do mod_rewrite. Estivera em vigor há meses, mas ninguém atingiu a URL específica que causou o problema. Portanto, esse é pelo menos um exemplo de alguns que podem fazer com que um único processo httpd.worker saia do controle com o consumo de memória.