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:

• User cache/SDK cache

  Go to Configuration > Servers and Sites > server > SDK > SDK Caching Max Size

• Max Active Session the system should allow

  Go to Configuration > Servers and Sites > server > Maximum Sessions.

• Session Notification Thread Pool Size (Number of threads to process session notifications)

  Go to Configuration >Servers and Sites > server >Notification Pool Size.

• Session Notification Queue size

  Go to Configuration > Servers and Sites > server > Notification Thread Pool Threshold.

• Session Purge Delay (Number of minutes to delay the purge timed-out session)

  Go to Configuration > Servers and Sites > server > Session Purge Delay.

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	200,000
2560 MB	145,000
1536 MB	45,000
1024 MB	7,000

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:

• Reduce the Max Sessions limit and make sure you follow the above rules. If you reduce the Max Sessions you may need to add additional instances to support additional sessions. If you do not want to add additional instances you can use the 64-bit JRE.

• Reduce the SDK cache size. If you reduce the SDK cache size, your performance will go down. For better performance it is always better to set the SDK cache size equal to Max Sessions, and add additional instances to support more sessions.

To Tune the Notification Threadpool Size

Set the value of com.iplanet.am.notification.threadpool.size based on number of CPUs and based on the purgedelay value. See To Tune the Purge Delay Settings for related information.

• If purgedelay is set to 0, the threadpool should be set using the following formula: (number of CPUs) x 3 = threadpool size. For example, for a machine with 8 CPUs, the threadpool size is 24. For CMT T1, T2, and T2 plus machines, use the formula: (number of cores) x 3 = threadpool size. The amtune tool sets this value based on the above rules, when purgedelay is set to 0, which is the default setting.

• If the purgedelay value is set to greater than 0, then the threadpool should be set using the following formula: (number of CPUs) x 4 = threadpool size . For CMT T1, T2, and T2 plus machines, use the formula: (number of cores) x 4 = threadpool size. The notification threadpool size should be set manually by a multiple of 4 times the number of CPUs or cores. With this setting, if you still see problems such as frequent "Cannot send notification" or "Notification task queue full" errors in the amSession debug file, this indicates that the SessionNotificationqueue is full. The problem could be related to the Policy Agent or SDK client which is receiving notifications. The Policy Agent or SDK client is not able to process notifications properly. Consider disabling notification mode on the Policy Agent.

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.

• In almost all deployments, purgedelay should be set to 0. The amtune tool will set the value to 0 when run.

• In special cases when the purgedelay value is greater than 0, reduce the number of active sessions (com.iplanet.am.session.maxSessions). Additionally, increase the notification threadpool size (com.iplanet.am.notification.threadpool.size)

The property com.iplanet.am.session.maxSessions 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 com.iplanet.am.session.maxSessions. 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.