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 <[email protected]> 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.
