Sun Java System Access Manager 7.1 Performance Tuning and Troubleshooting Guide

Part I Basic Performance Tuning

Chapter 1 Introduction to Access Manager Tuning

This guide provides performance tuning information for Sun Java^TM System Access Manager, including how to run the Access Manager tuning scripts. You can run these scripts to tune Access Manager and its related components.

Before You Begin

Before you use this guide, Access Manager and other Sun Java Enterprise System component products such as Directory Server, Web Server, and Application Server must be installed. For information about installing these products, see the one of the following books:

Caution –

Tuning Access Manager and its related components is an iterative process that can vary for different deployments. The Access Manager tuning scripts try to apply the optimal tuning parameter settings. However, each deployment is unique and might require further customization to suit specific requirements.

You can run the Access Manager tuning scripts in two modes:

REVIEW mode (default): The scripts return tuning recommendations in the amtune debug log file, but they do not make any actual changes to the deployment.
CHANGE mode: The scripts make the tuning changes to the deployment that are defined in the amtune-env file.

Therefore, it is recommended that you first run a script in REVIEW mode and check the recommended changes in the debug log file. Run a script in CHANGE mode only after you have reviewed the recommended tuning changes that will be applied to your deployment.

Tuning Access Manager and Other Components

This guide includes the following information:

Chapter 2, Access Manager Tuning Scripts describes how to run the Access Manager tuning scripts.
Chapter 3, Directory Server Tuning describes how to tune Sun Java System Directory Server.
Chapter 4, Distributed Authentication UI Server Tuning Chapter 4, Distributed Authentication UI Server Tuning describes tuning considerations for a Distributed Authentication UI server.
Chapter 5, Tuning Considerations provides considerations for the Solaris OS, Linux OS, and third-party web containers, including IBM WebSphere Application Server and BEA WebLogic Server.

Chapter 2 Access Manager Tuning Scripts

The Sun Java^TM System Access Manager 7.1 tuning scripts allow you to tune Access Manager and other components of your deployment, including Sun Java System Directory Server, the web container running Access Manager, and the operating system (OS) kernel and TCP/IP parameters.

This chapter includes the following topics:

Overview of the Access Manager Tuning Scripts

The Access Manager tuning scripts are non-interactive. To run a script, you first edit the parameters in the amtune-env configuration file to specify the tuning options you want to set for your specific environment. Then, you run either the amtune script, which calls other scripts as needed, or a specific script. For example, you might run only the amtune-identity script to tune only Access Manager.

The Access Manager tuning scripts and the amtune-env configuration file are installed in the following directory, depending on your platform:

Solaris systems: AccessManager-base/SUNWam/bin/amtune
Linux systems: AccessManager-base/identity/bin/amtune
Windows systems: javaes-install-directory\identity\bin\amtune

AccessManager-base is the Access Manager 7.1 base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.

On Windows systems, the default value for javaes-install-directory is C:\Program Files\Sun\JavaES5.

The following table describes the tuning scripts that are available in the Access Manager 7.1 release. See also Tuning Scripts for Windows Systems.

Table 2–1 Access Manager Tuning Scripts


