Opened 6 weeks ago

Last modified 6 weeks ago

#2638 new enhancement

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

Description

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.

Subtickets

Change History (2)

comment:2 Changed 6 weeks ago by zzz

https://wrapper.tanukisoftware.com/doc/english/prop-java-initmemory.html

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.

Note: See TracTickets for help on using tickets.