The page should provide the checklist in situations when Agent is consuming much more memory on the monitored application than expected. The problem of high memory consumption is usually appearing when the configuration of the Agent is not done properly. If you have the mentioned problem please check this list carefully and try to identify if one or more points match your situation and apply the proposed solution.
| Problem | Solution | |
|---|---|---|
| Too much methods instrumented | If the configuration is defined in the way that too much methods are instrumented than amount of gathered monitored data is very high. The data is such cases can have a big memory footprint, making the Agent have high memory consumption. In addition, in such cases there is a very big overhead to the monitored application. Sometimes, such configurations can even make application server impossible to start. Example: sensor timer my.app.* * sensor isequence my.app.* * | Start the monitoring with a small set of classes that belong to your application. For example, if the monitored application is EJB application it can be enough to just instrument the beans. Avoid instrumenting entities, since they usually provide no logic. Monitoring of getters and setters does not have any value.In addition, start with instrumenting only public methods using the modifiers=pub configuration option. As time goes by, try instrumenting more classes and methods but only the ones that will bring valuable performance analysis results. |
| Monitoring all exceptions | inspectIT provides possibility to instrument Java core classes. Thus, having configuration line as: exception-sensor * will mean that all exceptions will be instrumented including the Java ones. In many applications it is usually that many exceptions are raised during the run-time and inspectIT will for each one collect the stack trace, exception message, etc. All that information is represented as String and they can occupy much of the heap space. | Make sure that you only monitor exceptions that are defined by your application. If you want to monitor some special Java core exceptions defined them in additional configuration line with the fully qualified name: exception-sensor my.app.* exception-sensor java.lang.NullPointerException |
| Not defining string limit for sensors | All the sensors in inspectIT provide possibility to define the maximum length of strings collected by the sensor. For example, the SQL sensor will crop the SQL statement string to match the maximum length defined in the sensor definition. Omitting to define the max length of strings can in high-load situations create a large memory footprint for monitoring data that is mainly consisted out of strings (SQLs, Exceptions, HTTP data). | Always specify the stringLength property when defining the sensor: method-sensor-type jdbc-statement info.novatec.inspectit.agent.sensor.method.jdbc.StatementSensor MIN stringLength=300 You can freely increase the default value of 300 to something that matches your needs, but keep it reasonable. |
| Send strategy modifications | By default, inspectIT uses the time sending strategy that sends collected data every 5 seconds: send-strategy info.novatec.inspectit.agent.sending.impl.TimeStrategy time=5000 Increasing the time for the time sending strategy, can cause that too much data is collected on the Agent and not sent because Agent waits for the given time to pass between each send try. Since data to be sent to the CMR is also in the memory it can influence the consumption of the memory. | Keep the default settings. |
Using inspectIT will always create an overhead in the memory, but with careful and reasonable configuration it should be very low.
Note that if no presented points match your configuration and you are still experiencing the high memory overhead you can freely contact us and present the problem. The future versions of inspectIT will have additional features that will measure the memory overhead on the Agent and provide possibility to limit it.