What problems are detected by Plumbr?
Memory leak in Java is a data structure which cannot be garbage collected. If left unattended, a memory leak keeps growing and eventually kills your application. Plumbr monitors the application for dangerous trends in the data structures and when detecting such a trend, exposes a leak containing the following information:
- size of the leak in megabytes and the speed at which the leak is growing in MB/hour;
- leaked class and the number of instances created from this class;
- reference chain and allocation points for the leaked objects.
Most java.lang.OutOfMemoryErrors are not triggered by a leak in the source code. More commonly, either the application has grown beyond the capacity allocated for it or is suffering from a sudden surge where no previous trend confirms the presence of a leak. For such situations, Plumbr is equipped with a possibility to capture the information at the moment when the JVM runs out of memory, exposing you the following information:
- data structures consuming most memory;
- reference chain holding such data structures;
- allocation points, indicating the line in source code where such objects were allocated.
Expensive JDBC Operations
Modern applications are distributed by nature – most transactions exceed JVM boundaries to talk with integrated systems and data stores. The sheer amount of such operations combined with the blocking and remote nature of the calls is a significant threat to performance. Plumbr instruments and monitors the JDBC connections and when end users start suffering, hands you the following data about the offending JDBC operations:
- SQL statement executed;
- When you have enabled the JDBC parameter monitoring, the query is equipped with parameters, using which the particular query performed poorly..
- call stack from the thread launching the offending query.
Slow HTTP Operations
Transactions spanning multiple subsystems add extra latency to each operation to complete. Web Service calls over HTTP can become performance bottlenecks requiring attention. Plumbr monitors JDK HTTP (java.net.URL and related classes), Apache Commons HTTP components and Apache Commons HTTP Client libraries for outgoing HTTP requests. When such HTTP operations start affecting the end user experience, you get access to
- the offending HTTP query, linked to user transactions as a root cause exposing the outgoing HTTP request;
- the call stack from the thread executing the query.
Locking is a safety net present in all multi-threaded applications. Synchronizing access using locks is a way to guarantee consistency. However, poorly designed locks can and will degrade user experience, adding thousands of milliseconds to user transactions. Plumbr monitors your application for lock contention events and when end users start suffering, exposes the following information about the locks:
- lock which gets contended;
- the call stack for both the lock holder and waiting threads;
- names of both the lock holding and waiting threads.
Garbage Collection Inefficiencies
Garbage Collection is a process identifying and discarding unused objects to reclaim memory. In order to do so, GC needs to stop JVM every once in a while. Duration of those stops is unpredictable and can exceed tens of seconds, during which end users perceive the application as unresponsive. Plumbr monitors the JVM for all stop-the-world GC pauses and when end users start suffering, exposes the following:
- duration for each GC pause, along with the phase pausing the application threads for collection;
- additional insight regarding the memory pool capacity, promotion and allocation rates at the time the pauses occurred.
Exceptions should be for what the name states – for exceptional situations. However, programming errors can and will often result in user transactions resulting in Exceptions being thrown and transactions failing. Plumbr monitors the end user experience, and when the response sent back to end user from the system indicates a failed transaction, exposes you the following information:
- chronologically last Exception linked to the incoming transaction as a root cause;
- full stack trace of the Exception thrown