Estoy corriendoDebian GNU/Linux 5.0y estoy experimentando errores intermitentes de falta de memoria provenientes del kernel. El servidor deja de responder a todos excepto a los pings, y tengo que reiniciar el servidor.
# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux
Esta parece ser la parte importante de /var/log/messages
Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e
Fragmento completo aquí:http://pastebin.com/a7eWf7VZ
Pensé que tal vez el servidor se estaba quedando sin memoria (tiene 1 GB de memoria física), pero mi gráfico de memoria de Cacti me parece bien...
Un amigo me corrigió aquí; señaló que el gráfico en realidad está invertido, ya que el morado indicamemoria libre(No se utiliza memoria como sugiere el título).
Pero, extrañamente, el gráfico de carga se dispara poco antes de que el kernel falle:
¿Qué registros puedo consultar para obtener más información?
Actualizar:
Quizás sea digno de mención: el porcentaje de CPU y los gráficos de tráfico de red eran normales en el momento del bloqueo. La única anomalía fue el gráfico de carga promedio.
Actualización 2:
Creo que esto empezó a suceder cuando implementé Passenger/Ruby, y al usarlo topveo que Ruby está usando la mayor parte de la memoria y una buena cantidad de CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5189 www-data 18 0 255m 124m 3388 S 0 12.1 12:46.59 ruby1.8
14087 www-data 16 0 241m 117m 2328 S 21 11.4 3:41.04 ruby1.8
15883 www-data 16 0 239m 115m 2328 S 0 11.3 1:35.61 ruby1.8
Respuesta1
Verifique los mensajes de registro para ver si hay indicaciones del problema de falta de memoria del kernel o OOM killeden la salida de dmesg. Eso puede dar alguna indicación de qué procesos fueron el objetivo del asesino de OOM. También eche un vistazo a lo siguiente:
http://lwn.net/Articles/317814/
y
http://linux-mm.org/OOM_Killer
¿Qué hace este sistema? ¿Estás cansando de intercambiar al mismo tiempo? Parece que el problema es rsyslogd, según su enlace externo que detalla el bloqueo. Esta podría ser una situación en la que sería útil reiniciar periódicamente la aplicación.
Respuesta2
2.6.18 es un kernel muy antiguo. Me he encontrado con problemas en los que ciertas condiciones pueden desencadenar bucles infinitos en el kernel, lo que da como resultado que cualquier cosa, desde el agotamiento de la memoria hasta el ancho de banda de E/S, se agote por completo y descargue los mismos datos al disco en un bucle sin fin (lo que provoca picos de carga, pero la CPU normal usar.)
Estos errores tienden a corregirse poco después de ser reportados, por lo que una actualización del kernel es una solución fácil para esto; además, actualizar el kernel significa que obtendrás algunas correcciones de seguridad gratuitas :-)
Respuesta3
En otra nota, no olvide que los cactus y similares se gráfican con una determinada resolución (la recopilación es de 5 segundos de forma predeterminada, creo que los cactus son de 30 de forma predeterminada), por lo que tiene un período de 30 a 60 segundos que no necesariamente aparecen en su gráficos... si el sistema está totalmente atascado, esto también afectará al demonio de recopilación de datos.
Puede encontrar información útil adicional dentro de sus archivos de registro, ya sean /var/log/messages generales o /var/log/apache2/error.log específicos del servicio.
Si no puede, le recomiendo que revise sus servicios (observé apache2 en el extracto de registro anterior) y verifique si son capaces de causar una situación de agotamiento de la memoria en su servidor. (por ejemplo: la configuración predeterminada de Apache, con mod_prefork y php debería ser capaz de detener su sistema).