6.5.2 Tuning the shared class cache size

If shared classes are utilized, the cache size will need to be tuned to the specific application. This is a multistep process that involves stopping and starting the server, so it is best to perform this operation in a production-like test environment.

To determine optimum cache size, perform the following steps:

1. Stop all running Java applications.

2. Destroy the existing shared classes cache.

3. Perform a test load of the application using a large cache.

4. Use printStats to determine how much class data has been stored.

5. Use the -Xscmx runtime option to set the cache size to be slightly larger than the amount shown via printStats.

Here we present a simple demonstration showing how to tune the shared class cache size. This scenario assumes that multiple instances of the same application are installed and run on the same partition. It is possible to execute test loads of more than one application; simply start them all up in addition to the application started first in Step three.

Keep in mind that only the first Java application started with the cache size set will have its setting take effect. The shared class cache size setting only works when the cache is created. It is not possible to change the cache size after the cache has been created.

In the following sections, we explain the steps in greater detail.

 

 

Step 1 - Stop all running Java applications

Stop the server node and all running applications on the server. It is not possible to destroy a cache while a JVM is still attached to it. To ensure that no Java application, execute ps -ef | grep java. No output will be returned if the appserver and all its applications have been stopped.

 

 

Step 2 - Destroy the existing shared classes cache

Execute the java -Xshareclasses:destroyAll command.

 

 

Step 3 - Perform a test load using large cache

Set up and execute a test load of the application using the -Xscmx option in the Generic JVM arguments field in the Process Definition page. Use a large value to start with, say 200 MB.

The default cache size is platform-dependent. On AIX it is 50 MB. Determine the shared cache name by executing java -Xshareclasses:listAllcaches. See Example 6-6 for sample output from the listAllcaches command.

Example 6-6 Sample shared classes listAllcaches output 

/usr/IBM/WAS/AppServer/java/bin/java -Xshareclasses:listAllcaches

Shared Cache            OS shmid        in use          Last detach time

webspherev61_system     4               3               Fri Sep 29 12:26:30 2006

 

 

Step 4 - Use printStats to determine how much class data has been stored

Stop the running application and view the statistics by executing the command java -Xshareclasses:printStats. Note that it is not necessary to stop the application, but it is recommended. Example 6-7 displays sample output from the printStats command.

Determine the stored size by multiplying the cache size by the percentage full. In the example shown, we set the cache to be 200 MB. After running a test load and printing the shared cache statistics, we saw that the cache was 35% full. So the stored size of the shared class cache will be 35% of 200 MB, or 70 MB.

Example 6-7 Sample shared classes printStats output 

/usr/IBM/WAS/AppServer/java/bin/java -Xshareclasses:name=webspherev61_system,printStats

Current statistics for cache "webspherev61_system":


base address       = 0x0700000010000090

end address        = 0x070000001C7FFFF0

allocation pointer = 0x0700000014525B88


cache size         = 209715056

free bytes         = 135686036

ROMClass bytes     = 72506104

Metadata bytes     = 1522916

Metadata % used    = 2%


# ROMClasses       = 15769

# Classpaths       = 10

# URLs             = 25

# Tokens           = 0

# Stale classes    = 0

% Stale classes    = 0%


Cache is 35% full

 

 

Step 5 - Set the cache size to tuned value

A tuned cache size has now been determined for use in the production environment. Use the value determined in Step 4 plus an additional 10 to 20 percent.