El domingo, 27 sep 2015 a las 14:00 UTC Santiago Vila escribió: > On Sun, Sep 27, 2015 at 01:46:14PM +0200, José Miguel (sio2) wrote: > > Parece que hay memoria libre, pero si por: > > > > vm.overcommit_memory = 2 > > > > no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es > > plausible pensar que se llegó a ese límite cuando no podía acceder al > > servidor. > > Esto es lo que te decía antes. Si no dices nada más entonces la memoria > que puede asignar es swap + 50% de la RAM. > > Si tienes 2GB de swap y 8GB de RAM, te estás limitando a usar 6 GB de > memoria en total. Pero tienes 8 GB así que estás desaprovechando > completamente 2 GB de RAM de la forma más escandalosa. > > Si de verdad no quieres que pida más de 8 Gigas, sube el SWAP a 4 Gigas > manteniendo la regla de SWAP + 50% de RAM. Pero incluso así estarías > desaprovechando la memoria disponible. Si las aplicaciones "piden" el > doble de lo que realmente necesitan y decides darles 8 Gigas como > máximo, entonces solamente llegarás a usar 4 GB de verdad. > > Por supuesto que es una exageración, pero es para que te hagas una idea. > > Otra posibilidad es dejarle que use *toda* la memoria disponible: > > vm.overcommit_memory = 2 > vm.overcommit_ratio = 100 > > > @ManoloDiaz > > > Sugiero que investigues el ajuste OOM score, se hace por procesos y > > > creo que systemd lo gestiona sin dificultad. Así podrías establecer > > > una jerarquía para ver cuáles son los últimos en ser aniquilados por > > > el núcleo cuando empieza a faltar memoria. > > > > Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH > > tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el > > oom-killer no se lo cargará, cosa que me interesa. > > No te interesa que se cargue *ningún* proceso. > > Esto del OOM killer en realidad es una aberración. Es como si unas > líneas aéreas deciden que cuando un avión está bajo de combustible > se elige un pasajero al azar y le dan al botón de "eject" para > ese pasajero.
Al azar no. Los mantenedores de sshd parecen estar lo bastante lúcidos como para hacer que esté disponible casi en cualquier contingencia. En un caso como este en el que el servidor está en "El País de Muy, Muy Lejano" eso es de lo más conveniente. > Mejor lee el original de Andries Brouwer: > > https://lwn.net/Articles/104185/ > > No pierdas el tiempo haciendo "ajustes" del OOM killer. Es como si te > andaras rompiendo la cabeza afinando el algoritmo por el que se decide > qué pasajero expulsas del avión... No es muy elegante, pero no creo que los desarrolladores de Linux se hayan levantado un día aburridos y decidieran programar una aberración. Parece que las soluciones obvias al límite de la memoria son (aparte de aumentarla) o eliminar procesos, o impedir que se lancen nuevos. Y te ofrecen que elijas entre dos soluciones nada elegantes. -- Manolo Díaz
