This guide provides performance tuning information for Sun JavaTM 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 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:
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.
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 TuningChapter 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.
The Sun JavaTM 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:
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:
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 |
---|---|
Wrapper script that calls other scripts based on values in the amtune-env file. |
|
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-oswill 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. |
Tunes the Sun Java System Web Server 6.1 2005Q4 SP5 web container. |
|
Tunes the Sun Java System Application Server Enterprise Edition 8.2 Web container. |
|
Tunes the Sun Java System Application Server 7 Web container. |
|
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. |
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.
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.
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.
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).
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:
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 |
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.
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.
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.
The following table describes the specific parameters for tuning Access Manager.
Table 2–2 Access Manager Tuning Parameters
Parameter |
Description |
---|---|
Sets the tuning mode to one of the following:
Default: REVIEW |
|
Tunes the operating system kernel and TCP/IP settings. Default: true |
|
Generates a script to tune the Directory Server that supports Access Manager. Default: true |
|
Tunes the Access Manager web container, which can be either Web Server or Application Server. Default: true |
|
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 |
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 |
|
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:
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 |
|
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. |
Specifies whether session time-out tuning using the next three parameters is enabled. To enable, set to false. Default: true |
|
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. |
|
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. |
|
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. |
The following table describes the Access Manager installation environment tuning parameters.
The OSTYPE, OSPLATFORM, and HWPLATFORM parameters are used to construct other parameters, so you should not need to change their values.
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 |
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
Sun JavaTM 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.
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:
The following table describes the Directory Server tuning parameters in the amtune-env configuration file.
Table 3–1 Directory Server Tuning Parameters
Parameter |
Description |
---|---|
Generates a script to tune the Directory Server that supports Access Manager. Default: true |
|
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 |
|
Specifies the location of the RAM disk. Default: /tmp |
|
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 |
The amtune-prepareDSTuner scripts generates the amtune-directory script, which you can then use to tune Directory Server. This chapter describes:
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.
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.
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.
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.
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.
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.
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.
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 |
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.
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.
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.
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.
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.
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.
To tune for maximum performance on Linux systems, you need to make tuning adjustments to the following items:
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
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.
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.
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).
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.
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
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
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
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
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
Consider making the following changes:
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
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"
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
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