Linux no libera caché de disco grande cuando aumenta la demanda de memoria

24

Ejecutar Ubuntu en un kernel 2.6.31-302 x86-64. El problema general es que tengo memoria en la categoría 'en caché' que sigue subiendo y no se liberará ni usará incluso cuando nuestra aplicación lo necesite.

Entonces, esto es lo que obtengo del comando 'gratis'. Nada de esto parece fuera de lo común a primera vista.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

Lo primero que alguien va a decir es "No te preocupes, Linux administra esa memoria automáticamente". Sí, sé cómo se supone que funciona el administrador de memoria; El problema es que no está haciendo lo correcto. El "caché" de 1,4 GB parece estar reservado e inutilizable.

Mi conocimiento de Linux me dice que 3 GB es "gratis"; pero el comportamiento del sistema dice lo contrario. Cuando los 1.6 GB de memoria libre real se usan durante el uso pico, tan pronto como se demanda más memoria (y el 'libre' en la primera columna se acerca a 0) se invoca el asesino OOM, se eliminan los procesos y comienzan a surgir problemas a pesar de que el 'libre' en la fila - / + buffers / cache todavía tiene alrededor de 1.4 GB 'gratis'.

He ajustado los valores de oom_adj en los procesos clave para que no ponga de rodillas al sistema, pero incluso así se eliminarán procesos importantes, y nunca queremos llegar a ese punto. Especialmente cuando, teóricamente, 1.4GB todavía está "libre" si solo desalojara el caché del disco.

¿Alguien tiene alguna idea de lo que está pasando aquí? Internet está inundado de preguntas tontas sobre el comando 'libre' de Linux y "por qué no tengo memoria libre" y no puedo encontrar nada sobre este problema debido a eso.

Lo primero que me viene a la cabeza es que el intercambio está desactivado. Tenemos un administrador de sistemas que es inflexible al respecto; Estoy abierto a explicaciones si están respaldados. ¿Podría esto causar problemas?

Aquí es gratis después de correr echo 3 > /proc/sys/vm/drop_caches:

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

Como puede ver, se libera una cantidad minúscula de caché, pero alrededor de 1,4 GB parecen estar "atascados". El otro problema es que este valor parece aumentar con el tiempo. En otro servidor, 2.0 GB está atascado.

Realmente me gustaría recuperar este recuerdo ... cualquier ayuda sería muy apreciada.

Aquí está cat /proc/meminfosi vale algo:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB
linux  memory  memory-usage  disk-cache 
— trisweb
fuente
3
No tengo ninguna explicación para su caché (aunque sospecho que los archivos mmap'd probablemente entren en él), pero por el bien de la humanidad, tome una pala y un poco de cal y elimine el "no necesita intercambio" si tienes mucha RAM! " aumentador de presión. Son inmunes a la discusión racional, y están peligrosamente equivocados. El hecho de que el asesino de OOM te esté acosando es solo un síntoma de esto.
— womble
Mis pensamientos exactamente. Gracias por el consejo. ¿Conoces otros buenos artículos o argumentos sobre por qué es necesario el intercambio?
— trisweb
66
Porque si no tienes intercambio, suceden cosas como esta. Pero no te molestes en tratar de discutir con tu negador de intercambio; o bien romper la cal viva o decir "si no desea permuta de aquí, que arreglar este lío que ha insistido en la creación". Eventualmente cambiarán de opinión ellos mismos o morirán en el intento. Problema resuelto de cualquier manera.
— womble
Excelente, gracias por los consejos. Por cierto, tenías razón acerca de los archivos mmap'd: una rápida muestra mostró un montón de archivos de registro que ocupaban la memoria. Eliminarlos resolvió el problema.
— trisweb
El problema es que sin intercambio, el exceso de compromiso da como resultado que se ejecute el asesino de OOM y no el exceso de compromiso da como resultado un sistema que no puede iniciar procesos. Necesita cambiar para hacer un uso efectivo de la RAM.
— David Schwartz

Respuestas:

8

He descubierto la respuesta a mi propia pregunta, gracias a la ayuda de womble (envíe una respuesta si lo desea).

lsof -s muestra los identificadores de archivo en uso, y resulta que había varios gigabytes de archivos de registro mmap'd ocupando el caché.

Implementar un logrotate debería resolver el problema por completo y permitirme aprovechar más memoria.

También volveré a habilitar el intercambio para que no tengamos problemas con el asesino OOM en el futuro. Gracias.

— trisweb
fuente
2
Las páginas de mmap'd son descartables, por lo que no deberían hacer que la caché quede anclada. ¿Estás usando un ramfs?
— psusi
Hola, lamento desenterrar un hilo antiguo, pero actualmente estoy enfrentando el mismo problema y lsof -sno muestra ningún uso inusual. Sin embargo, estoy usando un ramfs como dijiste [y el kernel 2.6.10, que no tiene la función drop_caches]. ¿Cuál crees que es el probable sospechoso?
— Ram
1
¡Gracias por el consejo! Estoy agregando lsof -s | sort -rnk 7 | lessa mi caja de herramientas ahora. Una nota para otros lectores: esto puede ser una gran entrada /proc/net/rpc/nfs4.nametoid/channel, pero no resultó ser el culpable en mi caso.
— Nickolay
asegúrese de que sus archivos o programas grandes no estén usando mlock. en las /proc/meminfopáginas "inevitables".
— Michael Martinez
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.