Script	Description
`amtune`	Wrapper script that calls other scripts based on values in the `amtune-env` file.
`amtune-identity`	Tunes the installed instance of Access Manager. Before you run the `amtune-identity` tuning script, it is recommended that you add the following property set to `false` to the `AMConfig.properties` file: `com.sun.identity.log.resolveHostName=false` A value of `false` minimizes the impact of resolving host names and thus can improve performance. (However, if you want the client machine's hostname to be printed in the `amAuthentication.access` log, set the value to `true`.) This script supports Web Server in JVM 64-bit mode. If Web Server 7.0 is the web container, it determines if Web Server 7.0 is running in 64-bit or 32-bit mode and then calculates the tuning parameters accordingly.
`amtune-os` Not available on Windows systems	Tunes the operating system kernel and TCP/IP parameters for both the Solaris OS and Linux OS. The script determines the OS type from the `uname -s` command. The `amtune-os`will not run if the wrapper `amtune` script is run in a global zone on Solaris 10 or higher.
`amtune-ws7`	Tunes the Sun Java System Web Server 7.0 web container. This script supports Web Server in JVM 64-bit mode. It determines if Web Server 7.0 is running in 64-bit or 32-bit mode and then calculates the tuning parameters accordingly.
`amtune-ws61`	Tunes the Sun Java System Web Server 6.1 2005Q4 SP5 web container.
`amtune-as8`	Tunes the Sun Java System Application Server Enterprise Edition 8.2 Web container.
`amtune-as7`	Tunes the Sun Java System Application Server 7 Web container.
`amtune-prepareDSTuner`	Generates the `amtune-directory` script, which you can use to tune the Directory Server that supports Access Manager. For more information, see Chapter 3, Directory Server Tuning.

Tuning Scripts for Windows Systems

Access Manager 7.1 includes tuning scripts for Microsoft Windows systems. Running the tuning scripts on a Windows system is similar to running the scripts on a Solaris system or Linux system, with these differences:

The Windows scripts are written in Perl and require Active Perl 5.8 to run.
A script to tune the Windows operating system is not available.
Before running a script, you must set the $BASEDIR parameter in the amtune-env.pl file to the Access Manager installation directory.
If you are tuning Directory Server, after running the amtune-prepareDSTuner.pl script, you must copy the amtune-utils.pl, amtune-directory.pl, and amtune-samplepasswordfile files to the Directory Server system.
Support for zones is not provided.

Tuning Modes

The Access Manager tuning scripts can run in the following modes, as determined by the AMTUNE_MODE parameter in the amtune-env file.

REVIEW mode (default). The scripts return tuning recommendations for an Access Manager deployment, but they do not make any actual changes to the environment.
CHANGE mode. The scripts make all of the tuning modifications that are defined in the amtune-env file, except for Directory Server. For information, see Chapter 3, Directory Server Tuning.

In either mode, the scripts return a list of tuning recommendations to the amtune debug log file and the terminal window. The location of the log file is determined by the com.iplanet.services.debug.directory parameter in the AMConfig.properties file. The default debug directory depends on your platform:

Solaris systems: /var/opt/SUNWam/debug
Linux and HP-UX systems: /var/opt/sun/identity/debug
Windows systems: javaes-install-directory\identity\debug where the default value for javaes-install-directory is C:\Program Files\Sun\JavaES5.

Caution –

Tuning is an iterative process that can vary for different deployments. The Access Manager tuning scripts try to apply the optimal tuning parameter settings. However, each deployment is unique and might require further customization to suit specific requirements.

Therefore, it is recommended that you first run a script in REVIEW mode and check the recommended changes in the amtune debug log file. Run the scripts in CHANGE mode only after you have reviewed the recommended tuning changes that will be applied to your deployment.

Running an Access Manager Tuning Script

To run a tuning script, use the following syntax:

amtune-script admin_password dirmanager_password [ as8_admin_password ]

The tuning script parameters are:

amtune-script is one of the tuning scripts: amtune, amtune-identity, amtune-os, amtune-ws61, amtune-as7, amtune-as8, or amtune-prepareDSTuner.
admin_password is the Access Manager Administrator password.
dirmanager_password is the Directory Manager (cn=Directory Manager) password.
as8_admin_password is the Administrator password that is required if you are tuning Application Server 8 (WEB_CONTAINER=AS8).

To run a tuning script:

Follow these basic steps to run an Access Manager Tuning script.

If you have not run the script in REVIEW mode, ensure that AMTUNE_MODE=REVIEW (which is the default value) in the amtune-env file.

Edit other parameters in the amtune-env file, depending on the components you want to tune and the requirements for your deployment:
- Access Manager Tuning Parameters
- Installation Environment Tuning Parameters
- Web Server 7.0 Tuning Parameters, if Web Server 7.0 is the web container
- Application Server 8 Tuning Parameters, if Application Server 8 is the web container
To tune the Directory Server that supports Access Manager, see Chapter 3, Directory Server Tuning.

In REVIEW mode, run either the amtune script or one of the component scripts.

Review the tuning recommendations in the debug log file. If needed, make changes to the amtune-env file based on this run.

If you are satisfied with the tuning recommendations from the REVIEW mode run, set AMTUNE_MODE=CHANGE in the amtune-env file.

In CHANGE mode, run either the amtune script or one of the component scripts.

For example, to tune the Solaris OS, run the amtune-os script, as follows:
# ./amtune-os admin_password dirmanager_password
Note –
In CHANGE mode, the amtune script might need to restart the web container and Access Manager. In some instances, amtune might also recommend a system restart.

Check the debug log file for the results of the run.

Consideration for the `com.iplanet.am.session.purgedelay` Property

This property specifies the number of minutes to delay the purge session operation. The value recommended by amtune is 0 or 1, depending upon the Access Manager version you're using. For clients such as Sun Java System Portal Server, a higher value may be needed. You must manually set the property after you run the amtune script:

In the AMConfig.properties file, set the property to the new value. For example:
```
com.iplanet.am.session.purgedelay=5
```
Restart the Access Manager web container for the new value to take effect.

Access Manager `amtune-env` File Parameters

The amtune-env file contains the parameters to define the tuning options for an Access Manager deployment, including:

For a description of the Directory Server parameters, see Chapter 3, Directory Server Tuning.

Access Manager Tuning Parameters

The following table describes the specific parameters for tuning Access Manager.

Table 2–2 Access Manager Tuning Parameters


Parameter	Description
`AMTUNE_MODE`	Sets the tuning mode to one of the following: REVIEW– The scripts return tuning recommendations for an Access Manager deployment but do not make any actual changes to the deployment environment. CHANGE– The scripts make all of the tuning modifications that you have defined in the `amtune-env` file, except for Directory Server. For more information, see Chapter 3, Directory Server Tuning. Default: REVIEW
`AMTUNE_TUNE_OS`	Tunes the operating system kernel and TCP/IP settings. Default: true
`AMTUNE_TUNE_DS`	Generates a script to tune the Directory Server that supports Access Manager. Default: true
`AMTUNE_TUNE_WEB_CONTAINER`	Tunes the Access Manager web container, which can be either Web Server or Application Server. Default: true
`AMTUNE_TUNE_IDENTITY`	Tunes the installed instance of Access Manager. Default: true
`AMTUNE_LOG_LEVEL`	Specifies the log level for the output of the run: `NONE` — No results will be logged or displayed. `TERM` — Display results on the terminal only. `FILE` — Display the results and log in the debug log file. Default: `FILE`
`AMTUNE_DEBUG_FILE_PREFIX`	Identifies the prefix for the `amtune` log file. If this parameter is set, all operations performed by the `amtune` scripts are logged. The location of the log file is determined by the `com.iplanet.services.debug.directory` parameter in the `AMConfig.properties` file. If Access Manager is not installed on the server, the debug log file is written to the directory when the tuning scripts exist. For example, if a Distributed Authentication UI server is deployed from a WAR file. Default: `amtune`
`AMTUNE_PCT_MEMORY_TO_USE`	Specifies the percent of available memory used by Access Manager. Currently, Access Manager can use a maximum of 4 GB, which is the per process address space limit for 32-bit applications. Access Manager requires a minimum of 256 MB RAM. When you set AMTUNE_PCT_MEMORY_TO_USE to 100, the maximum space allocated for Access Manager is the minimum between 4 GB and 100% of available RAM. When you set AMTUNE_PCT_MEMORY_TO_USE to 0, Access Manager is configured to use 256 MB RAM Default: 75 The following values are derived from this parameter setting: JVM memory usage - Heap sizes, NewSizes, PermSizes Thread pool sizes - Web Server RqThrottle, Authentication LDAP connection pool, SM LDAP connection pool, Notification thread pools Access Manager caches - SDK caches and session caches Maximum sizes - Maximum number of sessions and maximum number of cache entries AMConfig.properties File Settings Notification thread pool settings: `com.iplanet.am.notification.threadpool.size` `com.iplanet.am.notification.threadpool.threshold` SDK cache maximum size setting: `com.iplanet.am.sdk.cache.maxsize` Session settings: `com.iplanet.am.session.httpSession.enabled` `com.iplanet.am.session.maxSessions` `com.iplanet.am.session.invalidsessionmaxtime` `com.iplanet.am.session.purgedelay`
`AMTUNE_PER_THREAD_STACK_SIZE_IN_KB`	Sets the available stack space per thread in Java (Web container). The per thread stack size is used to tune various thread-related parameters in Access Manager and the Web container. Default: 128 KB Caution: Do not change this value unless absolutely necessary.
`AMTUNE_PER_THREAD_STACK_SIZE_IN_KB_64_BIT`	Sets the available stack space per thread in Java (Web container) when the script detects Web Server 7.0 is running as a 64-bit process. Default: 512 KB
`AMTUNE_MEM_MAX_HEAP_SIZE_RATIO`	Specifies the maximum heap size ratio that is used to calculate the maximum and minimum heap sizes. Default: `7/8` Note: If you are running the `amtune-ws7` script with 64-bit enabled and the system has a large memory, the script displays the current value of `AMTUNE_MEM_MAX_HEAP_SIZE_RATIO` and the maximum and minimum heap sizes calculated from this value. If these values are sufficient, you do not need to make any changes. However, in some situations, you might need to modify the value of `AMTUNE_MEM_MAX_HEAP_SIZE_RATIO`.
`AMTUNE_MIN_MEMORY_TO_USE_IN_MB` `AMTUNE_MAX_MEMORY_TO_USE_IN_MB`	Specifies the minimum and maximum memory in MB that should not be exceeded. Defaults: 512 and 3584 If Web Server 7.0 is running in a 64-bit process, the `AMTUNE_MAX_MEMORY_TO_USE_IN_MB` parameter is not used. It is recommended that you use the default values.
`AMTUNE_DONT_TOUCH_SESSION_PARAMETERS`	Specifies whether session time-out tuning using the next three parameters is enabled. To enable, set to false. Default: true
`AMTUNE_SESSION_MAX_SESSION_TIME_IN_MTS`	Sets the maximum session time in minutes. Default: 60 However, the default value might be different for your installation. If the session service is registered and customized at the any other level, the tuning will not apply. Setting this parameter to very high or very low values affects the number of active user sessions an Access Manager deployment can support, so this parameter is optional for tuning purposes. To use this parameter, AM_TUNE_DONT_TOUCH_SESSION_PARAMETERS must be set to false.
`AMTUNE_SESSION_MAX_IDLE_TIME_IN_MTS`	Sets the maximum idle time for a session in minutes. Default: 10 However, the default value might be different for your installation. If the Session service is registered and customized at the any other level, the tuning will not apply. Setting this parameter to very high or very low values affects the number of active user sessions an Access Manager deployment can support, so this parameter is optional for tuning purposes. To use this parameter, AM_TUNE_DONT_TOUCH_SESSION_PARAMETERS must be set to false.
`AMTUNE_SESSION_MAX_CACHING_TIME_IN_MTS`	Sets the maximum session cache time in minutes. Default: 2 However, the default value might be different for your installation. If the Session service is registered and customized at the any other level, the tuning will not apply. Setting this parameter to very high or very low values affects the number of active use sessions an Access Manager deployment can support, so this parameter is optional for tuning purposes. To use this parameter, `AM_TUNE_DONT_TOUCH_SESSION_PARAMETERS` must be set to false.

Installation Environment Tuning Parameters

The following table describes the Access Manager installation environment tuning parameters.

Note –

The OSTYPE, OSPLATFORM, and HWPLATFORM parameters are used to construct other parameters, so you should not need to change their values.

Table 2–3 Installation Environment Tuning Parameters


Parameter	Description
`HOSTNAME`	Specifies the host name of the system where Access Manager is deployed. If the host name for your environment cannot be obtained using the `hostname` command, comment the following line: `HOSTNAME=`’`/bin/hostname \| /bin/cut -f1 -d"."`’ Then, add a line setting the correct host name. For example: `HOSTNAME=myhost`
`DOMAINNAME`	Specifies the domain name of the system where Access Manager is deployed. If the domain name for your environment cannot be obtained using the `domainname` command, comment the following line: `DOMAINAME=’/bin/domainname’` Then, add a line setting the correct domain name. For example: `DOMAINNAME=example.com`
`IS_INSTALL_DIR`	Specifies the Access Manager installation directory. Default: blank. The tuning scripts determine the default Access Manager installation directory dynamically by the `pkginfo` or `rpm` command. If the `pkginfo` or `rpm` command fails, values are `/opt/SUNWam` on Solaris systems or `opt/sun/identity` on Linux systems. For an Access Manager WAR file deployment, the value should be blank. The `IS_INSTALL_DIR` and `IS_CONFIG_DIR` parameters are then replaced by WAR file deployment setup script.
`AMTUNE_BIN_DIR`	Specifies the location of the tuning scripts. Set this variable only if the tuning scripts are not installed in the default location. Otherwise, leave it blank. Default: `AccessManager-base/bin/amtune`
`WEB_CONTAINER`	Specifies the name of the Web container on which Access Manager is deployed: `WS7` — Web Server 7.0 `WS61` — Web Server 6.1 `AS8` — Application Server 8 `AS7` — Application Server 7 Default: `WS7` Any other value returns a validation error.
`CONTAINER_BASE_DIR`	Specifies the base directory for the Web container that is running Access Manager. If you installed the Web container in a non-default location, change this value before running `amtune`. Default values: Web Server 7.0: `/opt/SUNWwbsvr7` Web Server 6.1: `/opt/SUNWwbsvr` Application Server 7: `/var/opt/SUNWappserver7` Application Server 8 on Solaris systems `/var/opt/SUNWappserver` Application Server 8 on Linux systems `/var/opt/sun/appserver`
`WEB_CONTAINER_INSTANCE_NAME`	Specifies the instance name of the Access Manager web container. Typically, this value is the host name where Access Manager is deployed. If you have multiple instances for the Web container, this value might be different from the host name, and you must set it to the correct instance name. Defaults: Web Server 6.1 or Web Server 7.0: `hostname` (`${HOSTNAME}`) Application Server 7: `domains/server1` Application Server 8: `domains/domain1`
`IS_INSTANCE_NAME`	Specifies the Access Manager instance names. IS_INSTANCE_NAME is used to determine the properties file names for the Access Manager installation. Default: none You can deploy multiple instances of Access Manager on the same machine, but generally, there is one set of properties files for each Access Manager instance, and the instance name is appended to the file names. If there is only one instance of Access Manager on a machine, the instance name is not appended to the file name. For example, there might be a single instance of Access Manager running under the default instance of Web Server. If Access Manager is installed on a machine named `server.example.com`, typically the first instance of Web Server is `https-server.example.com`. The properties files for the first Access Manager instance will not have the instance name appended (for example, `AMConfig.properties`). Multiple Access Manager Instances Multiple instances will have different names. For example, if there are three instances of Web Server, the Web Server instances might be: `server.example.com-instance1` `server.example.com-instance2` `server.example.com-instance3` If three instances of Access Manager are deployed (one per web container instance), the primary properties file names for Access Manager (typically, `AMConfig.properties`) might be named as: `AMConfig-instance1.properties` `AMConfig-instance2.properties` `AMConfig-instance3.properties`
`IS_INSTANCE_NAME` (continued)	You can specify IS_INSTANCE_NAME=`instance1`. The `amtune` script resolves the properties file names in the following order: AMConfig-IS_INSTANCE_NAME AMConfig-WEB_CONTAINER_INSTANCE_NAME `AMConfig.properties` The script uses the first available properties file in the list. The `amadmin` utility should also point to the correct server name. Java option: `-Dserver.name=`IS_INSTANCE_NAME `amtune` automatically tries to associate the instance names with the Access Manager properties files using this parameter. Currently, only these files are based on this instance name: `AMConfig.properties` `serverconfig.xml`
`CONTAINER_INSTANCE_DIR`	Specifies the base directory for the Access Manager web container instance. If you have installed the web container in a non-default location, change this value before running `amtune`. Default values are: Web Server 6.1 or Web Server 7.0: `$CONTAINER_BASE_DIR/https-${WEB_CONTAINER_INSTANCE_NAME}` Application Server 7 or Application Server 8: `$CONTAINER_BASE_DIR/${WEB_CONTAINER_INSTANCE_NAME}`

Web Server 7.0 Tuning Parameters

The following table describes the tuning parameters that you can set when you are running Web Server 7.0 as the Access Manager web container.

Table 2–4 Web Server 7.0 Tuning Parameters


Parameter	Description
`WSADMIN`	Specifies the location of the `wsadmin` utility. Default: Solaris systems: `/opt/SUNWwbsvr7/bin/wadm` Linux systems: `/opt/sun/webserver7/bin/wadm`
`WSADMIN_USER`	Specifies the Web Server 7.0 administrator. Default: `admin`
`WSADMIN_PASSFILE`	Specifies the Web Server 7.0 temporary password file used by the `wsadmin` utility. Default: `/tmp/passfile`
`WSADMIN_HOST`	Specifies the Web Server 7.0 admin host name. Default: localhost (`$HOSTNAME`)
`WSADMIN_PORT`	Specifies the Web Server 7.0 admin port. Default: 8989
`WSADMIN_DIR`	Specifies the Web Server 7.0 installation directory.
`WSADMIN_SECURE`	Specifies whether `WSADMIN_PORT` is a secure port. `"--ssl=true"` indicates a secure port. `"--ssl=false"` indicates the port is not secure. Default: `"--ssl=true"`
`WSADMIN_CONFIG`	Specifies the Web Server 7.0 instance name. Default: `$WEB_CONTAINER_INSTANCE_NAME`
`WSADMIN_HTTPLISTENER`	Specifies the Web Server 7.0 HTTP listener name. Default: `http-listener-1`

Application Server 8 Tuning Parameters

The following table describes the tuning parameters that you can set when you are using Application Server 8 as the Access Manager web container.

Table 2–5 Application Server 8 Web Container Tuning Parameters


Parameter	Description
`ASADMIN`	Specifies the Application Server 8 `asadmin` utility location. Default values: Solaris systems: `/opt/SUNWappserver/appserver/bin/asadmin` Linux systems: `/opt/sun/appserver/bin/asadmin`
`ASADMIN_USER`	Specifies the Application Server 8 administrator user account. Default: `admin`
`ASADMIN_PASSFILE`	Specifies the temporary password file location used by the `asadmin` utility. The `amtune-as8` script creates this file and then deletes it after use. Default: `/tmp/passfile`
`ASADMIN_HOST`	Specifies the Application Server 8 `admin` host name. Default: `$HOSTNAME`
`ASADMIN_PORT`	Specifies the Application Server 8 `admin` port. Default: 4849
`ASADMIN_DIR`	Specifies the Application Server 8 installation directory.
`ASADMIN_SECURE`	Specifies whether the ASADMIN_PORT is secure: `"--secure"` specifies the port is secure. Blank specifies that the port is not secure. Default: `"--secure"`
`ASADMIN_TARGET`	Specifies whether this Application Server 8 installation is used exclusively for Access Manager and Portal Server. Default: `server`, indicating that Application Server 8 installation is exclusively used for Access Manager and Portal Server.
`ASADMIN_HTTPLISTENER`	Specifies the HTTP Application Server 8 listener name. Default: `http-listener-1`
`ASADMIN_INTERACTIVE`	Specifies whether Application Server 8 administrator operates interactively. Default: false Caution: Do not change this parameter.
`AMTUNE_WEB_CONTAINER_JAVA_POLICY`	Specifies whether Application Server 8 evaluates Java security descriptors, as specified in the `server.policy` file. Default: false Caution: Do not change this parameter. Evaluating Java security descriptors can add a significant performance overhead.

Chapter 3 Directory Server Tuning

Sun Java^TM System Access Manager 7.1 tuning scripts tune either Sun Java System Directory Server 5.2 2005Q4 or Sun Java System Directory Server Enterprise Edition 6. Access Manager must use an existing Directory Server, either local or remote, in non-exclusive mode. If your deployment has separate Directory Servers for the Access Manager configuration data and users, you must manually tune each Directory Server.

Caution –

If you are working with a production Directory Server or a Directory Server that has not been backed up (both the data and configuration), it is recommended that you do not run the amtune-directory script in CHANGE mode to apply tuning changes.

After you run the amtune-directory script in REVIEW mode, review the tuning recommendations and apply them manually, if they meet your deployment needs.

Also, make sure you back up both your Directory Server data and configuration before you make any changes.

This chapter includes the following topics:

Directory Server Tuning Parameters

The following table describes the Directory Server tuning parameters in the amtune-env configuration file.

Table 3–1 Directory Server Tuning Parameters


Parameter	Description
`AMTUNE_TUNE_DS`	Generates a script to tune the Directory Server that supports Access Manager. Default: true
`DIRMGR_UID`	Specifies the user ID of the Directory Manager. If your deployment uses a user ID other than the default value (`cn=Directory Manager`), you must set this parameter with that value. Default: `cn=Directory Manager`
`RAM_DISK`	Specifies the location of the RAM disk. Default: `/tmp`
`DEFAULT_ORG_PEOPLE_CONTAINER`	Specifies the people container name for the default organization. This parameter is used to tune the LDAP authentication module's search base. It can be useful when there are no sub-organizations in the default organization. If this value is empty (`""`), tuning is skipped. Note: Along with appending the people container to the search base, the search scope will be modified to `"OBJECT"` level. The default search scope is `"SUBTREE"`. Default: `""` (empty)
`AMTUNE_LOG_LEVEL`	Specifies the log level for the output of the run: `NONE` — No results will be logged or displayed. `TERM` — Display results on the terminal only. `FILE` — Display the results and log in the debug log file. Default: `FILE`

Directory Server Tuning Scripts

The amtune-prepareDSTuner scripts generates the amtune-directory script, which you can then use to tune Directory Server. This chapter describes:

Directory Server Indexes

The Directory Server tuning script creates the following indexes if they do not already exist:

Index for attributes that are used to search for a user to be authenticated
Indexes for the default Access Manager attributes: nsroledn, memberof, iplanet-am-static-group-dn, iplanet-am-modifiable-by, iplanet-am-user-federation-info-key, sunxmlkeyvalue, o, ou, sunPreferredDomain, associatedDomain, and sunOrganizationAlias

These attributes are indexed during installation by using the index.ldif file in /etc/opt/SUNWam/config/ldif directory on Solaris systems and /etc/opt/sun/identity/config/ldif directory on Linux systems. If for some reason, any of these attributes are not indexed, the Directory Server tuning script creates them.

For more information about indexes, see Appendix A, Directory Server Considerations, in Sun Java System Access Manager 7.1 Postinstallation Guide.

Running the Directory Server Tuning Script in REVIEW Mode

The amtune script and amtune-prepareDSTuner scripts do not actually tune Directory Server. However, you must run one of these scripts to generate the amtune-directory script, which you can then use to tune Directory Server.

Log in as or become superuser (root).
Make sure that the following parameter is set in the amtune-env file:
AMTUNE_TUNE_DS=true
Run the amtune script or amtune-prepareDSTuner script. The script generates the following tar file:

current-directory/amtune-directory.tar
Copy the amtune-directory.tar file to a temporary location on the server that is running Directory Server.
Untar the amtune-directory.tar file in the temporary location.
In the amtune-directory script, make sure REVIEW mode is set:
AMTUNE_MODE="REVIEW"
Set these parameters, if you prefer a value other than the default (amtune):
- DEBUG_FILE_PREFIX is a prefix that will be included with the timestamp to specify the filename of the log file where the script writes the recommended tuning changes.
- DB_BACKUP_DIR_PREFIX is a prefix that will be included with the timestamp to specify the name of the Directory Server backup directory.
Run the amtune-directory script in REVIEW mode. For example:
# ./amtune-directory dirmanager_password
The dirmanager_password is the Directory Manager password.
Review the recommended tuning settings for Directory Server in the debug log file.

The script creates the log file in the same directory with the tuning scripts.

Applying the Tuning Changes to Directory Server

Caution –

If you are working with a production Directory Server or a Directory Server that has not been backed up (both the data and the configuration), it is recommended that you do not run the amtune-directory script in CHANGE mode to apply to the tuning changes. Review the tuning recommendations from REVIEW mode and apply the changes manually, if they meet your deployment needs.

Before making the tuning changes, the amtune-directory script stops and backs up Directory Server.

If you are working with a pilot or prototype Directory Server and you are sure you want to apply the tuning changes, follow these steps:

Back up both your Directory Server data and configuration.
Set the following parameter in the amtune-directory script:
AMTUNE_MODE="CHANGE"
Run the amtune-directory script in CHANGE mode. For example:
# ./amtune-directory dirmanager_password
The dirmanager_password is the Directory Manager password.
Check the amtune log file for the results of the run.

The script creates the log file in the same directory with the tuning scripts.

Chapter 4 Distributed Authentication UI Server Tuning

If you have deployed a Distributed Authentication UI server, you can run the Access Manager tuning scripts to tune the Solaris or Linux operating system and the web container. Except for the amtune-identity and amtune-prepareDSTuner scripts, the tuning scripts do not require an instance of Access Manager server to run.

This chapter provides the following information:

For more information about a Distributed Authentication UI server, see Chapter 11, Deploying a Distributed Authentication UI Server, in Sun Java System Access Manager 7.1 Postinstallation Guide.

Copying the Tuning Scripts

Because Access Manager server is not installed on the system where the Distributed Authentication UI server is deployed, you must copy the following tuning scripts and files from an Access Manager 7.1 server installation:

amtune-os, if you plan to tune the Solaris or Linux OS
Appropriate web container script:
- Web Server 7.0: amtune-ws7
- Web Server 6.1 2005Q4: amtune-ws61
- Application Server Enterprise Edition 8.2: amtune-as8
- Application Server 7: amtune-as7
amtune-env configuration file and amtune-utils script

The scripts and files are available on an Access Manager server installation in the following directory, depending on your platform:

Solaris systems: AccessManager-base/SUNWam/bin/amtune
Linux systems: AccessManager-base/identity/bin/amtune
Windows systems: javaes-install-directory\identity\bin\amtune

AccessManager-base is the Access Manager 7.1 base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.

On Windows systems, the default value for javaes-install-directory is C:\Program Files\Sun\JavaES5.

Tuning the Operating System

To tune the operating system for the Distributed Authentication UI server, run the amtune-os script. This script tunes the operating system kernel and TCP/IP parameters for both the Solaris OS and Linux OS. The script determines the OS type from the uname -s command.

On Solaris 10 and higher systems, the amtune-os script will not run if the wrapper amtune script is run in a local zone.

To run the amtune-os script, you first must copy it from an Access Manager server installation, as described in Copying the Tuning Scripts.

Tuning a Distributed Authentication UI Server Web Container

After you deploy the Distributed Authentication UI server on a web container, you can tune the web container by running the appropriate web container tuning script:

Web Container	Tuning Script
Web Server 7.0	`amtune-ws7`
Web Server 6.1	`amtune-ws61`
Application Server Enterprise Edition 8.2	`amtune-as8`
Application Server 7	`amtune–as7`

To tune a Distributed Authentication UI server web container:

Make sure you have copied the necessary scripts from an Access Manager server installation, as described in Copying the Tuning Scripts.

Edit the parameters in the amtune-env configuration file to specify the specific web container and tuning options.

To run the script in REVIEW mode, set AMTUNE_MODE=REVIEW in the amtune-env file.

Run the web container tuning script in REVIEW mode.

In REVIEW mode, the tuning script suggests tuning recommendations but does not make any changes to the deployment.

Review the tuning recommendations in the output log file, which is available in the same directory as the tuning scripts.

If needed, make changes to the amtune-env file based on this run.

To run the script in CHANGE mode, set AMTUNE_MODE=CHANGE in the amtune-env file.

To make actual tuning changes to your deployment, run the script in CHANGE mode.

Check the tuning results in the output log file.

Improving Performance for the Default Application User

When you deploy a Distributed Authentication UI server using the default application user, performance can drop significantly due to the default application user's restricted privileges in Directory Server.

To improve performance for the Distributed Authentication UI server default user:

In the Access Manager console, create a new user. For example: DistAuthUIuser.

In Directory Server, add the DistAuthUIuser user with a new ACI to allow reading, searching, and comparing user attributes. An example of this new ACI is:

dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com
changetype:modifyadd:aci
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = "*"(version 3.0; acl "SunAM client data access for application user"; 
allow (read, search, compare) 
userdn = "ldap:///uid=DistAuthUIuser,ou=people,dc=example,dc=com";)

On the Distributed Authentication UI server, set the following variables in the configuration file:
```
APPLICATION_USER=DistAuthUIuser
APPLICATION_PASSWD=DistAuthUIuser-password
```
On Solaris and Linux systems, the configuration file is based on the amsamplesilent file and is named DistAuth_config in the next step. Set any other variables in the DistAuth_config file, as required for your deployment.

On Windows systems, use the AMConfigurator.properties file to create a new configuration file. For example: AMConfigurator-distauth.properties.

Run the amconfig script using the edited configuration file.

For example, on a Solaris system with Access Manager installed in the default directory:
```
# cd /opt/SUNWam/bin
# ./amconfig -s ./DistAuth_config
```
On Windows systems, in the amconfig.bat file, change AMConfigurator.properties to AMConfigurator-distauth.properties, and then run the edited amconfig.bat file.

Restart the web container on the Distributed Authentication UI server.

Chapter 5 Tuning Considerations

Note –

The following tuning considerations are based on the tuning of various test deployments. Because each deployment is unique, you might need further customization and interactive testing to satisfy your specific requirements.

Operating System (OS) Considerations

Solaris OS

Sun Fire T1000 and T2000 Servers

If Access Manager is installed on a Sun Fire T1000 or T2000 server, the tuning scripts for Web Server 7.0 and Application Server 8.2 set the JVM GC ParallelGCThreads parameter to 8:

-XX:ParallelGCThreads=8

This parameter reduces the number of garbage collection threads, which could be unnecessarily high on a 32-thread capable system. However, you can increase the value to 16 or even 20 for a 32 virtual CPU machine such as a Sun Fire T1000 server, if it minimizes full garbage collection activities.

Solaris SPARC Systems with CMT Processor with CoolThreads Technology

For Solaris SPARC systems with CMT processor with CoolThreads technology, in the /etc/opt/SUNWam/config/AMConfig.properties file, it is recommended that you add the following properties at the end of the file:

com.sun.identity.log.resolveHostName=false
com.sun.am.concurrencyRate=value

where value depends on the number of cores in a Sun Fire T1000 or T2000 server. For example, for 8 cores, set value to 8, or for 6 cores, set value to 6.

Linux OS

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

Note –

If you are running Application Server 8.1 on Red Hat Linux, the stack size of the threads created by the Red Hat OS for Application Server is 10 Mbytes, which can cause JVM resource problems (CR 6223676). To prevent these problems, set the Red Hat OS operating stack size to a lesser value such as 2048 or even 256 Kbytes, by executing the ulimit command before you start Application Server. Execute the ulimit command on the same console that you will use to start Application Server. For example:

ulimit -s 256

File Descriptors

You might need to increase the number of file descriptors from the default. Having 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
8192

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 to survive a system reboot, add it to /etc/sysctl.conf and specify the maximum number of open files permitted:

fs.file-max = 65535

Note: 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:

limit

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 openfiles 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 could also specify a user ID instead.

Then edit /etc/pam.d/login and add the line:

session required /lib/security/pam_limits.so

On Red Hat Linux , you also need to edit /etc/pam.d/sshd and add the following line:

session required /lib/security/pam_limits.so

On many systems, this procedure will be sufficient. Log in as a regular user and try it before doing the remaining steps. The remaining steps might not be required, depending on how pluggable authentication modules (PAM) and secure shell (SSH) are configured.

Virtual Memory

To change virtual memory settings, add the following to /etc/rc.local:

echo 100 1200 128 512 15 5000 500 1884 2 > /proc/sys/vm/bdflush

For more information, view the man pages for bdflush.

Network Interface

To ensure that the network interface is operating in full duplex mode, add the following entry into /etc/rc.local:

mii-tool -F 100baseTx-FD eth0

where eth0 is the name of the network interface card (NIC).

Disk I/O Settings

To tune disk I/O performance for a non-SCSI disk, follow these steps:

Test the disk speed with this command:
```
 /sbin/hdparm -t /dev/hdX
```
Enable direct memory access (DMA) with this command:
```
/sbin/hdparm -d1 /dev/hdX
```
Check the speed again using the hdparm command. Given that DMA is not enabled by default, the transfer rate might have improved considerably. In order to do this at every reboot, add the /sbin/hdparm -d1 /dev/hdX line to /etc/conf.d/local.start, /etc/init.d/rc.local, or whatever the startup script is called.

TCP/IP Settings

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

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

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 60000 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 15000 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

Add the following to /etc/sysctl.conf:

# Disables packet forwarding
net.ipv4.ip_forward = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0
net.ipv4.ip_local_port_range = 1204 65000
net.core.rmem_max = 262140
net.core.rmem_default = 262140
net.ipv4.tcp_rmem = 4096 131072 262140
net.ipv4.tcp_wmem = 4096 131072 262140
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_keepalive_time = 60000
net.ipv4.tcp_keepalive_intvl = 15000
net.ipv4.tcp_fin_timeout = 30

Add the following as the last entry in /etc/rc.local:
```
sysctl -p /etc/sysctl.conf
```
Reboot the system.
Use this command to increase the size of the transmit buffer:
```
tcp_recv_hiwat ndd /dev/tcp 8129 32768
```

Third-Party Web Containers

IBM WebSphere Application Server

Consider making the following changes in the WebSphere Administrative Console:

For more information, see the “IBM WebSphere V5.1 Performance, Scalability, and High Availability WebSphere Handbook Series” at:

http://www.redbooks.ibm.com//Redbooks.nsf/RedbookAbstracts/sg246198.html?OpenDocument

JVM Tuning Parameters

Add the JVM tuning parameters for JVM 1.4.2 shown below, by following these links in the console:

Servers>Application Servers>server1>Process Definition>Java Virtual Machine

Add “-server” as the first parameter in the “Generic JVM arguments” box. Then, add the following entries after the other existing parameters:

-XX:NewSize=336M -XX:MaxNewSize=336M
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram 
-XX:+PrintGCTimeStamps 
-Xloggc:/opt/WebSphere/AppServer/logs/server1/gc.log
-XX:-CMSParallelRemarkEnabled

If you use WebSphere 6.x with Sun JVM 1.5 or later, then some of the garbage collection (GC) algorithms can be safely removed. The following is a list of JVM options that can be used with Sun JVM 1.5 or later.

-XX:NewSize=336M -XX:MaxNewSize=336M
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+PrintClassHistogram
-XX:+PrintGCTimeStamps
-Xloggc:/opt/WebSphere/AppServer/logs/server1/gc.log
-XX:-CMSParallelRemarkEnabled

Servlet Caching

Make sure that servlet caching is enabled by checking the checkbox next to “Enable servlet caching” by following these links in the console:

Application Servers>server1>Web Container>Configuration: Servlet caching

Thread Pool Size

Allow the thread pool to grow beyond the maximum thread pool size set by checking the checkbox next to “Allow thread allocation beyond maximum thread size” by following these links:

Application Servers>server1>Web Container>Thread Pool Is Growable

BEA WebLogic Server

Consider making the following changes:

JVM GC Parameter

For BEA WebLogic Server 8.1 SP4, to avoid the java.lang.OutofMemoryError reported by the WebLogic JVM 1.4.2_05, add the following JVM GC (garbage collection) parameter in the startWebLogic.sh JAVA_OPTIONS:

-XX:-CMSParallelRemarkEnabled

Set this parameter in addition to the other heap size and GC parameters that have been added for JVM 1.4.2 for Application Server 8.1 and Web Server 6.1.

For example, if Access Manager is installed in the default user_projects location (/usr/local/bea/user_projects/domains/mydomain/startWebLogic.sh):

JAVA_OPTIONS="-XX:+DisableExplicitGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram
-XX:+PrintGCTimeStamps
-Xloggc:/usr/local/bea/user_projects/domains/mydomain/myserver/gc.log"

If you use WebLogic 9.x with Sun JVM 1.5 or later, then some of the GC algorithms can be safely removed. The following is a list of JVM options that can be used with Sun JVM 1.5 or later.

-XX:NewSize=336M -XX:MaxNewSize=336M
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+PrintClassHistogram
-XX:+PrintGCTimeStamps
-Xloggc:/opt/WebSphere/AppServer/logs/server1/gc.log
-XX:-CMSParallelRemarkEnabled

Heap Size

Modify the commonEnv.sh script in the /usr/local/bea/weblogic81/common/bin directory for heap size increases in the section where $PRODUCTION_MODE" = "true" (which should be set to true, before running Access Manager in /usr/local/bea/user_projects/domains/mydomain/startWebLogic.sh):

# Set up JVM options base on value of JAVA_VENDOR
if [ "$PRODUCTION_MODE" = "true" ]; then
  case $JAVA_VENDOR in
  BEA)
    JAVA_VM=-jrockit
    MEM_ARGS="-Xms128m -Xmx256m"
  ;;
  HP)
    JAVA_VM=-server
    MEM_ARGS="-Xms32m -Xmx200m -XX:MaxPermSize=128m"
  ;;
  IBM)
    JAVA_VM=
    MEM_ARGS="-Xms32m -Xmx200m"
  ;;
  Sun)
    JAVA_VM=-server
    MEM_ARGS="-Xms2688M -Xmx2688M -XX:NewSize=336M -XX:MaxNewSize=336M"
   # MEM_ARGS="-Xms32m -Xmx200m -XX:MaxPermSize=128m"

