Solución 1:
Acabo de mirar el volcado de registro de oom y cuestiono la precisión de ese gráfico. Observe la primera línea 'Nodo 0 DMA32'. Dice free:3376kB , min:3448kB y low:4308kB . Cada vez que el valor gratuito cae por debajo del valor bajo, se supone que kswapd comienza a intercambiar cosas hasta que ese valor vuelve a subir por encima del valor alto. Cada vez que el valor libre cae por debajo del mínimo, el sistema básicamente se congela hasta que el kernel vuelve a subir por encima del valor mínimo. Ese mensaje también indica que el intercambio se usó por completo donde dice Free swap = 0kB .
Básicamente, kswapd se activó, pero el intercambio estaba lleno, por lo que no podía hacer nada, y el valor de pages_free todavía estaba por debajo del valor de pages_min, por lo que la única opción era comenzar a matar cosas hasta que pudiera recuperar pages_free.
Definitivamente te quedaste sin memoria.
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html tiene una muy buena explicación de cómo funciona. Consulte la sección 'Implementación' en la parte inferior.
Solución 2:
Deshágase del script drop_caches. Además, debe publicar las partes relevantes de su dmesg y /var/log/messages salida que muestra los mensajes OOM.
Sin embargo, para detener este comportamiento, recomiendo probar este sysctl ajustable. Este es un sistema RHEL/CentOS 6 y claramente se ejecuta con recursos limitados. ¿Es una máquina virtual?
Intenta modificar /proc/sys/vm/nr_hugepages y ver si los problemas persisten. Esto podría ser un problema de fragmentación de la memoria, pero vea si esta configuración hace la diferencia. Para que el cambio sea permanente, agregue vm.nr_hugepages = value a tu /etc/sysctl.conf y ejecuta sysctl -p para volver a leer el archivo de configuración...
Ver también:Interpretación de mensajes de "fallo de asignación de página" del núcleo críptico
Solución 3:
No hay datos disponibles en el gráfico desde que el asesino OOM comienza hasta que finaliza. Creo que en el marco de tiempo en el que se interrumpe el gráfico, de hecho, el consumo de memoria aumenta y ya no hay memoria disponible. De lo contrario, no se utilizaría el asesino OOM. Si observa el gráfico de memoria libre después de que el asesino OOM se haya detenido, puede ver que baja desde un valor más alto que antes. Al menos hizo su trabajo correctamente, liberando memoria.
Tenga en cuenta que su espacio de intercambio se utiliza casi por completo hasta que se reinicia. Eso casi nunca es algo bueno y una señal segura de que queda poca memoria libre.
La razón por la que no hay datos disponibles para ese período de tiempo en particular es porque el sistema está demasiado ocupado con otras cosas. Los valores "divertidos" en su lista de procesos pueden ser solo un resultado, no una causa. No es insólito.
Consulte /var/log/kern.log y /var/log/messages, ¿qué información puede encontrar allí?
Si el registro también se detuvo, intente otras cosas, descargue la lista de procesos en un archivo cada segundo más o menos, al igual que la información de rendimiento del sistema. Ejecútelo con alta prioridad para que aún pueda hacer su trabajo (con suerte) cuando la carga aumente. Aunque si no tiene un núcleo prioritario (a veces indicado como un núcleo de "servidor") puede que no tenga suerte en ese sentido.
Creo que encontrará que los procesos que están usando la mayor cantidad de CPU% en el momento en que comienzan sus problemas son la causa. Nunca he visto que rsyslogd ni mysql se comporten de esa manera. Los culpables más probables son las aplicaciones Java y las aplicaciones basadas en interfaz gráfica de usuario, como un navegador.