Re: oom-killer no funciona como debería.

[luis gil <luis.gilportero@gmail.com>]

Hola Santiago. Lo primero gracias por responder. Antes de que respondieras, ya había cambiado el overcommit_memory a 2 con el ratio a 75. Te comento dentro de tu correo:

El 8 de abril de 2017, 13:52, Santiago Vila <sanvila@unex.es> escribió:

On Thu, Apr 06, 2017 at 11:49:18PM +0200, luis gil wrote:

> ¿Alguien se ha visto en
> la necesidad de modificar este parámetro? ¿le ha funcionado?

Sí y sí.

Pero hay otras cosas interesantes que se pueden hacer además de poner
el parámetro ese a 2.

- Asegúrate de que tienes suficiente swap. Por ejemplo, si tus
aplicaciones hacen overcommit en proporción de 1:2 (es decir, piden el
doble de la memoria que realmente necesitan), entonces lo lógico sería
tener una partición de swap del mismo tamaño que la RAM. De lo
contrario estás infrautilizando la RAM.

¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2? Mi RAM es de 32 G. Me parece excesivo una swap de ese tamaño.

 

- Si pones vm.overcommit_memory = 2, pon también vm.overcommit_ratio = 100
como mínimo. De lo contrario estás infrautilizando la RAM de nuevo.

Según había leído por ahí en varios sitios (no he encontrado mucha información sobre este tema), cuando pones el overcommit_memory a 2, se fija un nivel de memoria RAM a partir del cual se empiezan a matar procesos. Este nivel se calcula realizando la siguiente operación Cantidad SWAT + Cantidad RAM * ratio / 100. Poniendo el ratio a 75 el nivel se queda un poco por debajo de la RAM, de esta forma se consigue que el sistema no empiece a swapear. Al menos así lo he entendido yo en la documentación que he encontrado. Me puedo equivocar.

Te paso el estado de la memoria justo antes de un oom-killer y justo después:

lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e Committed_AS -e MemTotal -e SwapTotal -e SwapFree
MemTotal:       33270104 kB
MemFree:        17961848 kB
SwapTotal:       7079928 kB
SwapFree:        7072288 kB
CommitLimit:    32032504 kB
Committed_AS:    4819852 kB
lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e Committed_AS -e MemTotal -e SwapTotal -e SwapFree
MemTotal:       33270104 kB
MemFree:        21839200 kB
SwapTotal:       7079928 kB
SwapFree:        7072288 kB
CommitLimit:    32032504 kB
Committed_AS:    3661152 kB

En estos momentos el overcommit_memory estaba puesto a 0 (probé a ponerlo a 2 pero ocurría lo mismo así que lo dejé como estaba) y el ratio a 75. Se ve como el CommitLimit es 32032504, coincidiendo con la fórmula, aunque como el  overcommit_memory está puesto a 0 no aplica, sólo lo hace si esta a 2.También se ve como la memoria libre sube de 17 a 21 G después del oom-killer. La swap ni la toca.

Cuando ocurrió este oom-killer estaba ejecutando una sentencia LOAD DATA LOCAL INFILE de un fichero csv de 1,5 G a través de la aplicación php. Esta carga se viene haciendo todos los días desde hace varios años, aunque el fichero es un poco más grande cada día (quizás se ha alcanzado algún límite, aunque no sé cual). Al tercer o cuarto intento carga el fichero. Como se puede apreciar la memoria libre en el momento del oom-killer es de más de 17G. No tiene sentido. O estoy monitorizando mal la memoria o la gestión de memoria no funciona como yo me creo.

También pensé que a lo mejor la memoria que se estaba llenando es la Low, pero este es su estado antes y después del mismo oom-killer:

lacuqui@Homer3:~$ free -lm
             total       used       free     shared    buffers     cached
Mem:         32490      14968      17521          0          2      12999
Low:           620        358        261
High:        31870      14609      17260
-/+ buffers/cache:       1966      30523
Swap:         6913          7       6906
lacuqui@Homer3:~$ free -lm
             total       used       free     shared    buffers     cached
Mem:         32490      11172      21317          0          4      10414
Low:           620        357        262
High:        31870      10814      21055
-/+ buffers/cache:        753      31736
Swap:         6913          7       6906

La memoria Low libre ronda los 260M. La tengo monitorizada cada 5 mn y nunca ha bajado de 190M.

 

- Si estás usando Apache en modo fork, considera usar otros modos.
En particular debes asegurarte de que una avalancha de visitas
no pueda elevar la memoria usada por Apache sin ningún límite.
(Hay parámetros para esas cosas si los sabes buscar).

La memoria que utiliza apache la monitorizo con el siguiente comando

ps -C apache2 -o rss --no-headers | awk '{ sum += $1 } END { print sum/1024 }'

cada 5 mn. El número de usuarios lo tengo limitado a 150. Pocas veces llega a tantos usuarios y en esos casos la memoria que ocupa apache es de 1,3 G en total. Entiendo que esto incluye la memoria que está ocupando php ....

 

- Si no estás usando PHP-FPM como forma de que funcione PHP, considera
usarlo en lugar de lo que estés usando. Esto ayuda muchísimo a que la
cantidad de RAM en uso se mantenga dentro de unos límites.

- Una vez que estés usando PHP-FPM, si lo único que necesitas de
Apache es que sirva ficheros y funcione PHP, considera además usar
nginx en lugar de Apache, suele gastar menos memoria.

Creo que el problema está más en la configuración del mysql, ya que esto mismo me ha ocurrido lanzando una consulta LOAD DATA LOCAL INFILE directamente al mysql, sin apache ni php ni nada. Y con un csv bastante más pequeño. De hecho de lo primero que desconfié fue de este comando pero no encontré nada en internet que asocie este comando con un out of memory intempestivo. El caso es que hay procesos bastante grandes que no utilizan este comando y se ejecutan sin problemas, algunos consumiendo mucha RAM.

Perdonad el rollo. Es fruto de mi desesperación. En cualquier momento el jefe de va a colgar de los pulgares y se me están acabando las ideas.

Un saludo.