in

Cómo configurar Linux Out of Memory Killer

Este artículo describe el asesino de la memoria insuficiente de Linux (OOM) y cómo averiguar por qué mató un proceso en particular. También proporciona métodos para configurar el asesino de OOM para que se adapte mejor a las necesidades de muchos entornos diferentes.

Sobre el asesino de OOM

Cuando un servidor que admite una base de datos o un servidor de aplicaciones deja de funcionar, a menudo es una carrera conseguir que los servicios críticos vuelvan a funcionar, especialmente si se trata de un sistema de producción importante. Al intentar determinar la causa raíz después de la clasificación inicial, a menudo es un misterio por qué la aplicación o la base de datos dejó de funcionar repentinamente. En ciertas situaciones, la causa raíz del problema se puede rastrear hasta que el sistema se está quedando sin memoria y mata un proceso importante para permanecer operativo.

El kernel de Linux asigna memoria según la demanda de las aplicaciones que se ejecutan en el sistema. Debido a que muchas aplicaciones asignan su memoria por adelantado y, a menudo, no utilizan la memoria asignada, el kernel se diseñó con la capacidad de comprometer la memoria en exceso para hacer que el uso de la memoria sea más eficiente. Este modelo de over-commit permite que el kernel asigne más memoria de la que realmente tiene disponible físicamente. Si un proceso realmente utiliza la memoria que se le asignó, el kernel proporciona estos recursos a la aplicación. Cuando demasiadas aplicaciones comienzan a utilizar la memoria que se les asignó, el modelo de sobrecompromiso a veces se vuelve problemático y el kernel debe comenzar a matar procesos para mantenerse operativo. El mecanismo que utiliza el kernel para recuperar memoria en el sistema se conoce como asesino sin memoria o Asesino OOM para abreviar.

Averiguar por qué se anuló un proceso

Al solucionar un problema en el que el asesino de OOM ha eliminado una aplicación, hay varias pistas que pueden arrojar luz sobre cómo y por qué se eliminó el proceso. En el siguiente ejemplo, vamos a echar un vistazo a nuestro syslog para ver si podemos localizar el origen de nuestro problema. los oracle el proceso fue eliminado por el asesino de OOM debido a una condición de memoria insuficiente. La capital K en Killed indica que el proceso se mató con un -9 señal, y esto suele ser una buena señal de que el asesino de OOM podría ser el culpable.




grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 2592 (oracle).



También podemos examinar el estado del uso de memoria alto y bajo en un sistema. Es importante tener en cuenta que estos valores son en tiempo real y cambian según la carga de trabajo del sistema; por lo tanto, estos deben observarse con frecuencia antes de que ocurra la presión de la memoria. Observar estos valores después de que un proceso se haya cancelado no será muy revelador y, por lo tanto, no puede ayudar realmente a investigar los problemas de OOM.




[root@test-sys1 ~]# free -lm
             total       used       free     shared    buffers     cached
Mem:           498         93        405          0         15         32
Low:           498         93        405
High:            0          0          0
-/+ buffers/cache:         44        453
Swap:         1023          0       1023



En esta máquina virtual de prueba, tenemos 498 MB de memoria baja libre. El sistema no tiene uso de intercambio. los -l El interruptor muestra estadísticas de memoria alta y baja, y el -m Switch pone la salida en megabytes para que sea más fácil de leer.




[root@test-sys1 ~]# egrep 'High|Low' /proc/meminfo
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         510444 kB
LowFree:          414768 kB


Los mismos datos se pueden obtener examinando /proc/memory y mirando específicamente los valores altos y bajos. Sin embargo, con este método, no obtenemos información de intercambio de la salida y la salida está en kilobytes.

La memoria baja es la memoria a la que el kernel tiene acceso físico directo. La memoria alta es la memoria a la que el kernel no tiene una dirección física directa y, por lo tanto, debe mapearse a través de una dirección virtual. En los sistemas más antiguos de 32 bits, verá poca memoria y mucha memoria debido a la forma en que la memoria se asigna a una dirección virtual. En plataformas de 64 bits, no se necesita espacio de direcciones virtuales y toda la memoria del sistema se mostrará como poca memoria.

