Heap sizing and GC tuning for Solr and friends
summary
Solr/Elasticsearch-style nodes need heap sized from measured peaks not rules of thumb: take highest peak and lowest peak and use twice the low as a baseline, keep Xmx and Xms equal and pre-touch to avoid resizing. If a heap OOM occurs, take a heap dump and inspect with Eclipse MAT to tell “need more heap” vs “GC fell behind.” Follow the ~30–32 GB pointer-compression hump (compressed pointers around 32GB); prefer G1 with target-pause and GC-time-ratio knobs, or ZGC (Java 21 generational) for very large heaps.
AI-written summary · about
chapters (8)
- 0:00Introduction and architecture
- 3:27Understanding JVM heap
- 5:37Performance and cache tuning
- 8:11Sizing and monitoring
- 10:00Pointers and memory limits
- 11:51Diagnosing GC issues
- 13:35Garbage collector tuning
- 17:55Questions and answers
related talks
40mDebugging JVM performance issues
52mMemory footprint of a Java process
07mSoft Memory Limit in Go 1.19
33mDigging through the garbage
22mEMD: Fair and Efficient Dynamic Memory De-bloating of Transparent Huge Pages
40mInspecting and Optimizing Memory Usage in Linux
20mRevisiting Partial Tracing for Safe, Efficient, and Concurrent Garbage Collection in(…)
27mWhen Linux Memory Accounting Goes Wrong