#2638 closed enhancement (wontfix)

Properly set wrapper.java.initmemory

Reported by: jogger Owned by:
Priority: minor Milestone: undecided
Component: installer Version: 0.9.42
Keywords: Cc:
Parent Tickets: Sensitive: no


Recently maxmemory was raised, but from a performance perspective this was the wrong parameter. maxmemory just sets an upper ceiling and increases the bandwidth level from which the bloomfilter starts complaining.

If we set initmemory=maxmemory we give the Java memory management a clear target to work against. Currently the GC threads work hard to keep the heap as small as possible, no matter what value we choose for maxmemory.

In my testbed using G1, CPU usage for the concurrent markers and refiners was down a whopping 57%. Can´t judge the improvement for STW GC because I use a pause time goal there for my dev version. Will try to attach the charts from jconsole, making clear how GC goes crazy without defined heap size.


Change History (3)

comment:2 Changed 22 months ago by zzz


Not sure if we want to try to outsmart the JVM here.
We also must be careful to tell the user to adjust the initmemory param if he reduces the maxmemory param; it appears from the docs that may be a fatal error.

One alternative would be to use the percent param instead.
Or, if using the initmemory param, set it fairly modestly, say 32 or 48 MB. Would have to test on RPi to make sure big numbers don't cause an error at startup. We usually try hard to minimize memory usage, even at the expense of performance, because the JVM is such a hog. This would be a change to that policy. Perhaps a simple commented-out line in wrapper.config would be sufficient.

comment:3 Changed 18 months ago by zzz

Resolution: wontfix
Status: newclosed

We already have a commented out line in wrapper.config for wrapper.java.initmemory, which is a hint to the user. This was one of the ideas in comment 2.
We'll trust the JVM to do its thing. There's no way to pick an initmemory setting that's optimized for all platforms and JVM flavors.
Disagree with statement in the OP about performance. Higher maxmem leads to less GC. But the primary reason to raise maxmem was to prevent OOMs.
Links from comment 1 are dead.

Note: See TracTickets for help on using tickets.