Running several Java services locally alongside other dependencies can use up a lot of memory. Is that a common headache, or does it mostly come down to the setup?
I'm also curious how people size heaps in production, tell leaks from load, and feel about a tool that watches memory and adjusts heap settings or restarts services automatically.
It seems to vary a lot. Some setups rarely hit heap trouble with explicit sizing and enough capacity, while others run into it regularly, especially with tight container limits or workloads whose memory needs are hard to predict.
For local development, a small fixed -Xmx per service is a reasonable starting point. Raise it when a particular test needs more, rather than giving every service a production-sized heap. You may still need to leave room for the broker, search service, and everything else running on the machine.
Watch the whole process, not just the Java heap. Metaspace, thread stacks, direct buffers, and other native allocations all need memory too. A container can hit its limit and get killed even when heap usage looks comfortable.
There's no magic heap percentage that works for every service. Some can devote most of the container limit to heap, while others need a much bigger off-heap allowance. MaxRAMPercentage can be handy when container limits vary, but it still needs tuning against the actual workload.
For production, I'd rather have monitoring and a deliberate sizing change than a service restarting itself to grab a bigger heap. Restarts affect availability, and a bigger heap can hide a problem rather than explain it.
Compare heap use after garbage collection with request volume over time. If the post-collection baseline keeps climbing under a comparable workload, that's a reason to investigate retained objects. A rise during heavier traffic that falls again afterward points in a different direction, though neither pattern proves the cause on its own. GC metrics, heap dumps, and process or container memory graphs can help narrow it down.
query.in.progress:
That makes sense. A recommendation with supporting metrics might be more useful than an automatic restart.
Don't assume every memory spike means the service needs a larger heap. Large imports, exports, or file processing can have very different requirements from ordinary requests. Test those paths separately and check whether the service is doing too much at once.
There are tradeoffs in both directions. Too little heap can increase garbage collection pressure, while a huge allocation leaves less memory for other processes and caching. Size for the workload you actually need to support.
There are already tools that configure Java memory settings for container images, so I'd look at those before building another automatic tuner. A useful gap might be explaining why a particular service needs more headroom, especially when the pressure isn't on the heap.
Answers are reviewed before publication.
almost-at-the-crosswalk:
That also means lowering -Xmx may help a crowded machine without fixing the underlying cause if native memory is what's growing.