Para no escribir varios correos contentos a todos aquí: Ya he logrado meterme en el servidor y no he visto ningún programa que parezca consumir ingentes cantidades de memoria. El estado de la memoria cuando logré entrar era este:
total used free shared buffers cached Mem: 8072224 5397344 2674880 223196 93108 3734372 -/+ buffers/cache: 1569864 6502360 Swap: 2097148 32572 2064576 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. En cuanto a las aplicaciones, la que más ocupaba era squid con un 6,8%. En su fichero de configuración tengo: cache_mem 512 lo que representa el 6,25% (1/16) de la memoria RAM. Así que el dato parece coherente. El siguiente es bind con un 3.5%. Esto sí me parece bastante, pero quizás sea debido a que tengo varias vistas y adición dinámica de nombres, de manera que unas vistas tienen que ser esclavas de otras. El caso es que he puesto a 0 el parámetro del núcleo y a funcionar un script que cada 10 minutos me comprueba las estadísticas de memoria y si se ha producido algún oom. Así tendré un historial del consumo de memoria y, si vuelve a fallar, más elementos de juicio. A ver qué pasa. > Si todos los programas piden más memoria de la que necesitan y le > dices al núcleo que nunca conceda más memoria de la que tiene > realmente, estás infrautilizando la memoria que tienes. Tiene 2GB de swap. Había leído que superar esa cantidad de swap no era muy recomendable. Aunque claro, a lo mejor es debido a que, si se da el caso, lo que el sistema está pidiendo urgentemente es una ampliación de la RAM. El caso es que en la salida de free, no parece haver mucha SWAP en uso. Me inclino a pensar que era por el valor de vm.overcommit_memory Comprobaré el consumo de swap en el historial del script que he puesto a funcionar. @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. Sin embargo, tengo un servidor con wheezy más o menos como tenía antes configurado este y he comprobado que ocurre lo mismo. Sin embargo, el año pasado cuando tuve los problemas de oom, no podía acceder al servidor. Efectivamente sshd corría, pero tras autenticarme, devolvía un error de ssh_exchange_identification, creo recordar y me quedaba sin acceso. Así que ese valor, simplemente, no me ayuda mucho. Supongo que al acceder por SSH, es necesario abrir subprocesos que dada la situación no pueden abrirse. No sé si eso tendrá alguna solución. @Camaleon > Ojo, que "2719744 bytes" son ~2,5 MiB ;-) Sí, son MB, no GB... En fin, agradezco que me lo hayas dicho así como disimulando para que no se entere el resto. Gracias, de momento, a todos por las sugerencias. -- En la vida humana sólo unos pocos sueños se cumplen, la mayoría se roncan. --- Enrique Jardiel Poncela ---