I've got an HP Microserver with 4 gig, running a pretty minimal LXDE desktop right next to me. It's primarily a web and small VM server. It's using Debian 7.2 Stable.

# free -m
             total       used       free     shared    buffers     cached
Mem:          3840       3262        577          0         19        238
-/+ buffers/cache:       3005        834
Swap:         7628         12       7616

What I gather from this is that this is not the usual problem that frightens people of disk caches growing large. If I force the caches to drop, it only frees 100 meg or so, so I don't think that's the problem here.

What i'm trying to find out is what's using the 3 gigabytes.

# cat /proc/meminfo 
MemTotal:        3932292 kB
MemFree:          919468 kB
Buffers:            2356 kB
Cached:            74220 kB
SwapCached:         1932 kB
Active:           201688 kB
Inactive:          44464 kB
Active(anon):     153004 kB
Inactive(anon):    24032 kB
Active(file):      48684 kB
Inactive(file):    20432 kB
Unevictable:          16 kB
Mlocked:              16 kB
SwapTotal:       7812088 kB
SwapFree:        7798840 kB
Dirty:                40 kB
Writeback:             0 kB
AnonPages:        167800 kB
Mapped:           362992 kB
Shmem:              7412 kB
Slab:              43164 kB
SReclaimable:      10728 kB
SUnreclaim:        32436 kB
KernelStack:        3688 kB
PageTables:        14072 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     9778232 kB
Committed_AS:    1364204 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     2580308 kB
VmallocChunk:   34357040804 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      124480 kB
DirectMap2M:     3938304 kB
DirectMap1G:           0 kB

Having a look at /proc/meminfo, adding up all of the Active/Inactive sections only comes out to about 1GB, leaving me with 2GB more unaccounted for. This also squares nicely with the output from top and where I should subjectively be considering what's running on the system right now.

Some other posts suggested looking at the Slab: number here, but that only is 43 megabytes.

Any idea where else I should be looking for this missing 2 gigabytes?

  • Can you post the output of freemem -a? – MariusMatutiae Nov 2 '13 at 16:21
  • The output of cat /proc/meminfo wouldn't hurt either. As is you provide no real details so any answer would just be general information on what can consume memory on a Linux/Unix system. – Brian Nov 2 '13 at 16:50
  • @MariusMatutiae - No such command or such program in the repos. Updated the question. – Karu Nov 2 '13 at 19:05
  • You may wish to try (as sudo) the following commands: sync; echo 3 > /proc/sys/vm/drop_caches ; free -m. The sync command forces writing out to disk everything pending in the buffers; the echo command will flush cached disk. This will leave only other allocations under the cachhe heading – MariusMatutiae Nov 3 '13 at 7:32
  • @MariusMatutiae If I force the caches to drop, it only frees 100 meg or so, so I don't think that's the problem here.. That only clears the relatively small amount of data under the cache heading as stated in the question, it does not free up the unaccounted for two gigabytes. – Karu Nov 3 '13 at 15:20

you can see what's eating you memory with this command.

ps -e -orss=,args= | sort -b -k1,1n


If the machine you are having issues is VM, then you might be running into something called "Ballooning". Basically this is a way for the host system to apply memory pressure to the guest OS, consuming the guest’s memory allocation when other hosts start using a significant amount of memory.


If you are using VMware, run the command

vmware-toolbox-cmd stat balloon

This will show the amount of ballooned memory. I would venture to guess that this is where your 2 GB of memory is sitting and that this would be your answer to where your other memory is used. Which would be your VM host is using it.

Other sources: Detect memory ballooning from within the affected VM

Turn off ballooned memory to validate the issue.

Unballooning memory: “Unballooning” RAM that’s been ballooned by VMware

  • This is really a comment and not an answer to the original question. You can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. Please read Why do I need 50 reputation to comment? What can I do instead? – DavidPostill Nov 15 '16 at 17:28
  • I added more to the answer to make it more explicit in answering his question. I feel that this is the answer to his question. He asked where his memory went. If my suspicion is correct that this is a VM guest (which he did state but was ambiguous), then the answer would be that his "VM Host is using it" (which I added to the answer). I gave a command for him to check the memory ballooning value and a method of turning off to confirm if he was using VMware (YMMV on other VM hosts). This to me directly answers his question. – Kevin Vasko Nov 15 '16 at 17:41
  • Understood. But asking questions "Is the machine you are having issues with a VM?" should be done in comments not answers. – DavidPostill Nov 15 '16 at 18:33

With apologies to @Ereli

you can see what's eating you memory with this command.

ps krss -e -orss=,args=

where krss means to sort by resident set size (real memory used), -e means to show all processes and -orss=,args= means to print the rss and command arguments.

Another way to produce a very similar output, but on (e.g.) MacOS, might be

ps mexOrss

where m means sort by memory usage, e means to include other people's processes, x means to include processes without controlling terminals, and Orss means to add resident set size to the output.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.