¿Cómo NO obtener tantas conexiones apache CLOSE_WAIT?

netstat muestra que hay 153 conexiones en estado CLOSE_WAIT. Las conexiones nunca se cierran. Por lo tanto, en el tiempo extra, el servidor está lleno de estas conexiones que llenan la RAM y ahora los sitios web no se están cargando.

netstat muestra muchos como los siguientes:

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

Si miro el registro de errores de Appache, antes de que aparezca la situación CLOSE_WAIT hay líneas como las siguientes

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

Mi configuración Apache 2.2.3 RAM 1024 MB (ráfaga 2048 MB) CentOS versión 5.3 (Final) ejecutando 2 instalaciones WPMU 2.9.2

Antecedentes

El socket ingresa al estado CLOSE_WAIT cuando el extremo remoto termina la conexión enviando un paquete con el indicador FIN establecido. Luego espera en este estado la aplicación local al close()socket y luego envía su propio FIN al cliente y pasa el socket al estado LAST_ACK. Consulte también el diagrama de transición de estado TCP y RFC 793 .

Tenga en cuenta también que CLOSE_WAIT no está relacionado con el infame TIME_WAIT ya que el primero ocurre en la rama de cierre pasivo (el extremo remoto se cierra primero) mientras que el último en la rama de cierre activo (el extremo local se cierra primero).

Descripción del problema

Normalmente, las conexiones pasan de CLOSE_WAIT a LAST_ASK con bastante rapidez. Si la dirección remota y el puerto siguen cambiando rápidamente, entonces un buen número de conexiones en el estado CLOSE_WAIT puede ser simplemente la consecuencia de un gran número de conexiones abiertas, utilizadas y cerradas. Se debe examinar el rendimiento del sistema, pero en sí mismo esto no constituye un problema.

Si la dirección remota y el puerto cambian lentamente, indica que los procesos de la aplicación deben esperar a la CPU, en cuyo caso los altos promedios de carga lo confirmarán.

Si, por otro lado, la dirección remota y el puerto permanecen constantes y el número de conexiones en el estado CLOSE_WAIT sigue creciendo, lo más probable es que indique un problema con la aplicación. Este es un caso especial del error de fuga de recursos: la aplicación pierde sockets abiertos en lugar de cerrarlos a tiempo. Esto consume memoria del núcleo y eventualmente hará que la aplicación falle una vez que alcance el número máximo de descriptores de archivo abiertos.

Sin embargo, tenga en cuenta que el ritmo de la fuga puede ser lento. A menudo ocurre que errores como este resultan de una falla en el manejo de una excepción en medio de una solicitud, interrumpiendo el flujo de ejecución en un subproceso de trabajo que posteriormente puede evitar la limpieza (incluido el cierre del socket). La excepción ofensiva puede ocurrir raramente.

Solución temporal

La solución temporal al problema es aumentar los límites en los descriptores de archivos abiertos y reiniciar periódicamente la aplicación cuando (preferiblemente antes) el problema comienza a afectar el rendimiento. Tenga en cuenta que esto puede afectar inadvertidamente las conexiones abiertas actualmente. La existencia de servidores redundantes y el equilibrio de carga pueden ayudar a ocultar el problema a los usuarios.

Solución permanente

La solución permanente al problema es implementar la versión de la aplicación sin el error. El grado en que la solución temporal perjudica a los usuarios y a las empresas, la disponibilidad de la versión parcheada y el estado de la última versión en funcionamiento ayudan a decidir si retroceder a la última versión en funcionamiento de la aplicación o esperar la solución.