O erro significa que a outra extremidade (webserver) desconectou-se repentinamente no meio da sessão. dê uma olhada nos logs de erro do apache ou nginx para ver se há algo suspeito lá.
Então, se eu fizer um benchmarking com o benchmark do apache (ab), e eu uso um grande número de pedidos. Então, às vezes, no meio de um teste, recebo esse erro.
Eu nem sei o que isso significa. Então, como posso consertar isso? Ou é apenas algo que acontecerá se o servidor receber muitos acessos? O problema é que, se eu executar 10.000 acessos, tudo funcionará perfeitamente. Se eu executar de novo, ele vai chegar a 4000 e obter o erro:
apr_socket_recv: Connection reset by peer (104)
Um pouco sobre minha configuração: Eu tenho o nginx recebendo solicitações estáticas e processando as dinâmicas para o apache. O arquivo em questão é servido do cache pelo nginx, então eu acho que provavelmente tem a ver com a forma como o nginx está lidando com os pedidos?
Idéias?
Isso significa que o servidor está sobrecarregado com a solicitação, ou seja, todos os threads estão ocupados servindo a solicitação. Solução: aumente a contagem do atributo maxThread para o conector no arquivo server.xml ou aumente o valor do atributo acceptCount.
acceptcount: o tamanho máximo da fila para solicitações de conexão de entrada quando todos os possíveis encadeamentos de processamento de pedidos 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 os módulos desnecessários e o problema desapareceu:
Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
Então, um dos mod_fcgid , o mod_php ou o mod_perl está causando problemas. Você pode tentar desativá-los se não estiver usando.
(nota lateral; Se você estiver usando o opcache, desabilite o fast_shutdown também. Estava causando problema também: opcache.fast_shutdown = 0)
Além das respostas aqui, li muitas outras:
localhost por 127.0.0.1 ApacheBench, Version 2.3 <$Revision: 1807734 $> ) -r (Então recebo apr_pollset_poll: The timeout specified has expired (70007) ) Nenhum deles ajudou.
Pensei em mudar para wrk depois de ver lutas semelhantes .
O problema parece estar relacionado com a quantidade de portas epidérmicas . Tentei configurá-lo de 50000 a 25000, pois esse é o intervalo de portas. Ainda sem sorte. Então fiquei com a impressão de que isso está relacionado a TIME_WAIT e este post de blog . Acho que posso confirmar isso:
$ 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
Eu não consertei até agora: - /
De acordo com sudo sysctl -a | grep net.ipv4.tcp , 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 der um pedido de alta simultaneidade ao sistema. O kernel do sistema operacional acionará a proteção contra inundação SYN. Então o sistema irá 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 tentar.
geralmente o atributo net.ipv4.tcp_syncookies foi usado para proteger o SO para evitar o enorme ataque de solicitação. Mas se você quiser usar este sistema operacional para fazer algum teste de carga ou teste de desempenho, feche este recurso.