You can view resource statistics by using the Resource Statistics tab in the web user interface, or you can display them in a Kibana dashboard in IBM® Cloud. You can also view them in files if you have specified that they are to be written to the file system.
This topic describes how to view resource statistics for your integration servers by using the Resource Statistics tab in the web user interface. For information about how to view them in a Kibana dashboard, see Reporting logging and statistics data to IBM Cloud Log Analysis and displaying it in a Kibana dashboard For information about resource statistics that are written to files, see Reporting resource statistics to files.
You can also view resource statistics collection by subscribing to the topic on which statistics are published. For more information, see Subscribing to event message topics.
To view resource statistics in the web user interface, complete the following steps:
Many tools that are specific to an operating system give you the total memory that is used by the integration server, but they do not show you how that memory is divided between Java processing and other processing in the integration server. By looking at the field CommittedMemoryInMB, you can see how much memory is currently allocated to the JVM. Then look at the field MaxMemoryInMB to see the maximum amount of memory that can be allocated.
To see how often the JVM is doing garbage collection, check the CumulativeNumberOfGCCollections field to see if the rate of collections is increasing. Garbage collection is a normal process, and is therefore expected to some degree. However, excessive garbage collection can affect performance.
To see whether current garbage collection is excessive, monitor the CumulativeGCTimeInSeconds value. If this value is increasing by more than 2 seconds in each 20-second statistics interval, try increasing the JVM maximum heap size for your integration server by using the mqsichangeproperties command. You might also want to inspect all the Java user-defined nodes and JavaCompute nodes that are included in your deployed message flows, to ensure that they do not create and delete many objects that could be reused; frequent deletions can contribute to excessive garbage collection.
Change these values gradually, and check the results to find the optimum settings for your environment.
A message flow parses input messages and can create many output messages. These messages might have large bit streams or large message trees. The parsers created to perform this message processing might use a large amount of memory. Use the Parsers statistics to determine whether message flow parsers are using more memory than expected. If so, consider deploying such flows into separate integration servers or improving ESQL or Java plug-in API processing to efficiently handle large messages or transformations.
If a message flow receives or attempts to write an invalid message, it is likely that this will be rejected by a parser. Use the message parsers statistics to see whether a message flow is rejecting a large amount of input or output messages compared with successful processing.
Creating outbound sockets can be an expensive operation, and the number of sockets available on a computer is a finite resource. Therefore, increasing socket reuse can enhance performance. If the workload is continuous and consistent, the TotalSockets value indicates an initial period of activity, which then reduces when the integration server starts to reuse sockets.
A steady increase in the TotalSockets value over time is expected because sockets are closed after a period of inactivity, or when they have been used many times.
If the TotalSockets value increases significantly over time, this trend might indicate that outbound sockets are not being reused.
If your message flows include HTTPRequest nodes, check that you have set the keepalive property Enable HTTP/1.1 keepalive.
Check also whether the endpoint that is called uses keepalive sockets.
The values TotalMessages indicates how busy each endpoint is. The value in the summary record tells you how much activity occurred across the whole integration server.
The values of the SentMessageSize_* and ReceivedMessageSize_* fields give a profile of the message sizes that flow to and from each endpoint.
If the statistics show that the count of callers that are waiting for connections is high, and the wait time is increasing, consider increasing the size of the pool by using the MaxConnectionPoolSize property for the JDBCProvider configurable service.
Alternatively, try reducing the number of additional instances that are configured for the message flow.
Creating outbound sockets can be an expensive operation, and the number of sockets available on a computer is a finite resource. Therefore, increasing socket reuse can enhance performance. If the workload is continuous and consistent, the TotalSockets value indicates an initial period of activity, which then reduces when the integration server starts to reuse sockets.
A steady increase in the TotalSockets value over time is expected because sockets are closed after a period of inactivity, or when they have been used many times.
If the TotalSockets value increases significantly over time, this trend might indicate that outbound sockets are not being reused.
If your message flows include HTTPRequest nodes, check that you have set the keepalive property Enable HTTP/1.1 keepalive.
Check also whether the endpoint that is called uses keepalive sockets.