el servidor web apache no responde con el estado del servidor que muestra todos los procesos secundarios que esperan la conexión [cerrado]

Mi configuración: tengo 3 máquinas de servidor web casi idénticas que sirven al mismo sitio web dinámico de alta carga con un simple equilibrio de carga sobre dns. El servicio ha estado funcionando durante más de dos años con la misma configuración de apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Mi problema: desde hace aproximadamente dos semanas tengo problemas con esta configuración. Casi todos los días tengo un pequeño momento durante unos 5 minutos, en el que no se puede acceder al sitio web. Todavía puedo iniciar sesión en los servidores a través de ssh. Si corro htop, veo que la máquina simplemente no hace nada. Tengo alrededor de 1000 procesos de apache en ejecución, pero no hay actividad de la CPU.

He usado el mod_status de apache para depurar esta situación. El cuadro de indicadores del proceso se ve así:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Entonces, la mayoría de los procesos solo están esperando la conexión. después de aproximadamente 5 minutos, la situación volverá a la normalidad: tengo menos procesos en cada máquina, la mayoría de los trabajadores tienen el estado "." (lo que significa que están abiertos para procesar una solicitud) y, por supuesto, ¡se puede acceder al sitio web!

así que estoy tratando de encontrar algo en los registros, pero simplemente no hay nada ... el registro de acceso de apache permanece en silencio durante aproximadamente 4 minutos, lo mismo es para el registro de errores. Tampoco puedo encontrar nada malo en otros registros del sistema.

la situación es la misma en los 3 servidores web (todos tienen este pico de carga y una condición que no responde al mismo tiempo), por lo que no creo que esto esté relacionado con el hardware. pero creo que esto podría estar relacionado con algún problema de red (tcp).

¿algunas ideas?

EDITAR: algo más de información, que acabo de descubrir:

Acaba de suceder nuevamente y pude verificar que tampoco puedo conectarme localmente cuando se produce este problema.

He realizado algunas estadísticas de conexión con el siguiente comando después de que sucedió: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

• 109 CLOSE_WAIT
• 2652 ESTABLECIDO
• 2 FIN_WAIT1
• 11 LAST_ACK
• 12 ESCUCHA
• 91 SYN_RECV
• 1 SYN_SENT
• 16 TIME_WAIT

Si ejecuto el mismo comando algún tiempo después, tengo algo como esto:

• 4 CIERRE
• 108 ESTABLECIDO
• 18 FIN_WAIT1
• 182 FIN_WAIT2
• 37 LAST_ACK
• 12 ESCUCHA
• 50 SYN_RECV
• 11276 TIME_WAIT

Entonces, en la situación normal, solo tengo 100-200 conexiones abiertas por parte de clientes que están siendo manejados por apache en este momento. Cuando tengo este "bloqueo", tengo muchas más conexiones. ¿Cuál es la mejor manera de analizar esto?

EDIT2: las líneas importantes en apache2.conf son:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

Es un prefork apache2 con php_mod.

El servidor tiene 8 GB de RAM y una partición de intercambio de 4 gb.

Debe habilitar el estado extendido de mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus ) para monitorear los hosts actuales y las solicitudes que se procesan. Creo que hay un script (s) / página (s) que lleva demasiado tiempo liberar la conexión y hace que las conexiones se apilen.

Primero: verifique su Max open fileslímite en el proceso. Una conexión de socket activa cuenta como un archivo abierto. cat /proc/###/limitses una buena manera de verificar el valor efectivo para otro proceso. Puede obtener una lista de archivos abiertos lsof -p ###donde ### es la identificación de proceso de su servidor web. Puede comparar lsof -p ### | wc -lpara ver qué tan cerca está llegando al límite. También debería ver mensajes en el error_log de apache si está llegando al límite.

Necesita un identificador de archivo para cada conexión de socket, y también para cada script cgi o referencia de archivo de datos. Para 920 MaxClients, debe configurar al menos 4,000 archivos para el proceso httpd. Puede aumentar la cantidad de archivos agregando un archivo en /etc/security/limits.d/ con los siguientes contenidos. Asegúrese de que el nombre de usuario coincida con lo que está utilizando para su servidor web.

apache soft nofile 10000
apache hard nofile 10000

Segundo: si el problema es el agotamiento de puertos, puede ajustar algunas configuraciones de IP en /etc/sysctl.conf. (Comenzando con net.ipv4.tcp_fin_timeout). Esto suele ser un problema solo con muchas conexiones muy pequeñas. Muchos sockets TIME_WAIT son un indicador de esto, pero esto indica el agotamiento del puerto solo cuando se acompaña de errores en syslog sobre possible SYN floodingy Sending cookies. También debe asegurarse de que su servidor esté detrás de un firewall que pueda frustrar ataques SYN maliciosos.

Además, tenga en cuenta que en el MPM prefork, cada proceso tendrá PHP en su espacio de memoria (¿cuál es su configuración de límite de memoria?). Puede intentar cambiar al MPM de trabajo, que puede requerir un módulo PHP ligeramente diferente.

También vale la pena el arete remoto para recortar su configuración de Apache de módulos extraños

En mi experiencia, tales cosas son desencadenadas por cosas como un rastreador de motores de búsqueda o cosas como conflictos ARP. O niveles de tráfico en alguna parte relacionada de la red.

Es posible que encuentre 'sar' útil ... no es el más amigable, pero ciertamente es útil.

Posiblemente también io relacionado. Sar puede decirle (si lo configura para registrar la actividad del disco), cuál es el tiempo promedio de espera io. También puede ver el tiempo de espera de E / S en la parte superior (que es un porcentaje, leer lo que realmente significa). Esto puede ser significativo si está utilizando un entorno virtual o SAN.