JXRay 2.8u3 released

Posted on February 20, 2022

In this version: Detection of several new memory leak kinds added. In particular, objects held in memory only via anonymous lambda class instances, only via Builder class instances, etc.New anomaly detection: strings that contain exception stack traces and occupy a significant percentage of the heap. This signals that the app is in bad state, throwing exceptions all the time.Improved information about thread status in the “Thread stacks” report sectionUI improvements and bug fixes

Fixing Azkaban’s excessive memory usage

Posted on January 30, 2022

Project Azkaban is a batch workflow job scheduler created at LinkedIn to run Hadoop jobs. Azkaban resolves the ordering through job dependencies and provides an easy to use web user interface to maintain and track user’s workflows. Some Azkaban servers may grow huge, using tens of gigabytes of memory. Heap dumps that we analyzed were generated by the JVM running with 45G max heap. It routinely utilized more than 35G, had long GC pauses and was occasionally

JXRay 2.8u2 released

Posted on August 20, 2021

In this version: Detection of more anomalies in 3rd party code (underutilized Netty I/O buffers in Couchbase code, very big arrays generated by Jackson codec, etc.)Improved analysis of unfinalized objects that may cause GC degradationBug fixes and UI improvements
There are a number of reasons to avoid using Java Finalization (that is, objects that override the finalize() method). From the GC performance perspective, the main problem with finalization is that when GC determines that a finalizable object F is unreachable, it doesn’t clean up F immediately, as it does with other unreachable objects. Instead, the GC places F on the finalization queue, which is served by a single thread. Only when that thread executes the finalize() method of

JXRay 2.8u1 released

Posted on February 26, 2021

In this version: Detection of more anomaliesBug fixes and usability improvements