We have a monitoring application that measure memory values of ESXi hosts and virtual machines. It can measure swap in and swap out for host and vm. It doesn't measure swap in rate or swap out rate though. I enabled some additional monitoring for swap in / swap out of the hosts and I immediately started getting alerts in regard to swap in and swap on on several hosts. So I investigated the hosts. The hosts are not under any cpu or memory presure at all and there is no cpu or memory overcommitment on the ESXi hosts. We are running ESXi 4.1.0 build 702113. I used vCenter performance to look at the values for the swap in / swap out and the rates for both. It seems that the swap in and swap out are steady and don't change that much at all. The rate for swap in / swap out is 0. So I looked at the individual vm's on the host and I've tracked down several vm's that were responsible for this on the hosts. The vm's in question don't appear to be having any cpu / memory issues, but they also have the steady / unchanging value for swap in and swap out with 0 for the rates. I looked in resxtop on the hosts also and see that the SWR/s and SWW/s are 0 so that no current swapping appears to be happening on the virtual machines in question. The SWCUR is relateively stable for the virtual machines in question and the SWTGT is lower that SWCUR.
It appears that these virtual machines got the high valies for swap in and swap out when I was doing maintenance on the ESXi cluster. I recently patched them and had to place hosts into maintenance and vmotion machines around. If swapping isn't occurring for the virtual machines how can I get the counters for swap in and swap out back down to 0 where they should be?
RUSS GIVENS wrote:
If swapping isn't occurring for the virtual machines how can I get the counters for swap in and swap out back down to 0 where they should be?
You should first verify that there are no Memory Limits set on these VMs, this could make swapping to take place even if the host is not low on memory.
If there just was some temporary condition that caused some VMs to swap out and you know that the situation is normal now then you should not have to worry. The memory that was swapped by the Vmkernel will not go back until:
1. The VM actually needs those memory areas. If they have been like this for some time then they have not had any use so far.
2. You could restart the VMs to bring all memory back, but this might be a production disturbance and if you do not mind that it "looks ugly" then you could just leave it like this.