Execute Queue Thread Count

Set the Execute Queue Thread count to be more than the number of CPUs. For example, consider using a value that is twice the number of CPUs. Set this value in either the console or in the /usr/local/bea/user_projects/domains/mydomain/config.xml file:

<ExecuteQueueName="MyExecute Queue" ThreadCount="8" ThreadsIncrease="4"/>

For more information, see “Modifying the Default Thread Count” in “WebLogic Server Performance and Tuning” at:

http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1142218

Connection Backlog Buffering

A guideline for setting Connection Backlog Buffering is 8192 for a server with 4 Gbytes of physical memory (which is equivalent to the ConnectionQueue size tuning set in the Sun Java System Web Server 6.1 magnus.conf file).

For more information, see “Tuning Connection Backlog Buffering” in the “WebLogic Server Performance and Tuning” document at:

http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1136287

Part I Basic Performance Tuning

Chapter 1 Introduction to Access Manager Tuning

Before You Begin

Tuning Access Manager and Other Components

Chapter 2 Access Manager Tuning Scripts

Overview of the Access Manager Tuning Scripts

Tuning Scripts for Windows Systems

Tuning Modes

Running an Access Manager Tuning Script

To run a tuning script:

Consideration for the com.iplanet.am.session.purgedelay Property

Access Manager amtune-env File Parameters

