Resolving Memory Issues

The amtune script 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, tune the following parameters:

• com.iplanet.am.sdk.cache.maxSize

  User cache/SDK cache.

• com.iplanet.am.session.maxSessions

  Max Active Session the system should allow.

• com.iplanet.am.notification.threadpool.size

  Number of threads to process session notifications.

• com.iplanet.am.notification.threadpool.threshold

  Notification Queue size.

• com.iplanet.am.session.purgedelay

  Number of minutes to delay the purge timed-out session.

All the parameters listed above can be tuned by editing the AMconfig.properties file which is located in under /etc/opt/SUNWam/config if installed using the JES installer. If the Access Manger is installed using the single WAR, than AMConfig.properties is located in directory you specified when you configured the WAR file.

The minimum required JVM heap size for Access Manager is 1024 mb.

Tuning com.iplanet.am.session.maxSessions

The tuning of this property entire depnds on the JVM Heap size configured in the web container where the Access Manager is deployed. The minimum required JVM heap size for Access Manager is 1024 mb and the # of sessions supported for 1024mb is 12000 and every additional 512mb can support upto 18000 sessions.

Tuning com.iplanet.am.sdk.cache.maxSize

The sdk cache size should be same as the value set for com.iplanet.am.session.maxSessions.

Tuning com.iplanet.am.notification.threadpool.threshold

This is the Notification Queue size. The Notification Queue size should be less than or equal to 30% of the Max Sessions.

The following table lists sample settings for the parameters listed above based on the rules described above.

The above 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 64bit JVM.

• 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 Settingsfor 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. ForNiagra T1000/T2000 machines, use the formula: (number of cores) x 3 = threadpool size.

• 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 . ForNiagra T1000/T2000 machines, use the formula: (number of cores) x 4 = threadpool size. The amtune script currently does not set this value based on the above rules. This configuration should be done manually. With the above setting if you still see problems such as frequent "Cannont send notification" or "Notification task queue full" errors in the amSession debug file, this indicate 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 script 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 AccessManager 7.1sp1 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 3136mb. 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.