EditAttachPrintable
r28 - 2013-12-12 - 15:39:30 - TimFeeneyYou are here: TWiki >  Deployment Web > DeploymentConfiguringAndTuning > ConfiguringAndTuningWAS

uc.png Configuring and tuning WebSphere Application Server (WAS)

Authors: StevenBeard, GrantCovell, TimFeeney
Build basis: Jazz applications and environments

This topic page will cover specific guidance and best practice for tuning WAS for Jazz applications and environments. General WAS top tuning recommendations will cover non-Jazz specific WAS tuning.

Monitor, Monitor, Monitor

The recommendations below should be vetted and regularly reviewed based on data collected by systematic deployment monitoring.

Review the default WAS settings

Review the instructions at Setting up WAS.

Review the default JVM settings

Be sure you are starting with the minimum recommended JVM settings.

  • -Xmx4G - This is the maximum JVM heap setting. It should be no more than half of the available memory on the computer that hosts the Jazz application. In this example, it is set to 4 GB, which assumes that you have at least 8 GB of memory on the computer that hosts this Jazz application instance.
  • -Xms4G - This is the minimum JVM heap setting. It should be set to the same value as the maximum JVM heap setting.
  • -Xmn512M - This is the maximum "nursery" size. It is prudent to add this setting for older versions of WAS (7.X and lower). But starting in WAS 8.0 the JVM makes very good decisions on nursery size, so this should not generally be set.
    • Older versions of WAS (7.X and lower) - This should be set to 1/8 of what your settings for the maximum and minimum JVM heap are. In some situations (usually validated by close examination of JVM garbage collection logs), this value may be increased to 1/4 the max and min JVM heap settings.
    • There are customers whose first tuning action is to add RAM to their server and correspondingly increase the JVM heap settings.

  • -Xgcpolicy:gencon - This is the garbage collection policy that the JVM uses. Use "gencon", and don't make changes unless you have read about and fully understand JVM garbage collection and how it impacts the performance of the Jazz applications. This is the default for WAS 7 and newer.
  • -Xcompressedrefs - This indicates use of compressed references in the JVM. Use this setting unless explicitly told otherwise.

Additionally, on all platforms but not AIX:

  • -Xgc:preferredHeapBase=0x100000000 - This is the preferred base address of the heap. Use this setting unless explicitly told otherwise.

If you are not using IPv6, consider disabling IPv6 support in the JVM:

  • -Djava.net.preferIPv4Stack=true - This setting tells the JVM to only use IPv4.

Consider using enabling large page sizes if your version of WAS doesn't already support them by default. If you are using Java 7 in WAS 8.5.0.2 or greater this setting is automatic.

  • -Xlp - Note that if your operating system doesn't also support large pages Java will not start with this setting enabled. For example, on Linux, Large pages need to be configured both in the Linux kernel and in the JVM.

Review the WebContainer thread pool settings

  • The default WAS WebContainer thread pool settings are a minimum and maximum size of 50. We suggest to set the minimum and maximum size to 200 for Jazz applications. Realize that increase threads may increase memory consumption and may push a greater amount of load onto the database. As is the case whenever you change any setting, be sure to monitor the rest of the environment in case there are side effects.

Review the JDBC connection and mediator pool settings

  • The recommendation is to set JDBC Connection pool size and mediator pool size to the value of max_clients * 25. max_clients is the estimated number of concurrent users making requests. max_clients is not equivalent to the estimated number of concurrent (or actively logged in) users. max_clients is usually around 10% of the estimated number of currently logged in users. The default value is 128.

Adjust the LPTA token timeout

Sometimes you may see many LPTA token timeout errors in the WAS logs (systemOut.log). These are caused by the LTPA (which provides SSO authentication capabilities) tokens being either expired or corrupted. These errors can be addressed in three different ways:

  1. Force the token to be reestablished
  2. Adjust the LTPA timeout
  3. Do nothing and live with the errors

For more information, see LTPA Token Expired error in WebSphere Logs with Rational Team Concert on the IBM Support website. The reason why you might want to address this issue is that the WebSphere logs can grow quite large as multiple entries are produced every second.

Solution 1: Force token

You can remove the LTPA Tokens which should eliminate the duplicate messages. To do this do the following:

  • Stop WAS
  • Remove the LTPA key at WAS_HOME/profiles/profileName/config/cells/cellName/nodes/nodeName/ltpa
  • Restart WAS

Solution 2: Adjust LTPA timeout

Adjust the LPTA timeout by following these steps:

  • Launch WebSphere Admin Console to start the WAS Console.
  • In the WAS Console navigation pane click Security > Global security.
  • In the Authentication area of the Global security page click the LTPA link.
  • In the LTPA timeout area of the LTPA page edit the value for the LTPA timeout from the default of 120 minutes to an arbitrarily large number and click OK.
  • In the Messages area at the top of the Global security page click the Save link and log out of the WAS Console.

Follow these steps only on the application nodes.

Setting the WAS WebContainer to synchronous mode

Problem (abstract)

The WebContainers use of asynchronous data transfer may use a large number of buffers in native memory to write an application response. This predominately occurs when large application responses are being transferred (for example a PDF, large images, the DMGR updating the nodeagents, etc.) but may also occur with normal size application responses. If the amount of native memory used by this is too large we can enable synchronous mode which will reduce the amount of memory used to store responses.

Most instances where it has been necessary to set channelwritetype to synchronous have involved addressing performance issues related to Rational Team Concert SCM and Build. It is not the case that all Team Concert environments will need this setting.

For further information, see the Setting the WAS WebContainer to synchronous mode troubleshooting technote on the IBM Support Portal.

Related topics: General WAS top tuning recommendations

External Links:

Additional contributors: DanToczala, Kevin Arhelger, KevinZemanek

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r32 | r30 < r29 < r28 < r27 | More topic actions...
Deployment.ConfiguringAndTuningWAS moved from Deployment.TuningWAS on 2013-11-30 - 17:09 by Main.sbeard -
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.