This session shares many of the production proven methods of running Java on vSphere. Covering how to size JVMs, and VMs for large scale deployments. The session will have a special section on GC tuning and show how a wide range of JVMs can be tuned using a GC recipe developed over the past 15 years of actual field experience in tuning JVMs.
Three key trends and associated tuning techniques are discussed in this session. The key trends are: Consolidation, Elasticity and Flexibility, and Performance
Consolidation
Many of our customers find that their middleware deployments have proliferated and are becoming an administrative challenge associated with higher costs. We see a trend across customers who look to virtualization as a way of reducing the number of server instances. At the same time, customers are taking the consolidation opportunity to rationalize the number of middleware components needed to service a particular load. Middleware components most commonly run within a Java Virtual Machine (JVM) with an observed scale of 100 to 1000s of JVM instances and provide many opportunities for JVM instance consolidation. Hence, middleware virtualization provides an opportunity to consolidate twice — once to consolidate server instances, and, secondly, to consolidate JVM instances. This trend is far-reaching, because every IT shop on the planet is considering the cost savings of consolidation. One customer in the hospitality sector went through the process of consolidating their server footprint and at the same time consolidated many smaller JVMs that were less than 1GB heap. They consolidated many of these smaller 1GB JVMs into 2 categories, those that were 4GB, and others that were 6GB. They performed the consolidation in such manner that the net total amount of RAM available to the application was equal to the original amount of RAM, but with fewer JVM instances. They did all of this while improving performance and maintaining good SLAs. They also reduced the cost of administration considerably due to the reduced number of JVM instances they had to manage, and refined environment that helped easily achieve SLA.
Another customer, in the insurance industry, was able to achieve the same as the above customer, but additionally was able to over-commit CPU in development and QA environments in order to save on third party software license costs. On the other hand, sometimes we come across customers that have a legitimate business requirement to maintain one JVM for an application, and/or one JVM per a line of business. In these cases, you cannot really consolidate the JVM instances, as that would cause intermixing of the lifecycle of one application from one line of business with another. However, while such customers don’t benefit from eliminating additional JVM instances through JVM consolidation, they do benefit from more fully utilizing the available compute resource on the server hardware, that otherwise would have been underutilized in a non virtualized environment
Elasticity and Flexibility
It is increasingly common to find applications with seasonal demands. For example, many of our customers run various marketing campaigns that drive seasonal traffic towards their application. With VMware, you can handle this kind of traffic burst, by automatically provisioning new virtual machines and middleware components when needed, and then automatically tear down these VMs when the load subsides. In addition, the ability to change updating/patching hardware without causing outage is paramount for middleware that supports the cloud era scale and uptime. VMware VMotion gives you the ability to move VMs around without needing to stop applicators and or the VM. This flexibility alone makes virtualization of middleware worthwhile when managing large-scale middleware deployments. One customer in the financial space, handling millions of transactions per day, used VMotion quite often to schedule their hardware upgrades without any time downtime. What otherwise would be a costly scheduled downtime to their business.
In this session, I will show some actual JVM and VM sizes for middleware components both small and large JVMs. Will also detail out GC tuning recipe that I have developed over the years,that has been shown to handle JVM heap sizes form 4GB to 88GB+, and higher. Of course the introduction of in-memory databases has driven the trend to have these larger JVMs and hence why we will discuss what is the best way to tune the JVM, VM, and the hardware platform they are deployed on.