LinkedIn
Copied!

Table of Contents

JVM configuration best practices

When you configure a Java Virtual Machine (JVM) as the application server for Pega 7-based business solutions, how you tune the JVM depends on a variety of factors and changes over time based on advancements in JVM technology.

The number of JVMs needed for a particular business solution depends on the following factors:

  • Total number of service requests
  • Total number of Decision requests
  • Total number of estimated concurrent users
  • Total number of estimated concurrent occasional users (percentage of occasional users that might be concurrent during a peak hour)
  • Estimated clipboard size

The best practices for JVM configuration are the same for both development and production environments. You might need to re-evaluate the JVM configuration for an application after you deploy the application, complete load testing, and monitor the JVM behavior. Wait to tune your JVM configuration until after you resolve any performance issues and memory bottlenecks in the application.

Remember the following points when configuring a JVM:

  • User-based JVMs are configured for response time.
  • Agent and batch-based JVMs are configured for throughput.
  • The total duration for garbage collection should not exceed 2% of the overall JVM time.
  • Isolate the System Management application and Autonomic Event Services on low volume or dedicated JVMs.

This article provides guidance about: 

In addition, the following articles provide information about the best practices for specifying the JVM configuration options for IBM WebSphere Application Server and Oracle Java HotSpot Virtual Machine:

JVM options for Oracle Java HotSpot Virtual Machine

JVM properties for IBM WebSphere Application Server

Pega 7 applications, users, and agent memory

Consider the following size ranges for memory when planning for JVM configuration.

Memory size range Memory component Notes
Memory size ranges by component

500 MB to

1 GB

Pega 7

Memory used for the Pega 7 engine and applications.

This range includes the memory needed for Pega 7 caches (150 MB to 250 MB).

2 GB JVM native and PermGen memory

JVM native memory includes the following metadata:

  • All Java classes
  • Just-in-time (JIT) code caches
  • JIT data caches

The IBM WebSphere Application Server information refers to JVM native memory as native.

The Oracle information for Java HotSpot Virtual Machine uses the term PermGen space.

Remaining heap memory Effective user memory The remaining heap memory is for all concurrent requestors, any background agents that are not high processing, or agents that consume high volumes of memory.
Effective agent memory

The typical agent requestor pool size is 10, and the typical agent heap size is 2 GB. However, agent requestor pool size depends on the type and amount of work that is targeted for the agent. Therefore, agent requestor pool size is variable.

You can validate memory requirements during load and scale testing.

JVM heap size

The heap size for a 64-bit JVM might start at 8 GB but can be larger. Larger JVM heap sizes are beneficial in development environments as developers learn to optimize application designs.

Recent IBM and Oracle enhancements to compression reduce the overhead of 64-bit processing, which helps to support the implementation of larger JVM heap sizes. For example, IBM WebSphere Application Server uses compressed references to support compression on heap sizes up to 28 GB. Oracle Java HotSpot Virtual Machine uses compressed ordinary object pointers and supports compression for heap sizes up to 32 GB.

In addition, because memory is inexpensive, cost is not a factor that prevents organizations from deploying sufficient amounts of memory for application servers.

The following table provides an example of the heap size that is required for an estimated number of concurrent developers. In this example, assume that the size of the developer Clipboard is 50 MB. The expected clipboard size determines how many users can reside in a JVM heap. After factoring in 10 percent overhead for 64-bit processing, you can calculate the estimated number of concurrent users by dividing the target heap size by the expected clipboard size.

JVM heap size Heap size minus 10% overhead for 64-bit processing Estimated number of concurrent users (90%)

Estimated number of concurrent users when the clipboard size is 50 MB (based on IBM and Oracle enhancements to 64-bit JVM compression)

8 GB 7.2 GB 130
12 GB 10.8 GB 194
16 GB 14.4 GB 259

Estimating memory requirements for a requestor Clipboard

When you plan for JVM configuration, consider the memory requirements for both the developer and production user clipboards.

A clipboard is a hierarchically structured, temporary Java object used to hold and name property values for a user session. The clipboard data structure is called a page. Pages can contain embedded pages that can also contain embedded pages.

To estimate the memory footprint for an application, use the following methods:

Clipboard type Available methods
Methods for estimating memory requirements for clipboards
For the developer Clipboard, multiply the clipboard size by the peak number of concurrent users.
  • Use the Performance tool and select the Add Reading with Clipboard Size option.
  • Open the clipboard and select Action > Analyze Clipboard.
  • Use the System Management application by selecting System > Tools > System Management Application from the Designer Studio menu. Select a node and then select the Requestor Summary option.
For a production user Clipboard, multiply the clipboard size by the peak number of users.
  • To see a snapshot of an individual heap, or node, use the Memory option of the System Management application. This option opens a window that shows the current total active requestors and the current active clipboard pages.
  • To view individual requestors, in the System Management application select Requestor > Estimate Size. This option displays the current clipboard size for each active requestor.

Agent and batch-based JVMs

For both IBM WebSphere Application Server and Oracle Java HotSpot Virtual Machine, a best practice is to deploy background agents and batch processing on their own JVM. Using a dedicated JVM ensures that users and agents do not compete for memory and CPU time. You can identify the optimum ratio of agents per JVM during load and scale testing for the transition phase of a project.

Memory for third-party monitoring utilities

Third-party monitoring utilities run with the application in every JVM. These monitoring utilities are deployed within the user and agent effective memory. If the third-party monitoring utility is configured correctly, memory usage is negligible.

Did you find this content helpful?

92% found this useful


Related Content

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.