Learn about the WebSphere Application Server option for large cache implementations

Introduction

In a recent review column that I wrote, I've made some suggestions to remind you that unless your application needs a large cache or can take advantage of a 64-bit algorithm, you need to be cautious about scenarios that transition to a 64-bit JVM. So far, some of the companies I've worked with are in fact trying to manage applications with large caches, and therefore have considered this recommendation. They are now planning to transition from a 32-bit JVM to a 64-bit JVM.

What I didn't mention before is that there is at least one 32-bit option that can be used to process large caches: The ObjectGrid component of the IBM WebSphere Extended deployment (also known as Data Grid). Therefore, if you are trying to manage an application that requires a large JVM because it uses a large cache, you should consider the pros and cons of the 64-bit JVM and ObjectGrid before you start transitioning to a 64-bit JVM, and then decide on the options that best suit your environment.

In my discussion, any JVM with a maximum heap capacity of more than 2GB is considered a "large JVM".

is the 64-bit JVM right for you?

In that column, I pointed out:

"Keep in mind that many people migrating from 32 to 64 have no performance advantage, and instead have a greater memory footprint because 64-bit addresses take up twice times the space occupied by 32-bit addresses." ”

Taking up more space means that it is highly likely that you plan to add more RAM to the server. The amount of extra ram you need will depend on the amount of RAM you currently use and the amount of available memory that you currently have, but you will end up with no surprise that you eventually have to use double RAM on the server to run a 64-bit JVM with the same heap size as the current 32-bit JVM. For example, a recent customer previously ran a 32-bit application server JVM with a maximum heap size of 768 MB on a system with a RAM of 2GB, but when transitioning to a 64-bit JVM, it eventually required 4GB of RAM to use the same sized application server JVM.

You might think, "How can a JVM with a maximum heap size of 768 MB cause the process to occupy more than 768MB of memory?" That makes no sense at all! "The heap is just one part of the JVM and there is an interpreter; The interpreter increases the maximum heap size by 20% to 50% in process memory usage depending on the operating system, JVM, and heap size." Therefore, for this customer, for a 32-bit JVM with a maximum heap size of 768 MB, its hardware and software configuration consumes about 950MB of memory, and its corresponding 64-bit JVM requires approximately 1.9GB of memory, and there is no memory available to the operating system or department in the case of only 2GB RAM Use of other processes running on the EC.

In addition to adding RAM (or at least enough RAM required for a 64-bit JVM), it will take time to adjust the garbage collection (GC) algorithm used by the JDK. IBM provides two GC memory for the J5SE implementation (JAVA™5) developed by WebSphere application Server (that is, aix® running on Windows®, linux®, iseries®, J5se, and System z) Model, which defaults to the "flat" memory model, which has been used in the previous version of the Java implementation developed by IBM (JDK 1.4.x and earlier) and the other as a generational GC memory model.

In the case of performance factors, a generational GC memory model will be used (on sun™ and HP, JDK only provides a generational GC memory model), which is set on the IBM JDK via command-line parameters:

-xgcpolicy:gencon

The preference for a generational GC memory model is that the large JVM must minimize the time it will take to execute the GC. In the generational GC memory model, the object was originally created in the young Generation (generation) space (often called the "nursery" (nursery)), and if the object still exists after multiple GC operations, it is then moved to the old generation space. In addition, two types of GC operations are involved in the generational GC:

Small recycling (Minor Collection) is performed only in the younger generation, which is usually done by direct replication and therefore very efficient (fast).

The large collection (Major Collection) is performed in the older generation and will use the usual tagging and scavenging algorithms.

As you may have guessed, correctly determining the size of the "nursery" and older generation space is the key to reducing the time spent in small or large recovery operations; For large caches, you want to resize the older generation to save all cached content and other objects that are long in existence. Older generations can cause too many GC operations, or even a low memory condition. The best way to determine the size of older generations is to view the amount of available heaps (the available heap percentages multiplied by the total heap size) after each GC operation in the default mode. GC logs should also be analyzed to find out how often the older generation space is recycled, and the optimal generational application should be very low in age-space recycling operations.

The size of the young generation space is set by-XMN (-XMNS/-XMNX), while the size of the older generation space is set by-xmo (-xmos/-xmox).

Large care rooms are usually suitable for handling large throughput situations, while small incubators often offer shorter pauses, while a relatively large care room is often required to obtain higher WebSphere application Server performance (throughput). A good practice is to start at 512MB and then step up or down to determine the optimal value, measure throughput or response time, and analyze the GC log to see how often and when the cleanup takes place.