Sun OpenSSO Enterprise 8.0 Performance Tuning Guide

About the amtune Tool

The OpenSSO Enterprise amtune tool enables you to tune the major components of your deployment. In previous versions of OpenSSO (known as Sun Java System Access Manager), a collection of amtune shell scripts was used to do the tunings. In OpenSSO Enterprise, the amtune tool is a Java application. Before you can use the amtune tool, the following conditions must be met:

The following table lists the components tuned by the amtune tool.

Table 2–1 Components Tuned by the amtune Tool


What Gets Tuned 

OpenSSO Enterprise  

  • Session entries

  • Logging buffer

  • Notification thread pool/queue

  • LDAP connection pool sizes for service management, global authentication service and user data store

Sun Web Server 7  

Sun Application Server 9.1 and GlassFish v2 

  • JRE heap and JRE per-thread stack sizes

  • JVM garbage collection algorithms

  • Container worker and acceptor threads and queue sizes

Sun Java System Directory Server 5.2 and 6.3 

  • Worker threads

  • Database cache and entry cache sizes

The amtune tool changes the database home directory to a RAM disk location such as /tmp.


  • The operating system (OS) kernel

    Solaris and Linux platforms only.

  • TCP parameters

The amtune tool relies on a list of DO NOT MODIFY parameters in the last section of the file. The parameters in that section are mainly for internal use by amtune. Do not modify the parameters in the DO NOT MODIFY list unless user tests show significant improvement in performance.

Using a Password File

Execute amtune or amtune.bat with a file that contains passwords for the servers in your deployment. Use the following strings:



Sun OpenSSO Enterprise 8.0 


Sun Web Server 7.0 


Sun Application Server 9.1 


Sun Directory Server 


For sample entries, see the sample passwords file. The file amtune-samplepasswordfile is located in the directory:


where amtune/amtune.bat and are also located.

On Solaris, Linux, and AIX, the password file must be inaccessible to non-owners and only readable by its owner . For example, you can change the permissions mode of the password file by running the following command:

chmod 400

On Windows, amtune.bat does not check the permission on the password file.

Tuning operating system parameters does not require a password file.

Using amtune Modes

You can run the amtune tool in REVIEW mode (the default) or in CHANGE mode, as determined by the AMTUNE_MODE parameter in the file.


This is the default value. Returns tuning recommendations for an OpenSSO Enterprise deployment, but does not make any actual changes to the environment.


Makes all tuning modifications defined in the file. Use CHANGE mode only after you have reviewed and understand the tuning changes that will be applied to your deployment.

In either mode, the tool returns a list of tuning recommendations to the terminal window and to the following log file: <TOOLS_DIR>\<OPENSSO_URI>\logs\amtune-config.<timestamp>.log

Any error messages due to missing or invalid data in the file are displayed in the terminal window and written to the following file: <TOOLS_DIR>\<OPENSSO_URI>\logs\amtune-errors. All other error messages triggered by underlying components such as OpenSSO Enterprise or Sun Web Server are also written to the amtune-errors file.

Tuning the Operating System

The amtune tool tunes the operating system parameters only on Solaris and Linux. It does not tune the operating system parameters on AIX, Windows, MacOS or BSD variants.

Linux OS

To tune for maximum performance on Linux systems, make tuning adjustments to the following items:

For detailed information on tuning Linux operating system parameters, see the IBM Linux Performance and Tuning Guidelines.

File Descriptors

You might need to increase the number of file descriptors from the default. A higher number of file descriptors ensures that the server can open sockets under high load and not abort requests coming in from clients. Start by checking system limits for file descriptors with this command:

cat /proc/sys/fs/file-max

The current limit shown is 8192. To increase it to 65535, use the following command (as root):

echo "65535" > /proc/sys/fs/file-max

To make this value survive a system reboot, add it to /etc/sysctl.conf and specify the maximum number of open files permitted:

fs.file-max = 65535

The parameter is not proc.sys.fs.file-max, as you might expect.

To list the available parameters that can be modified using sysctl:

sysctl -a

To load new values from the sysctl.conf file:

sysctl -p /etc/sysctl.conf

To check and modify limits per shell, use the following command:

ulimit -a

The output will look something like this:

cputime         unlimited
filesize        unlimit
datasize        unlimited
stacksize       8192 kbytes
coredumpsize    0 kbytes
memoryuse       unlimited
descriptors     1024
memorylocked    unlimited
maxproc         8146
openfiles       1024

