Re: oom-killer no funciona como debería.
El día 10 de abril de 2017, 6:31, luis gil <luis.gilportero@gmail.com> escribió:
> 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.
No has dado mayor información acerca de versiones específicas, yo
trataría de replicar vía VM el sistema en un debian más reciente con
un Mysql o MariaDB y Php actualizados y probaría (si es que es
factible). Personalmente pienso que Mysql no está haciendo lo que
documenta que hace, debiese hacer o comportarse. Desde Mysql 5.1 a la
actual ya ha pasado un tiempo.
Suerte.
--
usuario linux #274354
normas de la lista: http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html
Reply to: