Tuesday, April 30, 2024
 Popular · Latest · Hot · Upcoming
0
rated 0 times [  0] [ 0]  / answers: 1 / hits: 5119  / 3 Years ago, tue, september 28, 2021, 6:36:55

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:



BEFORE




  • 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




AFTER




  • 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?



Thanks



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?


More From » 12.10

 Answers
7

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


[#34053] Wednesday, September 29, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
berlorful

Total Points: 346
Total Questions: 90
Total Answers: 99

Location: Monaco
Member since Tue, Nov 30, 2021
2 Years ago
berlorful questions
Thu, Sep 2, 21, 10:12, 3 Years ago
Sun, May 9, 21, 20:55, 3 Years ago
Mon, Jan 16, 23, 23:19, 1 Year ago
Mon, Aug 29, 22, 05:43, 2 Years ago
;