Disponemos de un servicio de correo con estos datos:
1-Centos 6.4
2:Postfix 2.6.6
3:roundcube 0.8
4:dovecot 2.0.9.7
5:mysql-server 5.1.71
todo está bien, pero en el tiempo pico de uso, las conexiones inactivas de Roundcube aumentan de 1, 2 o 3 a 270 en menos de 10 minutos y los archivos abiertos de Apache (medidos por lsof) aumentan de 4000 a 20000 en ese tiempo pico.
esta es la configuración de Apache: (Apache funciona en modo prefork)
PidFile run/httpd.pid
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>
TraceEnable off
LimitRequestLine 1024
LimitRequestFields 100
LimitRequestFieldsize 1024
LimitRequestBody 10241024
y aquí está la configuración de mysql:
secure_auth=1
local_infile=0
max_connections = 600
max_allowed_packet = 16M
key_buffer =256M
wait_timeout=240
interactive_timeout=180
connect_timeout=10
innodb_buffer_pool_size=2G
cuando las conexiones inactivas de roundcube aumentaron a >100, casi los servicios (web, correo, mysql) disminuyen....
gracias por cualquier sugerencia.
Respuesta1
La respuesta es:
He editado la opción apache max_client para reducir el valor 256 --> 50 ¿¡por qué?!
para un problema (aún) desconocido, todos los procesos de Apache prebifurcados requieren un uso de CPU de aproximadamente el 100% (el 100% del uso de ese núcleo ejecuta el proceso de Apache prebifurcado durante unos momentos)
Entonces el sistema se cae, porque el sistema tiene 64 núcleos de CPU cuando los 256 procesos de Apache usan el 100% del uso de la CPU, el sistema y los servicios se caen
El problema aún existe, pero los servicios no tienen ningún problema. Creo que el problema está relacionado con los ataques a la red (nuestras herramientas de monitoreo informan muchos ataques por día), que a veces generan problemas como el bloqueo de recursos u otra cosa.
gracias por todas las sugerencias.
Respuesta2
Ahora
Después de unos 5 años
El problema ha sido detectado y solucionado en pocos días.
Fue muy complicado para un administrador de sistemas Jr. como yo ;)
Hubo un problema en el sistema de archivos del clúster GFS2 que mi compañero de equipo preparó en iSCSI LUN y este problema generó varios problemas en Dovecot y roundcube (y luego en Apache).
Para su información, cuando presté atención al parámetro %wa en el comando superior (era alrededor del 90%), pensé (quizás) que había un problema en el nivel del sistema de archivos.
Luego decidí transferir todos los datos al nuevo sistema de archivos del clúster (ocfs2) porque ¡GFS estaba obsoleto!
En primer lugar, todos los datos se trasladaron al nuevo sistema de archivos del clúster (en ocf2) y luego se rediseñó todo el sistema basándose en pacemake haproxy en Debian Wheezy.