Today, we’re happy to launch: Garbage Collection Analysis.
This new feature allow you to view profiles of your JVMs’ garbage collection and heap usage over time, enabling you to see why GCs take too long by pointing out where the top allocations which are filling your heap take place.
Main GC insights:
- GC profile: Takipi monitors your JVMs’ GC cycles, showing you: (1) When garbage collections happen, (2) How often they take place, and (3) How long each one takes.
- Heap profile: For each GC cycle, you can view snapshots of the major players in the heap before it happened. That is, Takipi shows you which objects were most relevant right before the GC, for example: 28% of the allocations were of DbCacheItem. In addition, Takipi tells you which GC cycles took the longest in the last 24 hours, and which classes were filling the heap when those took place.
- Allocation profile: Takipi analyzes your heap between garbage collections, and figures out the top GC “culprits”. We then show you where in the code, and in which stack traces, these classes are allocated the most.
How does it affect performance? If you’re using Takipi’s default settings, the maximum CPU/RAM overhead we consume is 5%. The GC analysis overhead is included in this limit. Use the settings panel if you’d like to increase/decrease the overhead limit.
To start receiving GC analyses, please make sure you update to the latest Takipi agent.
Enjoy, and we hope you’ll soon find which allocations are causing problems 🙂