Importance of sizing the thread pools correctly - #explainBestPractices mini-series

This article discusses the importance of thread pools. This assumes a standard deployment including an IHS and Maximo JVMs. It greatly simplifies the processes / elements involved.

It is important to follow IBM's recommendations as outlined in the best practice document.

Incorrectly sized thread pools can lead to a number of problems particularly poor response times for users.

When a user performs an action the following happens:

1.      Browser forms a HTTP request

2.      Browser passes request to the IHS (IBM HTTP Server)

3.      IHS checks request to see if it can handle it e.g. provide attachment

4.      IHS Forwards the request to WAS (Websphere Application Server) if WAS needs to handle it

The IHS and WAS processes use threads that perform the work. These threads perform series of operations and return results e.g. a page or an attachment.

The threads are organised in thread pools which are dedicated to specific purposes e.g. handling requests submitted over the web (HTTP/HTTPS) and other tasks e.g. crontasks.

When the IHS or WAS receives work they check if their thread pools contain idle threads in the relevant pool. If an idle thread is available then it will be given the work to process.

If an idle thread is not available then the request will be delayed until a thread is available or until the request times out. A user session can display to a white screen when this happens or the tab on the browser can change behaviour e.g. IE will display a spinning wheel on the tab.

It is important to ensure that the processes have sufficient threads available to handle the load. The Best Practices for system performance guide recommends the sizes that should be set for these pools. The settings are recommendations and organisations may want to tweak them further for their situations.

A common mistake is to apply the Websphere thread pool settings but not to update the IHS settings. If the IHS settings are too low then Websphere could have threads that are idle.

It is possible to monitor the number/status of the threads in the components so resources can be adjusted accordingly. Vetasi's standard build include the functionality/settings to make this visible and allow system administrators to tune their system accordingly.

The highest number of threads IBM recommend for Websphere is 150. Each thread requires memory and CPU to perform its work. Dramatically increasing the size of the pools could cause other problems e.g. poor performance due to lack of memory or because a JVM has hit a CPU usage limitation.

I will discuss memory requirements in a future blog article.

A thread pool of 150 threads doesn't mean that a JVM can handle 150 users. Any given user session could use up multiple threads. I have seen busy start centres that have generated requests that have used 10 threads simultaneously. I discuss the problems that start centres can cause in this blog posting.

Vetasi advice

I have dramatically improved the performance on a number of systems by implementing IBM's recommendations and then following up with detailed analysis of other problems.

If you are worried that your thread pools are not sized appropriately then do the following:

• Check the Maximo logs for BMXAA6720W log entries indicating Slow SQL statements – this indicates that Maximo did receive the request and that the problem could be elsewhere e.g. the database
• Ensure that the installation has enough JVMs to handle the required load. IBM recommend a maximum of 50 users per JVM. I discuss monitoring the number of users in this blog article - BMXAA8612I – User login counts
• Investigate which users were logged in at the time and what they were doing – Vetasi supported customers can gather this information using our standard tools. Our log analyser will read the relevant entries and advise on potential problems
• Contact Vetasi to analyse your logs and provide an analysis on potential problems/solutions. Vetasi Support customers just need to raise a support call for this.
• Consider attending Vetasi's Websphere concepts course that teaches administrators how Websphere interacts with Maximo and the key things to consider.

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

If you like this article then please share or like it.

Whilst I support the wider Maximo community and encourage the spread of knowledge, when republishing content from this blog please include the originating author along with the article or parts of.

If people do find parts of this blog coming up in blogs/newsletters/communications then please contact me directly. I’m happy to connect on LinkedIn to discuss.

Disclaimer

The postings on this blog are my own and don't necessarily represent Vetasi's positions, strategies or opinions.

The materials on this site are provided "AS IS" and the author will not be liable for any direct, indirect or incidental damages arising out or relating to any use or distribution of them. Readers are advised to test any changes/recommendations thoroughly before use