On 10/19/2016 05:54 PM, johnyju...@sigaint.org wrote:
It always seemed a bit "off" to me that there should be any swap usage or significant buffers/caches inside VM's.dom0 already caches the virtual .img files, so having the kernel inside each VM also buffering/caching files and metadata is really just a waste of CPU and disk space. More importantly, swap activity is a major performance killer on bare hardware; even more so on a virtual machine. There's a case to let some stuff swap out (unused x-servers in sys-net/sys-firewall, etc.) but the default is way too aggressive for good performance, IMHO. The kernel has a "vm.swappiness" (0 to 100) parameter that controls the balance between grabbing a new free page from the cache or swapping a page out to re-use. The default is 60, which leans towards swapping instead of cache use. Not ideal. In dom0 and all my VM's, I tried changing the swappiness factor to see what the effect would be: # echo 0 >/proc/sys/vm/swappiness or $ sudo sysctl -w vm.swappiness=0 To empty existing swap space, I did a "swapoff -av && swapon -av" Performance is noticeably better, with no swapping happening in any of the VM's, nor in dom0. And memory usage reported by the Vm's seems to be smaller; a heavy browsing session used to crank a VM up to 1.5G; now it seems to be more like 800M. So I can run more VM's, get more done. (I'm not sure why this is, but firefox seems to be less of a memory pig with this change. Maybe with the former aggressive swapping out, Firefox thought free memory was a bit cheaper than it is, and was more aggressive in its own use, or more lax in freeing things up. With a more realistic picture of the memory situation, by changing vm.swappiness to 0, it doesn't seem to be quite the pig it was.) You can set the parameter permanently by adding "vm.swappiness=0" to /etc/sysctl.conf in dom0 and your templates. Poking around 'net, I see a few comments where 0 swappiness is best for guest VM's. I wonder if a little higher might not be bad, for the case of an unused X server or whatever, being able to swap out. I might play a bit with different settings in different VM's. It would be nice to disable caching in the VM's, but that seems to be a difficult thing to do in Linux. So far I've found that the system is pretty good about keeping the VM size to the minimum/startup size, and giving up buffers/cache when needed. (buffers/cache aren't included in the 'memory-used' calculation when mem-balancing between VM's, which keeps the buffers/cache under control a bit, I think. Excessive cache use is not given weight and rewarded by additional memory in the balancing. Any real memory needs from an existing or new VM would effectively take priority over buffer space, in the memory balancing allocations.) Real quick and dirty way of checking your swap usage across VM's (I might add this info to the VM manager for fun, since it's pretty critical performance information; will submit any changes): $ sudo xenstore-ls -f /local/domain | awk '/meminfo/ { print $12-$14, $1 }' The # reported in the path is the domid, which you can see with "qvm-ls -i" I'd be interested in hearing others' thoughts on this. Related reading: https://www.xenproject.org/directory/directory/research/118-geiger-monitoring-the-buffer-cache-in-a-virtual-machine-envrionement.html http://www.sersc.org/journals/IJCA/vol6_no1/12.pdf
Interesting, sounds reasonable.Running with absolutely 0 swap however can lead to unexpected problems from my experience: Some applications (e.g. firefox downloads the last time I tested it) use memory-mapped files of arbitrary size assuming swapping is enabled, i.e. you'll store the entire files in memory without swapping. If however the files are getting too large (say you download a multi Gig file via firefox), your memory will run out and the application will report an error (firefox will cancel the download due to a write error).
Most applications work though and reducing the swap size to an absolute minimum certainly helps to improve speed.
-- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2efe4523-86f1-02a9-4a7a-313bc1a0733a%40hackingthe.net. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