Mientras mira /proc/memory y usando el free Los comandos son útiles para saber «ahora mismo» cuál es nuestro uso de memoria, hay ocasiones en las que queremos ver el uso de memoria durante más tiempo. los vmstat El comando es bastante útil para esto.

En el ejemplo del Listado 1, estamos usando el vmstat comando para mirar nuestros recursos cada 45 segundos 10 veces. los -S Switch muestra nuestros datos en una tabla y el -M El conmutador muestra la salida en megabytes para que sea más fácil de leer. Como puede ver, algo está consumiendo nuestra memoria libre, pero aún no lo estamos intercambiando en este ejemplo.




[root@localhost ~]# vmstat -SM 45 10
procs -----------memory-------- ---swap-- -----io-- --system-- ----cpu---------
 r  b   swpd  free  buff  cache  si   so   bi   bo   in    cs us  sy  id  wa st
 1  0      0   221   125     42   0    0    0    0   70     4  0   0  100  0  0
 2  0      0   192   133     43   0    0  192   78  432  1809  1  15   81   2 0
 2  1      0    85   161     43   0    0  624  418 1456  8407  7  73    0  21 0
 0  0      0    65   168     43   0    0  158  237  648  5655  3  28   65   4 0
 3  0      0    64   168     43   0    0    0    2 1115 13178  9  69   22   0 0
 7  0      0    60   168     43   0    0    0    5 1319 15509 13  87    0   0 0
 4  0      0    60   168     43   0    0    0    1 1387 15613 14  86    0   0 0
 7  0      0    61   168     43   0    0    0    0 1375 15574 14  86    0   0 0
 2  0      0    64   168     43   0    0    0    0 1355 15722 13  87    0   0 0
 0  0      0    71   168     43   0    0    0    6  215  1895  1   8   91   0 0



Listado 1

La salida de vmstat se puede redirigir a un archivo usando el siguiente comando. Incluso podemos ajustar la duración y la cantidad de veces para monitorear más tiempo. Mientras se ejecuta el comando, podemos mirar el archivo de salida en cualquier momento para ver los resultados.

En el siguiente ejemplo, estamos mirando la memoria cada 120 segundos 1000 veces. los & al final de la línea nos permite ejecutar esto como un proceso y recuperar nuestro terminal.



vmstat -SM 120 1000 > memoryusage.out &

Como referencia, el Listado 2 muestra una sección del vmstat página de manual que proporciona información adicional sobre la salida que proporciona el comando. Esta es solo la información relacionada con la memoria; el comando también proporciona información sobre la E / S del disco y el uso de la CPU.




   Memory
       swpd: the amount of virtual memory used.
       free: the amount of idle memory.
       buff: the amount of memory used as buffers.
       cache: the amount of memory used as cache.
       inact: the amount of inactive memory. (-a option)
       active: the amount of active memory. (-a option)

   Swap
       si: Amount of memory swapped in from disk (/s).
       so: Amount of memory swapped to disk (/s).

Listado 2

Hay varias otras herramientas disponibles para monitorear la memoria y el rendimiento del sistema para investigar problemas de esta naturaleza. Herramientas como sar (Informe de actividad del sistema) y dtrace (Seguimiento dinámico) son bastante útiles para recopilar datos específicos sobre el rendimiento del sistema a lo largo del tiempo. Para una visibilidad aún mayor, el dtrace Las sondas de estabilidad y estabilidad de datos incluso tienen un disparador para condiciones OOM que se activará si el kernel mata un proceso debido a una condición OOM. Más información sobre dtrace y sar está incluido en el «Ver también«sección de este artículo.

