Sun OpenSSO Enterprise 8.0 Performance Tuning Guide

Resolving Memory Issues

The amtune tool automatically tunes all memory related parameters. In most deployments, this is sufficient. However, occasionally the amtune tuning may not be sufficient and you may run into memory issues. Memory issues manifest themselves through excessively frequent garbage collection (GC) operations or frequent “Out of Memory” errors.

To resolve memory related issues, use the OpenSSO Enterprise administration console to tune the following parameters:

To tune the policy cache, see Tuning the Policy Cache.

Tuning Maximum Sessions

The tuning of this property depends on the JVM heap size configured in the web container where OpenSSO Enterprise is deployed. The minimum required JVM heap size for OpenSSO Enterprise is 1024 MB, and the number of sessions supported for 1024 MB is approximately 7000. see the table below for various JVM heap sizes with the default configuration.

Tuning SDK Cache Max Size

The default value is set to 10000, This is suitable for most deployments. The SDK cache value can be increased to equal to the maximum number of sessions as long as you don't encounter frequent full GCs. Increasing this value results in slightly better performance, but will reduce the maximum number of sessions.

Tuning Session Notification Queue Size

The Notification Queue size should be less than or equal to 30% of the Max Sessions, up to a maximum value of 30,000.

The following table lists the maximum number of sessions supported for various JVM heap sizes with the default tuning.

Table 3–2 Maximum Number of Sessions Supported for Various JVM Heap Sizes

JVM Heap Size 

Max # of session supported 

3136 MB 


2560 MB 


1536 MB 


1024 MB 


These settings may not be suitable for certain deployments. When the number of user attributes retrieved is large, the SDK cache size will increase. Similarly, if the Extra Session properties are set, the Session size will increase.

In these cases, use one of the following options to solve the memory related issues:

To Tune the Notification Threadpool Size

Set the value of based on number of CPUs and based on the purgedelay value. See To Tune the Purge Delay Settings for related information.

To Tune the Purge Delay Settings

The purgedelay property is used to keep the session in memory in a timed-out state after the session has timed out. If the value is set to 0, then the session is removed from memory immediately. If the value is greater than zero, then the session is maintained in the memory until the purgedelay time elapses.

The property describes the maximum number of active sessions that the system will allow. When the purgedelay is set to 0, the total number of sessions (active sessions and timed-out sessions) in memory will be equal to the value set for If purgedelay is greater than 0, then the total number of sessions (active and timed-out sessions) in memory can be greater than active sessions. The difference will be based on three factors: the purgedelay time , the percentage of timed-out sessions, and the authentication rate. Therefore, when purgedelay is greater than zero, the maximum active sessions value should be reduced accordingly.

The simple way to do this is to look in the OpenSSO Enterprise session stats file. The amMasterSessionTable shows the current and peak values for maxSessions (active sessions + timed-out sessions) and maxActive (only active sessions) sessions in memory . Based on this information, the maxSessions value in the stats file limit should not exceed the 90000 limit for a JVM heap size of 3136 MB. When the purgedelay is set to 0, only one notification is sent when a session is removed from memory. When the purgedelay is greater than 0, then there will be two notifications for each timed-out session. The number of notifications for timed-out sessions are increased, and now more notification threads are needed. So the notification thread pool size should also be increased.