Comprensione di questo errore: apr_socket_recv: connessione ripristinata dal peer (104)

Quindi, se faccio qualche benchmarking con apache benchmark (ab) e utilizzo un gran numero di richieste. Quindi a volte nel mezzo di un test ottengo questo errore.

Non so nemmeno cosa significhi. Quindi, come posso ripararlo? O è solo qualcosa che accadrà se il server ottiene troppi hit comunque? Il problema è che se eseguo 10.000 colpi, tutto funzionerà perfettamente. Se lo eseguo di nuovo, arriva a 4000 e viene visualizzato l'errore:

apr_socket_recv: Connection reset by peer (104)

Un po 'della mia configurazione: ho nginx che accetta richieste statiche ed elabora quelle dinamiche in apache. Il file in questione è servito dalla cache da nginx, quindi credo che probabilmente abbia a che fare con come nginx sta gestendo le richieste?

Idee?

L'errore indica che l'altra estremità (server web) si è improvvisamente disconnessa nel mezzo della sessione. dai un'occhiata ai log degli errori apache o nginx per vedere se c'è qualcosa di sospetto lì.

Significa che il server è pesantemente caricato con la richiesta, cioè tutti i thread sono occupati a servire la richiesta. Soluzione: aumentare il conteggio degli attributi maxThread per il connettore nel file server.xml o aumentare il valore dell'attributo acceptCount.

acceptcount: la lunghezza massima della coda per le richieste di connessione in entrata quando sono in uso tutti i possibili thread di elaborazione delle richieste. Qualsiasi richiesta ricevuta quando la coda è piena verrà rifiutata.

Ho avuto lo stesso problema e la mia versione del server 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

ho rimosso i moduli non necessari e il problema è sparito:

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

Quindi uno di mod_fcgid , mod_php o mod_perl sta causando problemi. Puoi provare a disabilitarli se non lo stai utilizzando.

(Nota a margine; se si utilizza opcache, disabilitare anche fast_shutdown. Stava causando anche problemi: opcache.fast_shutdown = 0)

Oltre alle risposte qui, ho letto molte altre:

• Sostituisci localhostcon127.0.0.1
• Aggiorna la versione di Apache (ho ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Aggiungi -r(Quindi ottengo apr_pollset_poll: The timeout specified has expired (70007))

Nessuno di loro ha aiutato.

Ho pensato di passare a wrkdopo aver visto lotte simili .

Trovare il problema

Il problema sembra essere correlato alla quantità di porte ephermal . Ho provato a impostarlo da 50000 a 25000 in quanto questo è l'intervallo di porte. Ancora niente fortuna. Poi ho avuto l'impressione che fosse correlato a TIME_WAIT e a questo post sul blog . Penso di poter confermare che:

$ 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

Quello che ho provato

Finora non l'ho risolto: - /

Secondo sudo sysctl -a | grep net.ipv4.tcp, ho:

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

Questo problema è causato dal sistema. se fornisce una richiesta di concorrenza elevata al sistema. Il kernel del sistema operativo attiverà la protezione da inondazioni SYN. Quindi il sistema ripristinerà il collegamento. è possibile modificare la configurazione del sistema operativo nel file.

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

Puoi provarlo.

di solito l'attributo net.ipv4.tcp_syncookiesveniva usato per proteggere il sistema operativo per evitare l'enorme attacco di richiesta. Ma se si desidera utilizzare questo sistema operativo per eseguire alcuni test di carico o test delle prestazioni, è necessario chiudere questa funzione.