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 section UI improvements and bug …
Author: Mikhail Dmitriev
Fixing Azkaban’s excessive memory usage
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
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 degradation Bug fixes and UI improvements
Tip of the day: what’s wrong with Java Finalization?
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
In this version: Detection of more anomalies Bug fixes and usability improvements