|
I've launched something that took lots of memory and now everything lags a lot. I guess all applications' memory has gone to swap in order to free some space for the memory-intensive process, and now everything is slowly returning to RAM when accessed. Is there a way to explicitly move everything possible from swap back to RAM? Or maybe not everything, but just some particular processes data?
| ||||
feedback
|
|
I'd recommend allowing the normal Linux memory control swap in the things that are actually used, as they are used. The only thing I can think off is to turn swap off, then on again That assumes you have enough spare physical memory to contain everything in swap... | |||||||||||||||||||
feedback
|
|
You can tune it echoing some number between 0 to 100 into /proc/sys/vm/swappiness, higher number, more the system will use swap. | |||||||||||
feedback
|
|
Linux does a fine job managing memory and you shouldn't stand in its way. The vm.swappiness setting (mentioned previously) doesn't get in its way. You're more likely to experience odd issues doing things any other way. What did you launch that was so memory hungry? Can it be tuned? If it doesn't have it's own memory limit directives you can look at ulimit as well. | |||||
feedback
|
|
To copy some of my answer from this question. So that you know how the swappiness tunable works. This works by telling the VM subsystem to look for pages to swap when the % of memory mapped to process page tables + swappiness value is > 100. So a setting of 60 will cause the system to start paging out stale pages from the process page table when it is using more than 40% of your system's memory. If you want to allow your programs to use more memory at the expense of cache you'll want to lower the swappiness value. | |||
feedback
|
|
I would advise against trying to out-think the VM subsystem in the kernel. It is EXTREMELY unlikely that you actually have enough information to make better decisions than it will. And if you force it somehow to do the wrong thing, then you'll just end up making things even slower. | |||
|
feedback
|
|
If you have the memory available for all your applications, it is ok to set the swappiness to 0 so things won't swap out. For example, qemu-kvm is a big target the VMM to get swapped out, because it "appears" to be idle most of the time. I've see up to 80% of the memory of a qemu-kvm memory get written to swap. The VMs running in qemu-kvm will become near-unresponsive because they are running out of swap (although the guest has no idea this is happening). The guest VM will think it's performing most excellently, even though in truth it is dragging along terribly. When I bunch of VMs "wake up" and start doing things, it can spike the load average up to over 30, even on enterprise grade hardware with ample fast memory and disk. I guess this is a failing in the out-of-the-box qemu-kvm design. Hope this helps someone. | |||
|
feedback
|
|
If you're able to reboot the system that should do it (and might take far less time than trying any other solution out). | |||
|
feedback
|
|
Is the process still running? Open a terminal and see if you can spot the process(s) that were launched. (ps aux |grep processname might make it a bit easier) Use kill -9 PID to kill them off if they are still running. Be careful of what you kill off. If you don't know what the process is, don't kill it! Also, post the output of free -m so we can see if you are actually still using a lot of swap. If things are still running slow, you might still have whatever you launched still running. I would never turn the swap off on unless you really know what you are doing or you like living on the edge. =) | |||
|
feedback
|