The open files and descriptors show a limit of 1024. To increase the limit to 65535 for all users, edit /etc/security/limits.conf as root, and modify or add the nofile setting (number of file) entries:

*         soft    nofile                     65535
*         hard    nofile                     65535

The asterisk (*) is a wildcard that identifies all users. You can also specify a user ID instead.

TCP Settings

To tune the TCP/IP settings, follow these steps:

  1. Add the following entry to /etc/rc.local:

    echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
          echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
          echo 75 > /proc/sys/net/ipv4/tcp_keepalive_intvl
          echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
  2. Add the following to /etc/sysctl.conf:

          net.ipv4.ip_local_port_range = 1204 65000
          net.core.rmem_max = 8388608
          net.ipv4.tcp_rmem = 4096 131072 8388608
          net.ipv4.tcp_wmem = 4096 131072 8388608
          net.ipv4.tcp_sack = 0
          net.ipv4.tcp_timestamps = 0
          net.ipv4.tcp_window_scaling = 0
          net.ipv4.tcp_keepalive_time = 60
          net.ipv4.tcp_keepalive_intvl = 75
          net.ipv4.tcp_fin_timeout = 30
  3. Add the following as the last entry in /etc/rc.local:

    sysctl -p /etc/sysctl.conf

  4. Reboot the system.

Tuning JRE Heap Sizes

The amtune tool restarts the server to check its JVM mode and to determine how much heap size is available for setting OpenSSO cache and session entries. For other web containers, the amtune tool supports only 32-bit JRE. For other web containers, $WEB_CONTAINER and $CONTAINER_INSTANCE_DIR values are not required.

Although the amtune tool does not tune non-Sun web containers, it will tune OpenSSO parameters if $AMTUNE _TUNE_OPENSSO is set to true.

By default, the amtune tool runs based on the assumption that the following amount of memory (megabytes) is available for tuning OpenSSO when the web container (both Sun and non-Sun) is running with 32-bit JRE:

The amtune tool also tunes OpenSSO Enterprise when it is deployed on WebSphere 6.1 and 7, and on AIX, although it does not tune IBM AIX system parameters or WebSphere container parameters.

For 64-bit JRE, the amtune tool limits the initial heap size (-Xms) to 12 GB for Web Server 7, and for Application Server 9.1 and GlassFish v2. If the Solaris operating system has at least twice as much virtual memory (swap space) as the desired initial JVM heap size, the initial heap size can be increased manually. There is no limit for the maximum heap size (-Xmx).

Using 64–bit JRE, the user session cache size and number of sessions are calculated by the amtune tool. The results can be many times more than those calculated for 32–bit JRE, depending upon available memory. Be sure to review these numbers and determine whether or not they are apropriate.

Tuning Third-Party Containers

For 32-bit Sun JRE 1.5 on Solaris 10 (both Sparc and x86), the following JVM options can be used as an example. The actual heap sizes should be adjusted based on the available physical memory, other processes running and the presence of any other active web applications running in the same JVM as OpenSSO.


If JRE 1.6 is used, the following diagnostic JVM options can be added:

For more information on troubleshooting JRE 6 deployment, see “Troubleshooting Java SE 6 Deployment”.

For more efficient garbage collection processing of soft reference objects, add the -XX:+DoEscapeAnalysis JVM option which is available with JDK 1.6.0_14 and later versions. To improve the performance of 64–bit JRE, add the -XX:+UseCompressedOops JVM option which is available with JDK 1.6.0_14 and later versions. This option compresses object references to 32 bits of the 64–bit JRE heap if the total heap is less than 32GB in size, reducing the amount of data that the HotSpot garbage collection engine must process.

Note –

The Escape analysis-based optimization option -XX:+DoEscapeAnalysis is disabled in JDK 1.6.0_18. This option will be restored in a future Java SE 6 update. For more information on these two options, see “Java SE 6 Update Release Notes.”

For WebLogic Application Server, increase the MaxPermSize from the default value of 128m to 256m in as shown below:

"if [ "${JAVA_VENDOR}" = "Sun" ] ; then
       MEM_ARGS="${MEM_ARGS} ${MEM_DEV_ARGS} -XX:MaxPermSize=256m"
       export MEM_ARGS

Otherwise, WebLogic Application Server may not start up with OpenSSO Enterprise 8.0 deployed.