Hi All,
This is a follow-up to this post:
http://communities.vmware.com/thread/155348?tstart=0
In short, something in the console is causing high swap file usage on three of our five ESX 3.5 servers. As far as I know, we don't have any third party agents installed. We have the default 256 MB of Service Console memory and 512 megs of swap on the ESX server. Do you recommend increasing the SC memory to 512? Is there anyway to see exactly what is causing the high swap file usage? Thanks.
Rather than add swap, I would figure out the cause of the memory usage
free -m, top (NOT esxtop in this case), vmstat can all help.
--Matt
Hello,
Definitely find the culprit, but in general I find 272MBs too limiting when you have to use management agents. I always opt for 800MBs unless my host is seriously low on memory ( under 6 GBs ).
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Hello,
I go for 800 and 2GB swap (max for a swap partition).....
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Swap memory is related to the amount of memory assigned to your service console not to the maximum amount of memory in your host.
Do you know how much memory was/is assigned to you console? Your swap should be 2 times your console memory size, the default it 272Mb hence the reason then default swap size is approx 512Mb, this should be good for upto 50VM's, as a matter of course if I have a large memory host I tend to set my console memory to maximum 800Mb, this means that SWAP should be set to 1.6GB. although it is not going to affect performance if you set it to a round 2Gb as Texiwill does.
Tom Howarth
VMware Communities User Moderator
Hello,
As Tom points out the general rule for SC swap is to use 2x the amount of memory you assign. However you can always assign more. Also note, that if you ARE swapping performance will go right down. But if you do need to swap, more is generally better than less. In Windows Parlance the Swap Partition is similar to pagefile.sys but it is not quite the same nonetheless.
There has always been the debate on how much Swap to give to any GNU/Linux system. However, just be aware that > 2GB swap partitions imply only 2GBs is used. So having more than in one partition is not useful and a waste of disk space. You can use up to 32 swap partitions however.
Probably more than you wanted to know....
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Thanks for all of the replies. Our servers have 32 gigs of RAM and the VMs are using about half, but the swap is over 90% used on all of them.
We also have the default 256 of memory for the SC and 512 swap. Any tips on tracking down the culprit. free -m top confirms that out of 541 swap, 0 is available.
I hate how ESX Server defaults to 5xx MB for the swap. I ALWAYS set EVERY ESX server to 1.6GB swap and leave the SC at 272MB. It's trivial to increase the SC later, and when is local disk space ever at a premium?? Pretty much never.
So, if you run esxtop, hit m to toggle to memory, and look at the COSMEM line (service console memory)... does it say... 0 free, 512 swap_t (total swap), and "some small # here" swap_f (free swap). If so that is very odd. If not, let us know.
It says COSMEM/MB 13 free: 541
swap /MB 0 curr 0
I believe the concensus here for your question is yes, increase the service console memory. Secondly, since you want to figure out the memory usage on the COS, use top. Use 'M' to sort by memory usage, type 'H' to turn off threads, and see where your usage is largest. The RSS should tell you how large of a resident set size is for a process.
-KjB
The default for the service console is 272MB, not sure how yours is 256.
I didn't quite get the whole COSMEM line from your last post. It should read something like:
COSMEM (MB): 44 free: 1592 swap_t: 1592 swap_f: 0.00 r/s: 0.00 w/s
Which reads 44MB RAM free, 1592MB swap total, 1592MB free in swap, 0.00 reads per second, and 0.00 writes per second. It would be good to see the whole COSMEM line to verify that your service console is indeed using swap excessively. I'd hate to bark up the wrong tree. ALternatively, what is the output when you do a free -m.
IF indeed your SC memory alotment is too low, which I suspect it is, then:
Our good friend Edward (TEXIWILL), who we're lucky to have posting on here, wrote up a great procedure for changing the swap partition.
http://communities.vmware.com/message/685697#685697
I recommend going right to 1.6GB, but if you have space maybe go to 2GB. You won't need it but why mess around? Every ESX server I have ever built is 1.6GB.
Once you have the swap partition switched over, increase your service console memory (super simple using VI Client/select esx host/config tab/memory/properties). I would maybe go to 400-500MB or if you are feeling like you have lots of RAM go right to 800MB.
Once that's all done, have a look at your COSMEM again. If you aren't swapping anymore, the last two values (r/s and w/s) should both be 0.00, and you should see a big number before the word free. If you are still swapping after that then there is obviously a problem with service console memory consumption that needs to be tracked down. As Matt suggested, it would be good to find the culprit first but I am assuming you haven't had any luck there yet. There may not be a culprit, your service console may just need that much RAM.
Anyhow, good luck. Let us know how it goes.