Most of the analysis data (Detailed list) reside within the in-memory buffer of the CMR, thus the size of this buffer defines the amount of data that is available for monitoring/diagnosis. In other words, the bigger the provided heap space for the CMR, the more/longer invocation sequences, exceptions, DB queries, etc. are available for analysis until they are removed from the buffer.

A very small size for the in-memory buffer (or unreasonable configuration of the sensors) can lead to situations in which data needs to be removed from the buffer before the analyst can inspect it. This small documentation provides insights how you should size your buffer. Please note that the standard settings are usually fine, you only need to adapt them if you need more data.

Use provided JVM

The CMR comes with a JVM provided. Note that is best if the CMR runs with provided JVM, because the control of the in-memory buffer memory footprint is adapted for this JVM. Usage of any other JVM is not recommended.

Quicktip: Reasonable settings are provided

For single user environments in which each developer has its inspectIT installation, the configuration provided by the CMR release should be absolutely enough.

Different sensors data need different memory

The internal structure of the data objects inspectIT uses are very small, so almost all memory is used by the concrete data the application provides. inspectIT is also optimized to store static data only once, so the in-memory objects do not contain detailed method, class or package names, but only identifiers, that are resolved for display in the user interface.

Within the data inspectIT captures String objects usually take the most space. That is why usually data provided by the SQL Sensor takes up lots of space as database queries tend to be long Strings. Compare that to a simple Timer sensor information in which (among other small data) we only provide an integer value. Context Capturing can also increase the number of String objects that are send and thus kept in-memory. The Exception Sensor provides a stacktrace information which increases the space requirement.

Reducing the number of unnecessary data

Often the amount of sensor configuration is set too high. In such a scenario the amount of unnecessary data is very high. By reducing the number of sensors you automatically reduce the number of data sent to the CMR and thus the time data can be held in the buffer. As a rule of thumb: Try to reduce the amount of data within an invocation sequence to be approximately 200 children or less (this is only a rule of thumb! Different applications have different requirements)

Monitor the CMR heapsize and adapt memory accordingly

The CMR already provides detailed information about the number of elements currently available in the buffer, the amount of space they take and the amount of free space. You can easily find this information in the Health Status of the CMR.

Persist important data

bear in mind that it is always possible to persist important data for later analysis.

Version 1.4 provides automatic storage for important data

With version 1.4 inspectIT provides automatic means for persisting data.