Working with the in-memory storage

Owned by Copy Space for Confluence
May 20, 2015

Overview

inspectIT stores most of the monitoring data in memory to improve performance and scalability on the CMR and to provide faster access to the data for the client. So the CMR does not automatically persist all data that is sent by Agent, but uses a buffer for storing some data types (list of data types) in memory. Here are the details on the reasons:

  • Usually only a small amount of data is of big importance for discovering performance problems. After analyzing the data it often becomes not useful anymore and can be deleted. 
  • Persisting data requires much more time than to store in the memory
  • Retrieving the data is much faster now, especially for invocations that have a large number of children
Types of data that are stored in memory

Currently following data types are stored in memory:

  1. Invocation sequence data
  2. SQL Statement data
  3. Timer data
  4. Exception data

All other data types are stored in database. The Timer data is, by default settings, also stored in database in an aggregated mode, thus available for the historical overview. However, this option can be disabled (see CMR properties).

Move important analysis results to the storage area

Bear in mind that it is always possible to store important/interesting analysis results (e.g. invocation sequences) to the storage area to make them available for all times. More information can be found here: Working with disk storage

The buffer

The buffer has a FIFO evicting policy, meaning that when it is full, the oldest data will be evicted first. The size of the buffer is automatically set depending on maximum heap memory size assigned to the Java virtual machine where CMR is run, and by default ranges from 60% to 80% of maximum heap memory size. More heap assigned to CMR, means bigger buffer size, and with larger buffer size more data can be stored.

Changes in buffer memory size calculations from version 1.3

The version 1.3 brings the better garbage collection performance of the CMR. Because of these changes, it was necessary to adapt the initial buffer memory size calculations. The size it not depending any more on the total heap size of the JVM, but on the old generation memory pool size. By default it ranges from 50% to 65% of the old generation space. More information on how to increase the buffer size by increasing the memory given to the CMR.

The initial size of the buffer can be seen in the CMR logging output:

2010-12-23 10:56:22,880 : Central Measurement Repository is starting up!
2010-12-23 10:56:22,891 : ==============================================
...
2010-12-23 10:56:28,321 : |-Using buffer with maximum size 490,421,408 bytes...

Although it is not necessary and recommendable, initial buffer size settings can be changed. Please see CMR Configuration page for more details.

Warning

Shutting down the CMR will throw away all the data in the buffer, thus after restarting it is not possible to examine them. Be sure to shut down CMR only when data in the buffer is not needed any more and/or you saved the data that was important to you to the storage area.

Increasing the buffer size by giving more memory to the CMR

Valid for versions 1.3 and above

The default memory size given to the CMR is 1024MB for the 32-bit CMR versions, and 1536MB for the 64-bit versions. By increasing the heap size of JVM where CMR is run, the buffer size will increase as well, which will enable to store more inspectIT data in the in-memory buffer. However, with the increase of the heap size it is important to size the new and old generation memory pools accordingly. The suggestion is that the new generation size is 1/3 of a total heap size.

For example, if the intention is to give CMR the 6GB of memory, it is important to change the following JVM parameters in the CMR startup file:

Default JMV parameters (1GB of memory):
-Xms1024m -Xmx1024m -Xmn384M

Changes to have a 6GB of memory:
-Xms6144m -Xmx6144m -Xmn2048M

The parameter -Xmn is defying the size of the new generation memory pool, and it is defined as 1/3 of a total 6GB heap size.

User interface

The user interface provides the option that enables the user to delete all existing data in the buffer on selected CMR. The action Clear Repository Buffer  in the Repository Manager View menu deletes all data that is stored in the memory-buffer on the selected CMR.