O Apache não está respondendo e nada é registrado após uma curta e strong “onda de tráfego”

Question

Meu apache está atendendo a cerca de 300 solicitações / s (2 megabytes / s) constantemente com uma carga de 0,05 no servidor.

O problema é que minha arquitetura de serviço faz com que o tráfego seja enorme em determinado momento (como 300 a 500 pessoas é redirecionado para uma página com JavaScript em alguns segundos).

Após um salto de tráfego tão curto, o apache deixa de responder (conexão redefinida após cerca de 30 segundos no firefox) sem registrar nada. O Apache é congelado até o procedimento de reinicialização do apache2.

Quando congelado, ele não pode servir até mesmo arquivo HTML simples sem conexão PHP ou SQL (mas existem processos apache2)

Eu tentei diferentes configurações de prefork de 50 para quase 1000 funcionários ociosos e limites máximos de clientes de 10000, mas nada ajuda.

Outro sintoma, além de não registrar nada, é que momentos antes do congelamento, o módulo de status do apache mostra (que da última vez também não responde) que quase todo processo espera por conexão:

__R_R_______R__RR______R___R________________RR_______R______R___
_________R__________R_________________________R________CR___R___
___________R__________________________C__WR__R________________R_

Mas em trabalhos normais e menos laodedados, mostra:

C___R___K_C___C___C_____KK______R___C_C_R______C__K___C________K
____C__KR_RR__C___K___KK_C__R__K__C_CK__RC___CR___R__K__C__R____
___KR____C_____R______R______K__R_______KC__C_K__R____C_______R_

syslog também não dá nada. Minha máquina tem 64GB de RAM e nunca excede a carga de 0,1

    

Answer 1

Acho que quando suas conexões atingem mais de 450 por segundo, isso pode estar relacionado ao fato de que você está ficando sem portas efêmeras no Linux.

Confira esta pergunta respondida

Pequeno resumo da resposta:

sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_fin_timeout

O intervalo de portas ephérmicas define o número máximo de soquetes de saída que um host pode criar a partir de um determinado IP. endereço. O fin_timeout define o tempo mínimo que esses soquetes permanecerão no estado TIME_WAIT (inutilizável depois de ser usado uma vez). Os padrões usuais do sistema são:

net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.tcp_fin_timeout = 60 

Isso basicamente significa que seu sistema não pode garantir mais que (61000 - 32768) / 60 = 470 soquetes a qualquer momento. Se você não está feliz com isso, você pode começar aumentando o port_range. Definir o intervalo para 15000 61000 é bastante comum nos dias de hoje. Você pode aumentar ainda mais a disponibilidade diminuindo o fin_timeout. Suponha que você faça as duas coisas e verá mais de 1500 conexões de saída, mais facilmente.

    

Answer 2

Você pode se conectar ao processo de falta de resposta e ver o que acontece? Pode ser mais fácil se você executar o prefork.

Anexando ao processo usando rastreio

strace -p <pid> -o /tmp/somefile

Você pode querer brincar com -s

-s strsize Specify the maximum string size to print (the default is 32). Note that filenames are not considered strings and are always printed in full.

    

Answer 3

Concordo com o 3molo, o strace pode fornecer uma pista do que está acontecendo, ou seja, se houver chamadas do sistema em espera. A única coisa que eu não achei que seja útil é um problema lento. Correndo

sudo iotop

e

sudo top

Pode dar uma ideia do tipo de atividade de IO que está ocorrendo. O IO lento causou um comportamento similar para mim no passado; como ter que ler muitos arquivos muito pequenos de um NAS lento. Se o top reportar um 'wait' alto e o iotop mostrar uma alta porcentagem de largura de banda, talvez seja necessário aplicar uma solução de armazenamento diferente.

    

Answer 4

Você precisa começar com duas coisas.

1) Defina o nível de log para depurar na configuração do apache. Sempre que você tiver um comportamento problemático, dê uma olhada nos logs de acesso e nos logs de erros.

Aviso: Isso pode encher seu disco rapidamente. Então, retorne da depuração para seu valor original quando tiver informações suficientes.

2) Embora eu concorde com a opção strace sugerida aqui, recomendo que você faça o gdb no processo em execução. Se você quiser mais ajuda sobre como depurar um processo em execução, recomendo que você consulte isso .

    

Answer 5

Soa muito como um limite de descritor de arquivo. Você precisa su para o usuário que o apache executa como e execute isto:

ulimit -n

A configuração padrão em muitas distros parece ser 1024. Se sim, tente subir assim. Você pode alterá-lo em /etc/security/limits.conf em distros baseadas no debian. Digamos que o usuário apache seja executado como é apache , então você pode adicionar isto:

apache soft nofile 65535
apache hard nofile 65535

Você precisará reinicializar para aplicar essa alteração.