A ghost process eating up all RAM?

This post was written by eli on October 27, 2013
Posted Under: Linux,oddities

After a “find” operation spanning the entire disk, I suddenly had System Monitor (2.28.0 of Fedora 12) telling me that 11.5 GB out of the existing 16 GB were used up, and the applet said 75% was “in use by programs”. Really. Virtually nothing was running on the system.

Just to be sure, I tried out

$ ps aux --sort -rss | less

(list processes sorted by resident memory) and as expected, no memory hog to be seen.

So what does the kernel (a home cooked 2.6.35.4) say for itself?

$ cat /proc/meminfo
MemTotal:       16463436 kB
MemFree:          130568 kB
Buffers:         2818532 kB
Cached:          1387344 kB
SwapCached:            0 kB
Active:          3368176 kB
Inactive:        2246912 kB
Active(anon):    1407872 kB
Inactive(anon):   339276 kB
Active(file):    1960304 kB
Inactive(file):  1907636 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               368 kB
Writeback:             0 kB
AnonPages:       1409264 kB
Mapped:           174032 kB
Shmem:            337932 kB
Slab:           10246976 kB
SReclaimable:    9526744 kB
SUnreclaim:       720232 kB
KernelStack:        5112 kB
PageTables:        47880 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8231716 kB
Committed_AS:    4241756 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      122564 kB
VmallocChunk:   34359572612 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      350080 kB
DirectMap2M:    16422912 kB

Hmmm… That’s the kernel eating up ~10 GB, most of which is reclaimable. This page seems to explain the issue: As the disk was scanned, directory and inode metadata was probably cached. So what if that takes nearly 10 GB?

The thing is that it gives a somewhat misleading picture of the computer’s state.

So let’s just tell the kernel to drop all those caches, as suggested in that page:

As root, just go

# echo 3 > /proc/sys/vm/drop_caches

and watch how the memory meter drops. This problem is supposed to be solved in kernel not as ancient as mine.

Add a Comment

required, use real name
required, will not be published
optional, your blog address