Entendendo este erro: apr_socket_recv: Redefinição de conexão pelo ponto (104)

Portanto, se eu fizer algum teste comparativo com o apache benchmark (ab) e usar um grande número de solicitações. Às vezes, no meio de um teste, recebo esse erro.

Eu nem sei o que isso significa. Então, como posso corrigir isso? Ou é apenas algo que acontecerá se o servidor receber muitos hits de qualquer maneira? O problema é que, se eu executar 10.000 hits, tudo funcionará perfeitamente. Se eu executá-lo novamente, chegará a 4000 e receberá o erro:

apr_socket_recv: Connection reset by peer (104)

Um pouco sobre minha configuração: tenho o nginx recebendo solicitações estáticas e processando solicitações dinâmicas para o apache. O arquivo em questão é fornecido pelo cache pelo nginx, então acho que provavelmente tem a ver com o modo como o nginx está lidando com as solicitações?

Ideias?

O erro significa que a outra extremidade (servidor da web) se desconectou subitamente no meio da sessão. dê uma olhada nos logs de erro apache ou nginx para ver se há algo suspeito lá.

Isso significa que o servidor está muito carregado com a solicitação, ou seja, todos os threads estão ocupados atendendo a solicitação. Solução: aumente a contagem de atributos maxThread para o conector no arquivo server.xml ou aumente o valor do atributo acceptCount.

acceptcount: o comprimento máximo da fila para solicitações de conexão recebidas quando todos os encadeamentos possíveis de processamento de solicitações estão em uso. Quaisquer solicitações recebidas quando a fila estiver cheia serão recusadas.

Eu tive o mesmo problema e minha versão do servidor era:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.5 mod_perl/2.0.9dev Perl/v5.16.3

eu removi módulos desnecessários e o problema se foi:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips

Portanto, um dos mod_fcgid , mod_php ou mod_perl está causando problemas. Você pode tentar desativá-los se não estiver usando.

(Observação: se você estiver usando o opcache, desative também o fast_shutdown. Também estava causando problemas: opcache.fast_shutdown = 0)

Além das respostas aqui, eu li muitas outras:

• Substituir localhostpor127.0.0.1
• Atualize a versão do apache (eu tenho ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Adicionar -r(então eu recebo apr_pollset_poll: The timeout specified has expired (70007))

Nenhum deles ajudou.

Pensei em mudar para wrkdepois de ver lutas semelhantes .

Encontrando o problema

O problema parece estar relacionado à quantidade de portas epérmicas . Tentei configurá-lo de 50000 a 25000, pois esse é o intervalo de portas. Ainda sem sorte. Então, tive a impressão de que está relacionado a TIME_WAIT e a esta postagem do blog . Eu acho que poderia confirmar que:

$ netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

    1 CLOSE_WAIT
    1 established)
    1 Foreign
    4 LISTEN
    8 SYN_SENT
   62 SYN_RECV
  351 ESTABLISHED
13916 TIME_WAIT

O que eu tentei

Não corrigi até agora: - /

De acordo com sudo sysctl -a | grep net.ipv4.tcp, eu tenho:

net.ipv4.tcp_tw_reuse = 0    # No luck setting only that to 1
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_fin_timeout = 60  # Setting it to 5 didn't help either

Esse problema é causado pelo sistema. se forneça uma solicitação de alta simultaneidade ao sistema. O kernel do SO ativará a proteção contra inundação SYN. Portanto, o sistema redefinirá o link. você pode modificar a configuração do sistema operacional no arquivo

#vi /etc/sysctl.conf
net.ipv4.tcp_syncookies = 0 # set value is 0
#sysctl -p # read config from the config file.

você pode experimentá-lo.

geralmente o atributo net.ipv4.tcp_syncookiesfoi usado para proteger o sistema operacional e evitar o enorme ataque de solicitação. Mas se você quiser usar este sistema operacional para realizar alguns testes de carga ou de desempenho, feche esse recurso.