Comprensión de este error: apr_socket_recv: restablecimiento de la conexión por igual (104)

Entonces, si hago un benchmarking con apache benchmark (ab), y uso un gran número de solicitudes. Luego, a veces, en medio de una prueba, recibo este error.

Ni siquiera sé lo que significa. Entonces, ¿cómo puedo solucionarlo? ¿O es algo que sucederá si el servidor recibe demasiados resultados de todos modos? El problema es que si ejecuto 10,000 visitas, todo funcionará perfectamente. Si lo ejecuto nuevamente, llegará a 4000 y obtendrá el error:

apr_socket_recv: Connection reset by peer (104)

Un poco sobre mi configuración: tengo a nginx tomando solicitudes estáticas y procesando las dinámicas para apache. Nginx sirve el archivo en cuestión desde el caché, así que supongo que probablemente tenga que ver con cómo nginx maneja las solicitudes.

Ideas?

El error significa que el otro extremo (servidor web) se desconectó repentinamente en medio de la sesión. Eche un vistazo a los registros de errores de apache o nginx para ver si hay algo sospechoso allí.

Significa que el servidor está cargado con la solicitud, es decir, todos los subprocesos están ocupados atendiendo la solicitud. Solución: aumente el recuento de atributos maxThread para el conector en el archivo server.xml o aumente el valor del atributo acceptCount.

acceptcount: la longitud máxima de la cola para las solicitudes de conexión entrantes cuando todos los hilos de procesamiento de solicitudes posibles están en uso. Cualquier solicitud recibida cuando la cola esté llena será rechazada.

Tuve el mismo problema y la versión de mi 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

Eliminé módulos innecesarios y el problema desapareció:

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

Entonces uno de mod_fcgid , mod_php o mod_perl está causando problemas. Puede intentar deshabilitarlos si no los está utilizando.

(Nota al margen; si está utilizando opcache, desactive también fast_shutdown. También estaba causando problemas: opcache.fast_shutdown = 0)

Además de las respuestas aquí, he leído muchas otras:

• Reemplazar localhostpor127.0.0.1
• Actualice la versión de apache (tengo ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Agregar -r(entonces obtengo apr_pollset_poll: The timeout specified has expired (70007))

Ninguno de ellos ayudó.

Pensé en cambiar wrkdespués de ver luchas similares .

Encontrando el problema

El problema parece estar relacionado con la cantidad de puertos ephermales . Traté de configurarlo de 50000 a 25000 ya que este es el rango de puertos. Aún no hay suerte. Luego tuve la impresión de que está relacionado con TIME_WAIT y esta publicación de blog . Creo que podría confirmar eso:

$ 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

Lo que probé

No lo arreglé hasta ahora: - /

Según sudo sysctl -a | grep net.ipv4.tcp, tengo:

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

Este problema es causado por el sistema. si da una solicitud de alta concurrencia al sistema. El núcleo del sistema operativo activará la protección contra inundaciones SYN. Entonces el sistema restablecerá el enlace. Puede modificar la configuración del sistema operativo en el archivo.

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

puedes probarlo.

Por lo general, el atributo net.ipv4.tcp_syncookiesse utilizó para proteger el sistema operativo para evitar el gran ataque de solicitud. Pero si desea utilizar este sistema operativo para realizar una prueba de carga o una prueba de rendimiento, debe cerrar esta función.