Why collecting the Websphere "MustGather" data for opening a performance PMR really is beneficial
RickRhea 060000AVGB Comment (1) Visits (4108)
So, you think you have a performance issue that requires opening a PMR with IBM Maximo support. You open the PMR, and the first thing that comes back is, "Please provide the MustGather information".
We're all in a hurry these days, and it seems like such a hassle to provide this info. However, read on, and I'll explain why the MustGather data for your Application and HTTP Server(s) can provide invaluable insight into your environment for solving performance issues.
Just to recap, the data you are asked to collect for your Application and HTTP Server(s) consists of the following information:
So, now that we've taken the time to gather this information, how can it be used to resolve potential performance issues related to WAS / IHS?
Different operating systems can be tuned differently, so it's helpful to know whether the application server is running on AIX, Windows, Linux, etc. Knowing if the OS and WAS are both 64-bit determines whether or not the JVM heap size can be larger than what's available on 32-bit operating systems. And, some folks prefer to run the 32-bit version of WAS even if the OS is 64-bit. Also, understanding the version of WAS / IHS installed can help rule out known issues with back-level releases of the middle-ware. Similarly, knowing the CPU, memory, and disk info can indicate whether or not the hardware has the capability to handle the application server load. Lastly, there are special considerations that must be taken into account when the environment is virtualized.
Many performance issues can be traced to the system not properly load balancing across JVMs or servers. There are many ways to do load balancing, so understanding whether hardware or software is used can be important. Likewise, knowing if IBM HTTP Server with it's WAS plug-in is being used and what policy for load balancing has been chosen can be important factors in diagnosing load balancing issues.
Bottlenecks can occur at any point in the solution, so knowing if single sign-on or LDAP group synchronization is used can be important to rule out potential issues in those areas.
The Best Practices for System Performance white paper highly recommends that you setup multiple clusters to handle the various types of processing that come into the system. The main goal is to ensure that the JVMs servicing the user interface requests aren't being bogged down by log running escalations or reports. Similarly, you want integration processes to be free from the UI when performing their transactions. Knowing the cluster architecture decisions that have been made can help pinpoint issues that may be related to various types of processes conflicting with one another. Once the overall architecture is understood, it is important to know how each cluster is configured, the number of servers involved in each cluster, the number of JVMs used, etc.
Analyzing the SystemOut.log and SystemErr.log can uncover many issues at the application server level that could affect performance. With verbose garbage collection enabled, the native_std_err.log shows any potential garbage collection issues that can have a negative effect on performance.
As you can see, all of the requested "MustGather" information can be used to understand the architecture, environment, and configuration to diagnose potential performance issues. So, next time you suspect you have an issue related to WAS / IHS, know that the time taken to collect this information is well worth the effort!