Hay varias cosas que pueden causar un evento OOM además de que el sistema se quede sin RAM y el espacio de intercambio disponible debido a la carga de trabajo. Es posible que el kernel no pueda utilizar el espacio de intercambio de manera óptima debido al tipo de carga de trabajo del sistema. Aplicaciones que utilizan mlock() o HugePages tienen memoria que no se puede intercambiar al disco cuando el sistema comienza a quedarse sin memoria física. Las estructuras de datos del kernel también pueden ocupar demasiado espacio agotando la memoria del sistema y provocando una situación OOM. Muchos sistemas basados ​​en la arquitectura NUMA pueden experimentar condiciones OOM debido a que un nodo se queda sin memoria y activa un OOM en el kernel mientras que queda mucha memoria en los nodos restantes. Puede encontrar más información sobre las condiciones OOM en máquinas que tienen la arquitectura NUMA en el «Ver también«sección de este artículo.

Configuración de OOM Killer

El asesino de OOM en Linux tiene varias opciones de configuración que permiten a los desarrolladores elegir el comportamiento que exhibirá el sistema cuando se enfrente a una condición de falta de memoria. Estos ajustes y opciones varían según el entorno y las aplicaciones que el sistema haya configurado.

Nota: Se sugiere que las pruebas y ajustes se realicen en un entorno de desarrollo antes de realizar cambios en sistemas de producción importantes.

En algunos entornos, cuando un sistema ejecuta una única tarea crítica, reiniciar cuando un sistema se encuentra en una condición OOM puede ser una opción viable para devolver el sistema al estado operativo rápidamente sin la intervención del administrador. Si bien no es un enfoque óptimo, la lógica detrás de esto es que si nuestra aplicación no puede funcionar debido a que el asesino OOM la mata, un reinicio del sistema restaurará la aplicación si se inicia con el sistema en el momento del arranque. Si un administrador inicia manualmente la aplicación, esta opción no es beneficiosa.

Las siguientes configuraciones harán que el sistema entre en pánico y se reinicie en una condición de memoria insuficiente. los sysctl Los comandos establecerán esto en tiempo real y agregarán la configuración a sysctl.conf permitirá que estas configuraciones sobrevivan a los reinicios. los X por kernel.panic es el número de segundos antes de que se reinicie el sistema. Esta configuración debe ajustarse para satisfacer las necesidades de su entorno.




sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
echo "vm.panic_on_oom=1" >> /etc/sysctl.conf
echo "kernel.panic=X" >> /etc/sysctl.conf



También podemos ajustar la forma en que el asesino de OOM maneja las condiciones de OOM con ciertos procesos. Tomemos, por ejemplo, nuestro oracle proceso 2592 que se mató antes. Si queremos hacer nuestro oracle proceso con menos probabilidades de ser asesinado por el asesino OOM, podemos hacer lo siguiente.



echo -15 > /proc/2592/oom_adj

Podemos hacer que el asesino de OOM sea más probable que mate a nuestro oracle proceso haciendo lo siguiente.



echo 10 > /proc/2592/oom_adj

Si queremos excluir nuestro oracle proceso del asesino OOM, podemos hacer lo siguiente, que lo excluirá por completo del asesino OOM. Es importante tener en cuenta que esto puede provocar un comportamiento inesperado según los recursos y la configuración del sistema. Si el kernel no puede matar un proceso que utiliza una gran cantidad de memoria, pasará a otros procesos disponibles. Algunos de esos procesos pueden ser procesos importantes del sistema operativo que, en última instancia, pueden hacer que el sistema deje de funcionar.



echo -17 > /proc/2592/oom_adj

Podemos establecer rangos válidos para oom_adj de -16 para +15, y un escenario de -17 exime un proceso completamente del asesino de OOM. Cuanto mayor sea el número, más probable será que nuestro proceso sea seleccionado para su terminación si el sistema encuentra una condición OOM. Los contenidos de /proc/2592/oom_score También se puede ver para determinar la probabilidad de que el asesino OOM elimine un proceso. Una veintena de 0 es una indicación de que nuestro proceso está exento de la OOM …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

1vah8IolNqlxNHq9ysVzYkw

Una guía para principiantes sobre la reducción de la dimensionalidad en el aprendizaje automático

Cómo crear una barra de búsqueda