Access Manager Tuning Parameters

Installation Environment Tuning Parameters

Web Server 7.0 Tuning Parameters

Application Server 8 Tuning Parameters

Chapter 3 Directory Server Tuning

Directory Server Tuning Parameters

Directory Server Tuning Scripts

Directory Server Indexes

Running the Directory Server Tuning Script in REVIEW Mode

Applying the Tuning Changes to Directory Server

Chapter 4 Distributed Authentication UI Server Tuning

Copying the Tuning Scripts

Tuning the Operating System

Tuning a Distributed Authentication UI Server Web Container

To tune a Distributed Authentication UI server web container:

Improving Performance for the Default Application User

To improve performance for the Distributed Authentication UI server default user:

Chapter 5 Tuning Considerations

Operating System (OS) Considerations

Solaris OS

Sun Fire T1000 and T2000 Servers

Solaris SPARC Systems with CMT Processor with CoolThreads Technology

Linux OS

File Descriptors

Virtual Memory

Network Interface

Disk I/O Settings

TCP/IP Settings

Third-Party Web Containers

IBM WebSphere Application Server

JVM Tuning Parameters

Servlet Caching

Thread Pool Size

BEA WebLogic Server

JVM GC Parameter

Heap Size

Execute Queue Thread Count

Connection Backlog Buffering

Consideration for the `com.iplanet.am.session.purgedelay` Property

Access Manager `amtune-env` File Parameters