For those of you who have installed VMware vCenter Server 4.1, have you noticed anything new during the installation process? A new screen was introduced at the end of the installation wizard for specifying the anticipated size of the virtual infrastructure which the respective vCenter Server would be managing. There are three choices here: Small, Medium, & Large. Sorry, no Supersize available yet. If you require this option, I’m sure VMware wants to talk to you.
The selection you make from the installation wizard not only defines the Maximum Memory Pool value for the Java Virtual Machine, but also the Initial Memory Pool value. Following is a chart which takes a look at vCenter Server 4.0 & 4.1 JVM Memory Configuration comparisions:
| vCenter/JVM | Initial Memory Pool | Max Memory Pool | Thread Stack Size |
| 4.0 | 128MB | 1024MB | 1024KB |
| 4.1 Small (<100 hosts, default) | 256MB | 1024MB | 1024KB |
| 4.1 Medium (100-400 hosts) | 256MB | 2048MB | 1024KB |
| 4.1 Large (> 400 hosts) | 512MB | 4096MB | 1024KB |
As noted by the table above, in vCenter Server 4.0, the JVM Maximum Memory Pool was configured by default at 1024MB. The vCenter Server 4.1 installation also defaults to 1024MB (Small <100 hosts) if left unchanged. One other comparison – pay attention to the difference in Initial Memory Pool. By default, vCenter 4.1 uses twice the amount of RAM out of the gate than previous versions.
Although the installation wizard JVM tuning component is new in 4.1, the ability to tune the JVM for vCenter is not. The Configure Tomcat application has been available in previous versions of vCenter. Some organizations with growing infrastructures may have been instructed by VMware support to tune the JVM values to overcome a vCenter issue having to do with scaling or some other issue.
Judging from the table, one can assume that the 1024MB value was appropriate for managing less than 100 hosts in vCenter 4.0. As a point of reference, the Configuration Maximums document states that 300 hosts can be managed by vCenter 4.0. This would imply that managing 100 hosts or more with vCenter 4.0 requires an adjustment to the out of box setting for the JVM Maximum Memory Pool (change from 1024MB to 2048MB).
With vCenter 4.1, VMware has improved scaling in terms of the number of hosts a vCenter Server can manage. The Configuration Maximums document specifies vCenter 4.1 can manage 400 hosts but the table above implies VMware may be preparing to support more than 400 hosts in the near future. And that’s awesome because vCenter Server sprawl sucks. Period.
So have fun tuning the JVM but before you go, a few parting tips:
- The Initial Memory Pool value defines the memory footprint (Commit Size) of the Tomcat process when the service is first started. The Maximum Memory Pool defines the memory footprint which the Tomcat process is allowed to grow to. Make sure you have sufficient RAM installed in your server to accommodate both of these values.
- Setting the Initial Memory Pool to a value greater than the Maximum Memory Pool will prevent the Tomcat VJM from starting. I thought I’d mention that before you spend too much time pulling your hair out.
- If you would like to learn more about tuning Tomcat, vast resources exist on the internet. This looks like a good place to start.
I had posted this a few weeks back on the Vmware Communities site. Modifying JVM settings fixed many issues we had with vCenter 4.1. Thanks for verifying this.
http://communities.vmware.com/message/1599268#1599268
Hmm, IME on Windows any JVM pool size over ~1.2GB causes significant performance degradation whenever GC kicks in, is it supported to set the flag for less aggressive garbage collection?
as per some of the doco floating around the internet ; when running JVM’s inside virtual machines reserve the memory for the VM otherwise performance will degrade – we see this issue with websphere, weblogic, and anything tomcat based running JVMs 🙂
It’s not a bad idea to set initial and max to the same value, this way the OS spends less time managing memory for Java. Try it out, YMMV.
As for large heaps (max memory pool), a larger heap will give you larger GC pause times. This means that every once in a while a page will take longer to load than you would expect. On the other hand with a large heap you should hit GC less frequently. If you’ve got a lot of VMs there’s no choice but to go big.
Seems GC algorithm is not tunable in a supported way. Of course you don’t want to do that sort of stuff if you don’t need to.
Jason,
Thanks for the info. I’ve been struggling with Tomcat6 memory consumption in my demo lab(s), and I’ve decided to set initial and max pools both to 128mb.
Of course, I don’t suggest anyone try this at home. My labs have vCenter 4.1 as a nested VM on an ESX(i) VMs, and I am using vCenter just for show, and not tapping into all it’s “glory”. I am just trying to put a leash on vCenter’s appetite!
Thanks for this tip, I have set my Java Initial and Max to 128 in my Lab hosth ed on Dell E4300 with 6 GB memory. As soon as I upgraded from vCenter 2.5 to vCenter 4.0 was,, memory starts to chew up.