Are the Newer OpenVz Kernels Swap-Happy?

[sleddog]

This VM was recently migrated to a new host node, running a newer OpenVz kernel:


[root@red:~] uname -a
Linux red 2.6.32-042stab104.1 #1 SMP Thu Jan 29 12:58:41 MSK 2015 i686 i686 i386 GNU/Linux
[root@red:~] free -m
total used free shared buffers cached
Mem: 512 154 357 0 0 143
-/+ buffers/cache: 10 501
Swap: 512 12 499


On its previous node with an older kernel it ran a month or two with 0 swap usage. (To be clear, all VMs were migrated to a new hardware, so it's not like this node is busier or more crowded than the previous. It has the same VMs.)

I've noticed the same thing with other OVZ VMs: newer kernel, more swap usage. Old kernel, near-0 swap usage.

I know that swap usage is not necessarily a bad thing But I'm curious to hear if anyone else notices the same behaviour.

 

[Awmusic12635]

Is the swapiness levels on both servers the same?

 

[sleddog]

Is the swapiness levels on both servers the same?

Don't know. These are rented VMs.

 

[Awmusic12635]

Was the older kernel a prevswap kernel?

 

[sleddog]

Was the older kernel a prevswap kernel?

No, it was vswap, 2.6.32-something. Sorry, didn't keep a note.

 

[devonblzx]

A little swap is usually a good thing, it keeps stale data out of your RAM which leaves it open to handle active processes.

Say you start a process that needs a lot of RAM, if your RAM was full of stale data, the process would have to wait for the memory to be swapped to disk before it was able to use it.  This would delay processing quite a bit as opposed to the stale data already being swapped out.

 

[sleddog]

A little swap is usually a good thing, it keeps stale data out of your RAM which leaves it open to handle active processes.

Say you start a process that needs a lot of RAM, if your RAM was full of stale data, the process would have to wait for the memory to be swapped to disk before it was able to use it.  This would delay processing quite a bit as opposed to the stale data already being swapped out.

Thanks. I do understand how swap works. What I don't understand is why a lightly-loaded container, using maybe 10% or 20% of it's RAM (including cache), swaps out a significant amount of that memory-in-use. And swaps it in again later.

 

[Francisco]

A little swap is usually a good thing, it keeps stale data out of your RAM which leaves it open to handle active processes.

This is vswap, though, so it has no real tie to actual OS swap

From my own findings, it really comes down to the app you're running. Java loves vswap, no matter how much RAM you have.

Francisco

 

[devonblzx]

This is vswap, though, so it has no real tie to actual OS swap


From my own findings, it really comes down to the app you're running. Java loves vswap, no matter how much RAM you have.


Francisco

Newer releases of OpenVZ have much different memory management than when vswap was first released, although not well documented at this time.  The implementation of cgroups is a big reason for the changes.

I'm fairly certain OpenVZ accounts for actual swap usage by the container's processes now.  Cgroups in the kernel allows for containers to distinguish between RAM and swap limits now.  Eventually, they should implement swappiness per container too, since that is an option in cgroups.

 

[devonblzx]

Thanks. I do understand how swap works. What I don't understand is why a lightly-loaded container, using maybe 10% or 20% of it's RAM (including cache), swaps out a significant amount of that memory-in-use. And swaps it in again later.

It shouldn't ever swap out memory that is in use if you have free RAM on the system.   It should only be swapping out memory that has not been used recently (stale data).

The only other reason would be if the host system is out of RAM.