Hi, If you toss a GC log this way I maybe able to offer a suggestion.
Kind regards, Kirk Pepperdine > On Dec 21, 2017, at 10:01 PM, Gary Mulder <[email protected]> wrote: > > As a data point: > > I'm managing (or more watching and daily sacrificing a goat to) a JVM using > Hotspot parallel GC with a 14GB heap and 4.5GB young generation. It is > randomly taking 30-90 seconds to do a minor GC due to scheduled quartz job > generates large XML document POST request that I suspect is around 4GB in > size. There is no VM memory pressure or swapping, as the VM has 16GB of RAM. > > As a general rule I've found young generations of more than about 2GB and JVM > heap sizes of more than 8GB (i.e. large old generations) really do not > perform well with the Hotspot parallel GC when there is a mix of small > requests creating a lot of short-lived small objects and then a large slow > request hits the young generation. As I can't yet reproduce this problem in a > test environment I'm not sure whether the G1 collector might perform better. > > Naturally, Azul System's Zing JVM would likely be a simple solution to > dealing with this, but as this is a retail platform under a change freeze, so > my goal is to keep it alive until Christmas... > > Ho ho ho, > Gary > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
