IBM Integration Bus, Version 9.0.0.5 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Good operating practice: Analyzing parser statistics reports to reduce memory usage

When an integration server is using an unexpected amount of memory, identifying the cause of this usage can be difficult. There are two metrics that relate to memory usage, which can be extracted for an integration node.

The two metrics that can be extracted are provided by resource statistics. For more information, see Resource statistics. These two metrics are as follows:
  1. JVM statistics. The JVM statics gives the size of the JVM heap, and this size shows if many Java™ objects are in scope.
  2. Parser statistics. The parser statistics provide information on the number of parsed fields that are cached for the integration server. One of the columns in these statistics is ApproxMemKb, which reports the basic amount of memory that is being occupied by the cached fields.

This Good operating practice document explains what the statistics mean, how you can diagnose your memory issue, and gives some examples on interpreting the statistic reports and using ESQL best operating practices to improve efficiency.

Tip:

Why is there no node name associated with parser statistics?

One question that is often asked of parsing statistics is: "Why is there no node name associated with parser statistics?" To a message flow developer, it might look like a parser is tied to a specific node. However, this relationship is not the case. Because of partial parsing, a parser can be created by a node but then passed on to the rest of the message flow. Then, any other nodes might cause any parsing in that parser, and as such any downstream node might cause most of the parsing to take place. Which of the following pieces of information is the most useful when you consider a node name:
  1. The node that created it?
  2. The node that last parsed any fields?
  3. The node that caused the most parsing to take place?
You must also consider that a parser can be reused mid flow, and is temporarily assigned back to the input nodes parser pool.

With these details in mind, the node information becomes less useful when you consider the operations of a parser. Even if useful node information can be determined, the resource statistics does not allow the storing of character data that can be changed. To maintain high performance, the resource statistics does not lock the update side of the statistics, and as such relies on reading a set amount of memory atomically. This behavior is possible with numeric data, but is not possible using character data. Therefore, storing any character data involves locking the flows operations while the statistics are read, which is unacceptable when you consider performance. For these reasons, no node name is included in parser statistics.

Parent topic: Best practices
bj60100_.htm | Last updated: Last updated: 2016-08-12 11:20:24