[Geoserver-users] Optimising the JVM and Garbage Collectors

GeoServer GeoServer User
1

Hi List,
I was wondering if maybe the “Optimize your JVM” page could use an update? (http://docs.geoserver.org/stable/en/user/production/container.html )

Reasoning:
“-XX:+UseParallelGC” - is enabled by default (although not on everything - http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors )
“-server” - is also enabled by default on almost everything that’s going to be used to run a production GeoServer.

And are the suggested options the best ones? Some thoughts from reading around the subject, though I’m far from an expert:

  • Should not the xmx and xms both be the same? Why initialise less than the maximum in a production environment? - From http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html - “Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice.”

  • They are also rather low (though that’s also based on the anticipated usage and resource availability).

  • The ParallelGC defaults are potentially prone to locking up GeoServer for a while as it does the “stop-the-world” thing. This article ( http://blog.mgm-tp.com/2013/03/garbage-collection-tuning/ ) suggests that turning off -XX:-UseAdaptiveSizePolicy reduces this somewhat when used with -XX:NewSize=200m -XX:MaxNewSize=200m (or whatever values) (or NewRatio if we don’t want to specify a size).

Other options that it may be worth adding:
-XX:PermSize=256m and -XX:MaxPermSize=256m (or whatever is the best value).

Finally, has anyone tried the Concurrent Collector (CMS) with GeoServer? Although that does seem to require more consideration with how its tweaked (memory fragmentation doesn’t look pleasant). The G1 Collector looks easier to configure than CMS but doesn’t appear to provide the same levels of performance.

What have others used that has worked (or not)?

Jonathan

p.s. (This may be better suited to the Dev list, but starting on User)

2

Hi Jonathan,

We have been using the G1 Collector (on Java 8) in production for about a year or so with no reported issues. When you mention the performance of G1, do you mean in general or under GeoServer-specific workloads?

Thanks

Jack

···

On 14 May 2016 at 00:10, Jonathan Moules <jonathan-lists@anonymised.com> wrote:

Hi List,
I was wondering if maybe the “Optimize your JVM” page could use an update? (http://docs.geoserver.org/stable/en/user/production/container.html )

Reasoning:
“-XX:+UseParallelGC” - is enabled by default (although not on everything - http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors )
“-server” - is also enabled by default on almost everything that’s going to be used to run a production GeoServer.

And are the suggested options the best ones? Some thoughts from reading around the subject, though I’m far from an expert:

  • Should not the xmx and xms both be the same? Why initialise less than the maximum in a production environment? - From http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html - “Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice.”

  • They are also rather low (though that’s also based on the anticipated usage and resource availability).

  • The ParallelGC defaults are potentially prone to locking up GeoServer for a while as it does the “stop-the-world” thing. This article ( http://blog.mgm-tp.com/2013/03/garbage-collection-tuning/ ) suggests that turning off -XX:-UseAdaptiveSizePolicy reduces this somewhat when used with -XX:NewSize=200m -XX:MaxNewSize=200m (or whatever values) (or NewRatio if we don’t want to specify a size).

Other options that it may be worth adding:
-XX:PermSize=256m and -XX:MaxPermSize=256m (or whatever is the best value).

Finally, has anyone tried the Concurrent Collector (CMS) with GeoServer? Although that does seem to require more consideration with how its tweaked (memory fragmentation doesn’t look pleasant). The G1 Collector looks easier to configure than CMS but doesn’t appear to provide the same levels of performance.

What have others used that has worked (or not)?

Jonathan

p.s. (This may be better suited to the Dev list, but starting on User)

Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

3

Hi Jack,
Thanks for the feedback. My comments on the performance of the G1 collector relate to its general performance, reading around suggests that generally speaking the G1 collector isn’t as performant as a combined CMS/UseParNewGC. I’ve not tried it on an instance myself so don’t know how well suited to GeoServer it is. Any other insights you or anyone else has would be welcome.
Thanks,
Jonathan

---- On Mon, 16 May 2016 07:42:58 +0100 Jack Mitchell citricwage@anonymised.com wrote ----

Hi Jonathan,

We have been using the G1 Collector (on Java 8) in production for about a year or so with no reported issues. When you mention the performance of G1, do you mean in general or under GeoServer-specific workloads?

Thanks

Jack

On 14 May 2016 at 00:10, Jonathan Moules <jonathan-lists@anonymised.com> wrote:

Hi List,
I was wondering if maybe the “Optimize your JVM” page could use an update? (http://docs.geoserver.org/stable/en/user/production/container.html )

Reasoning:
“-XX:+UseParallelGC” - is enabled by default (although not on everything - http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors )
“-server” - is also enabled by default on almost everything that’s going to be used to run a production GeoServer.

And are the suggested options the best ones? Some thoughts from reading around the subject, though I’m far from an expert:

  • Should not the xmx and xms both be the same? Why initialise less than the maximum in a production environment? - From http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html - “Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice.”

  • They are also rather low (though that’s also based on the anticipated usage and resource availability).

  • The ParallelGC defaults are potentially prone to locking up GeoServer for a while as it does the “stop-the-world” thing. This article ( http://blog.mgm-tp.com/2013/03/garbage-collection-tuning/ ) suggests that turning off -XX:-UseAdaptiveSizePolicy reduces this somewhat when used with -XX:NewSize=200m -XX:MaxNewSize=200m (or whatever values) (or NewRatio if we don’t want to specify a size).

Other options that it may be worth adding:
-XX:PermSize=256m and -XX:MaxPermSize=256m (or whatever is the best value).

Finally, has anyone tried the Concurrent Collector (CMS) with GeoServer? Although that does seem to require more consideration with how its tweaked (memory fragmentation doesn’t look pleasant). The G1 Collector looks easier to configure than CMS but doesn’t appear to provide the same levels of performance.

What have others used that has worked (or not)?

Jonathan

p.s. (This may be better suited to the Dev list, but starting on User)

Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users