¿Alguien puede decirme dónde se ha ido la memoria: (no, esta vez ni buffers ni caché)
# free
total used free shared buffers cached
Mem: 3928200 3868560 59640 0 2888 92924
-/+ buffers/cache: 3772748 155452
Swap: 4192956 226352 3966604
arriba, ordenado por memoria, descendente:
top - 13:42:06 up 1 day, 3:47, 2 users, load average: 0.08, 0.12, 0.36
Tasks: 228 total, 1 running, 227 sleeping, 0 stopped, 0 zombie
Cpu0 : 2.0%us, 4.0%sy, 0.0%ni, 90.1%id, 0.0%wa, 0.0%hi, 4.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 3928200k total, 3868020k used, 60180k free, 2896k buffers
Swap: 4192956k total, 226048k used, 3966908k free, 82068k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3863 root 20 0 902m 199m 3296 S 7 5.2 99:08.77 ndsd
21906 root 20 0 138m 9076 2988 S 0 0.2 0:00.02 sfcbd
2332 root 20 0 126m 4660 1332 S 0 0.1 0:17.72 mono
4243 wwwrun 20 0 683m 4468 668 S 0 0.1 0:07.38 java
2994 root 20 0 202m 2288 1660 S 0 0.1 6:10.02 httpstkd
4338 root 20 0 184m 2240 1112 S 0 0.1 0:00.52 namcd
21898 root 20 0 32368 1832 1256 R 1 0.0 0:00.08 top
De hecho, hace algún tiempo, Oom intervino y bloqueó el sistema (kernel panic), y me temo que nuevamente no estamos lejos de ese punto ...
ACTUALIZAR
# cat /proc/meminfo
MemTotal: 3928200 kB
MemFree: 51336 kB
Buffers: 2964 kB
Cached: 72876 kB
SwapCached: 29128 kB
Active: 233440 kB
Inactive: 88040 kB
Active(anon): 188920 kB
Inactive(anon): 56752 kB
Active(file): 44520 kB
Inactive(file): 31288 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 4192956 kB
SwapFree: 3966824 kB
Dirty: 32 kB
Writeback: 0 kB
AnonPages: 225112 kB
Mapped: 11356 kB
Shmem: 32 kB
Slab: 1624080 kB
SReclaimable: 13740 kB
SUnreclaim: 1610340 kB
KernelStack: 4176 kB
PageTables: 10500 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6157056 kB
Committed_AS: 2397684 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 441372 kB
VmallocChunk: 34359246755 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 4184064 kB
losa
Active / Total Objects (% used) : 9041019 / 9207548 (98.2%)
Active / Total Slabs (% used) : 401132 / 401156 (100.0%)
Active / Total Caches (% used) : 91 / 159 (57.2%)
Active / Total Size (% used) : 1491537.88K / 1519791.56K (98.1%)
Minimum / Average / Maximum Object : 0.02K / 0.17K / 4096.00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
4240470 4240319 99% 0.12K 141349 30 565396K pid
2245140 2219675 98% 0.25K 149676 15 598704K size-256
2238090 2210087 98% 0.12K 74603 30 298412K size-128
...
/usr/bin/slabtop
dice El uso de la memoria no parece estar ocurriendo en el espacio del usuario, así que eche un vistazo más de cerca al uso del kernel.Respuestas:
Si estás en casa, es casi seguro que tengas una aplicación que tenga una pérdida de memoria. A menudo, el delincuente es el que el núcleo selecciona para matar (pero a veces no).
¿Has probado algo como memtop ?
fuente
top
resultados, ordenados por memoria. Es más probable que Top se encuentre en la mayoría de las distribuciones, y puede proporcionar la información necesaria. Si tiene una opción específica en mente para su sugerencia de memtop para proporcionar una mejor salida, indíquelo.puedes ejecutar
y compruebe qué aplicación es candidata para oom kill -por lo general, consume más memoria- Me parece una aplicación que se ejecuta de forma salvaje. O asigna demasiados descriptores o algunos hilos no terminan correctamente.
fuente
slabtop muestra al menos 1.3 GB de memoria utilizada en la losa.
Sin ver el resto de la losa, es difícil saber qué estaba mal, pero si se trata de inodos o entradas de directorio, estos artículos pueden ayudar:
http://rackerhacker.com/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
http://people.arsc.edu/~kcarlson/software/man/drop_caches.html
fuente