Is there a use for the fetchResultLogLimit property and is it possible to generate critical debug information for troubleshooting performance, stability, and runtime issues?
In V6 the mxe.db.fetchResultLogLimit property can be found in the path:
<application source root>/applications/maximo/properties/maximo.properties
The default value for this property is 200.
In V7 the fetchResultLogLimit property can be found in the system properties application
The default value for this property is 200
When enabled, this property generates a forced exception in the log each time the specified number of objects is loaded into a single set. The resulting stack trace shows what process is loading the objects.
When too many objects are being loaded and not released, this property can show how often a given process is loading the threshold count of objects. When set to 200, this will generate a stack trace when 200, 400, 600…etc objects are loaded into any single set.
Objects are organized in sets. You may have 20 sets and some sets will have 5 objects while other sets have 100 objects. The fetchResultLogLimit monitors objects in any single set. This property will not generate any output if the threshold set by the fetchResultLogLimit is not met. This means that setting the value to a higher number may not provide the necessary results to diagnose a problem. For example, setting the threshold to 1000 will cause an exception only when 1000 objects are in any one set so if there are 11 sets and each has 999 objects 10,989 objects will be in memory but no exception will be generated because none of the sets have 1000 or more objects in them. When troubleshooting memory problems, this threshold should be set no higher than 200 to show what is loading objects in a given set.
When the mboCount property is set on, once per minute, the total MBOs in memory are shown in the log in a similar format to the following:
15 Oct 2009 09:15:59:182 [INFO] [server10]  MAXLABELS: mbosets (40), mbos (12200)
In this example, there are 40 MBO sets and the total of all MBOs in all sets is 12,200.
Typical fetchResultLogLimit output to the logs might look as follows when the threshold number is met:
IBM has internal tools that can correlate and trend this information combined with the output of the mbocount property and the LogSQLTimeLimit to determine many causes of performance, stability, and runtime problems. Since mbocount runs every minute, IBM can gather an understanding of the health of the JVM over a period of time. Often IBM will request up to 24 hours of logs to determine trends in user loads, memory requirements and many other points of interest.
This property should be left running at all times since a problem can often not be foreseen or replicated. In order to troubleshoot or find root cause of many issues, the data from this property is required.
For more information on debug properties see the document Using debug properties to monitor and troubleshoot performance
The document what is the mbocount property
The document what is the logSQLTimeLimit property
|Systems and Asset Management||IBM Maximo Asset Management Essentials|
|Systems and Asset Management||Tivoli Asset Management|
|Systems and Asset Management||Tivoli Asset Management for IT|
|Systems and Asset Management||Tivoli Asset Management for Service Providers|
|Systems and Asset Management||Tivoli Change and Configuration Management Database|
|Systems and Asset Management||Tivoli Service Automation Manager|
|Systems and Asset Management||Tivoli Service Request Manager|