System Sizing Guide
Overview
Getting the best performance in production environments requires a properly configured system. The most critical elements of that configuration surround JVM memory usage and garbage collection settings. This section covers:
-
a subset of JVM options relevant to the sizing and tuning of the Oracle Health Insurance application
-
sizing guidelines for the JDBC Connection Pool
JVM Options
A full list of JVM options can be found in the Java documentation. The following are relevant for Oracle Health Insurance applications:
Setting | Value | Description |
---|---|---|
-Xmx |
Maximum java heap size. |
|
-XX:+UseG1GC |
UseG1GC |
Specifies that the G1 garbage collector will be used. |
Heap size does not determine the amount of memory the JVM will use.
Java will allocate a certain amount of memory for the native part of the JVM, as well as a per thread call stack and reserved code cache for JIT compilation. The native part of JVM allocation can not be influenced and depends on a number of factors including platform and heap heuristics.
Processing Related Memory Sizing
Oracle recommends allocating 50 Megabytes of heap per processing thread. The maximum number of task or activity processing threads is controlled by the Core Work Manager Max Threads Constraint that can be set via the WebLogic Console.
Web Services Related Memory Sizing
Similar to the sizing for task or activity processing threads, Oracle recommends allocating 50 Megabytes of heap for servicing a Web Service request.
Working Space Memory
Once the UI and processing contributions have been calculated, the entire value should be increased by 30%. This accounts for working space for the garbage collector. Oracle recommends the use of the through put collector (concurrent mark and sweep or CMS) as well as the parallel new generation collector. Both of these collectors require extra working space for carrying over objects during concurrent collection.
Sample Worksheet for Heap Size Calculations
Base Memory |
1024m |
|
---|---|---|
Processing Memory |
1600m |
(16 + 16) * 50 |
Total Memory |
3074m |
Base Memory + Processing Memory |
Heap Setting (-Xmx) |
~4000m |
3074Mb * 1.3 (garbage collector overhead) |
In this scenario, the -Xmx value would be set to approximately 4000 Megabytes in the shell script for setting environment variables for the Oracle Health Insurance application.
Allocating Too Little Memory
Allocating too little memory can have significant performance impacts. It can lead to garbage collector issues, system freeze and severe system performance issues.
Allocating Too Much Memory
Allocating too much memory can lead to lengthy garbage collection pauses and lengthy memory defragmentation (also known as compaction). That in turn may lead to system failures. Make sure that the maximum heap size does not exceed 8192 megabytes. If more memory is required to service all requests then set up additional managed servers in the same domain / cluster for running the system.
Connection Pool Sizing Guidelines
Oracle Health Insurance utilizes WebLogic Data Sources & Connection Pools to connect to the database. The number of connections in the Connection Pool should be properly sized. This paragraph contains guidelines for that sizing exercise.
Connection Pool Management
The connection pool is managed by the WebLogic application server. For example, WebLogic may temporarily test a connection before it is handed to the process that requested it. For determining the size of the connection pool the total amount of connections is corrected for this overhead by increasing it with 30%.
Processing Related Connection Pool Sizing
For task or activity processing, the number of database connections required is similar to the amount of processing threads.
Web Services Related Connection Pool Sizing
For handling Web Service request, Oracle Health Insurance use more than one database connection. For auditing purposes, information is logged using a separate connection. As a result, for handling Web Services requests the number of database connections required is: the number of concurrent requests * 2.
Processing Threads |
15 |
|
Processing Database Connections |
15 |
15 |
Number of concurrent Web Services Requests |
15 |
|
Web Services Database Connections |
30 |
15 * 2 |
Total number of Database Connections |
137 |
(50 + 15 + 30) * 1.3 (management overhead) |
As a result, the maximum number of database connections in the pool should be set to 137. Make sure that the number of sessions that the database can accommodate is larger than that number.