R82 using more swap than R81.20

[Don_Paterson]

Anyone know why an R82 SMS would use more swap than an R81.20 SMS?

Both have 8GB RAM.

The R82 SMS has 8 CPU cores and the R81.20 SMS has 4

Both are on Hyper-V (Build: 20348-10.0-3-0.3692)

R81.20 is unpatched (take 631) and R82 is JHFA Take 33

R81.20 uses 70M of swp and R82 uses up to 2G when doing nothing (idle) - and after 1 hour of uptime.

SmartConsole is connected but not used.

[the_rock]

Hey Don,

Were you able to sort this out?

[Timothy_Hall]

8GB is the minimum RAM requirement for an SMS in both R81.20 and R82.  I would expect some swap usage if you are allocating the minimum.  The major kernel update in R82 may have changed the way it handles swap space, or there may be more overhead in the new kernel that consumes more memory (kernel memory cannot be swapped or paged and must always be "real"), which is squeezing process space for memory more than it did before.

Regardless of 4 or 8 cores, with 8GB of RAM, both versions of the SMS will use the "Medium env resources profile," which I just reviewed, and the heap sizes and such for that particular profile did not change between R81.20 and R82.  Keep in mind that a transitory condition (booting up, policy installation, etc.) that caused the system to run low on available (not free) memory may have briefly pushed the system into swap space.  In my experience, once that swap space is allocated, it is never released until a reboot.  So even if the transitory condition has passed and there is now plenty of available (not free) memory, it may still show swap allocated but not actually used.  Generally, I don't get too worried unless the amount of swap allocated exceeds 5% of the system's total RAM, which is about 410 MB in your case.

You can use sar -S to help determine when the transitory condition occurred and when the swap was initially allocated, and whether it is still actually in use right now.  To see the amount of swap allocated to each currently running process (this may indicate which process was responsible for the swap allocation growth during the transitory period), run grep -i vmswap /proc/*/status

[Don_Paterson]

Hi Tim,

Thanks for the Intel. Much appreciated. 

It makes perfect sense and resonates with my experience. 

It's been a interesting exercise. 

I got the swap up to 2G yesterday, a little over the 400M mark 😉

That was after downloading/exporting a JHFA package from the SMS in the CPUSE portal (Gaia portal).

That and using central deployment made the swap usage jump up. 

It only ever goes down a few M from the high water mark that it sets. 

It suddenly dropped to 300M (from 2G) but that was because I had started the JHFA installation and I assumes CPM and postrgres stop using memory and a RHEL component kicks in and deallocates and properly frees up memory and swap. 

Of course a reboot follows that and the story begins again. 

Performance was not bad at quiet times (shared virtual platform) and it was interesting to watch vmstat 1 and see the si and so when revisiting parts of the SmartConsole after some time had passed between the initial browsing to the different parts of the SmartConsole and returning to those views. 

So, lessons learned:

Swap is good, and needed but its better to go for 16G + RAM in the SMS and watch out for slow storage otherwise.