Re: Problemas de memoria
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 ---
Reply to: