I have read plenty of threads on memory caching and the standard response of "large cache is good, it shouldn't effect performance", "the kernel knows best".

I have recently upgraded from 12.04 to 12.10 and changed from VirtualBox to VMware Workstation and the performance differences are severe (I suspect it is because of the latter).

When I am running my virtual machine the system load monitor graph shows less than 50% memory usage generally. enter image description here System load indicator is showing me that the rest of my RAM is used in the cache all the time.

Plain and simple this is the comparison:


  • Cache was very sparingly used, pretty much none of my memory usage was the cache
  • Swappiness was 0 (caused my memory to be used first, then swap only if needed)
  • Performance was quite good and logical
    1. RAM was used fully first, caching was minimal. I could run enough software to utilize my full 4GB of RAM without any performance degradation whatsoever
    2. Swap space was then used as needed which was obviously slower (I am on a HDD) but was still usable when the current program was loaded into memory


  • Cache is used to fill the full 4GB as soon as my virtual machine is run
  • Swappiness is 0 (same behaviour as before but cache uses full memory straight away)
  • Performance is terrible and unusable while running Ubuntu software
    1. Basic things like changing windows takes 2 minutes +
    2. Changing screens happens frame by frame over sometimes up to 5 minutes
    3. Cannot run an IDE and VM like I could with ease before

So basically, any suggestions on how to take my performance back to how it was before while keeping my current setup?

My suspicion is VMWare is the problem, but how do I see what is tied to the use of the cache? Surely there is a way to control this behaviour in software as polished as VMware?


EDIT: Could also be important to note that the behaviour differs depending on whether VMware is open or closed. If VMware is open, then the ram will lock at like 50% and 50% cache and go into the complete lock up mentioned above. Contrastingly, if VMware is closed (after being open), then the RAM will continue to rise as it needs / cache will stay as the complete remaining memory and there is no noticeable performance degradation.

EDIT2: I have swapped my swappiness to 5 as suggested, no change whatsoever (also had the same problems with swappiness of 10 and 60 prior to posting this question). On closer examination, there is something really messed up. System monitor (and confirmed with the terminal commands suggested - free -m namely) are showing the following:

ben@ben-HPdv6:~$ free -m
         total       used       free     shared    buffers     cached
Mem:          3945       3827        117          0         42       2770
-/+ buffers/cache:       1014       2931
Swap:         1905          0       1905

Which says that only ~ 1GB of my RAM is being used and ~3GB is in disk cache BUT my VM IS running and IS allocated 1.5GB of RAM. There was NO increase in my used RAM when I loaded the VM, but the cache jumped. System monitor (was confirmed with ps -aux) does show that vmware has a correct sounding 1.8GB of RAM but obviously free -m is showing otherwise. The results also suggest otherwise as my system struggled to even open this chrome page to post the reply (I only have vmware workstation and terminal open). Its like the memory isn't being declared correctly as RAM memory usage (as opposed to cache) and then the kernel obviously isn't responding properly based on that? Like its trying to release the cache memory as required like its supposed to but it can't because its in fact used memory / not cache.

I am just spitballing here now, really looking for some help about how to get to the bottom of this. Any idea whatsoever on finding out what is going on? Is there a way to confirm this is a VMware problem and not a Ubuntu one?

  • Make sure you are running the latest VMware Workstation v9.0.1, install/upgrade VMware Tools in the guest. – Terry Wang Nov 27 '12 at 22:48
  • Also you can try to do drop clean caches "sync && echo 3 > /proc/sys/vm/drop_caches" explained here: kernel.org/doc/Documentation/sysctl/vm.txt – Terry Wang Nov 27 '12 at 22:57
  • Thanks for the continuing help :P Unfortunately, no luck. I have the latest vmware (the one without the update crashed my system so had to anyway), upgraded/reinstalled tools. I tried that command (had to run it through tee because of permission denied stuff), it worked as it should, but the cache just dropped from 2.5GB to 1.7GB - obviously there is something really messed up with that VM memory that vmware is allocating. Seeming more and more like something I should be posting in vmware forums? – B T Nov 29 '12 at 0:18
  • I'd say go and try the VMWare forum/community, see if you are hitting some bugs;-) – Terry Wang Nov 30 '12 at 5:05
  • I am seeing the same thing on my Kubuntu 12.10 desktop. Usually happens after resuming from sleep. drop_caches does nothing :( – VitoshKa Dec 29 '12 at 9:05

Set swappiness to 0 is NOT recommended in Production environment, especially for a host that runs multiple virtual machines. I've seen weird issues on servers and my own workstations, with swappiness set to 0, changing it to 5 or higher value makes it normal again, just don't set it to zero, unless you are 100% sure what you are doing and the consequence, workaround.

I don't trust the GNOME System Monitor. Normally use free, vmstat or dstat.

  1. free Available system memory = free + buffers + cached, or + buffers/cache in free output.
  2. vmstat is mainly used to monitor page (swap) out/in. You need to troubleshoot if lots of page out/in happen.
  3. dstat is more advanced than vmstat

Have you tried to check VMware Workstation known issues? Make sure you run the latest version: 9.0.1?

Linux memory management:



  • Thanks, changed the swappiness and used those tools with no result (see EDIT2). Is there a reason behind the swappiness = 0 being bad or is it just buggy or something else? Haven't really been able to find anything suggesting not to use swappiness = 0, so just wondering. Also, the links were great, helped me understand better what could be going on. Thanks – B T Nov 25 '12 at 23:34
  • Just experience;-) Normally in production environment, the folks here don't set swappiness to 0, unless you have endless RAM that is never going to be filled. I've seen kernel doing stupid things (page/swap out to disk) even if swappiness was set to 0 and plenty of RAM was available there, swapping out will cause poor performance and applications down. – Terry Wang Nov 27 '12 at 22:29

The solution ended up being resolved with future kernel updates. For the record, the offending kernel which caused this problem was 3.5.0-17-generic

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.