El día 10 de abril de 2017, 6:31, luis gil <[email protected]> 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 <[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.
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
