-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 George,
On 11/16/16 11:18 AM, George I. Develekos wrote: > On another installation with higher load, the JVM has "selected" > to give YoungGen 250MB or so (as opposed to 150M here), and I > have confirmed that Full-GC is much less frequent so I'll go with > that next time I have downtime. +1 - From the screenshots you posted, it looks like everything is healthy EXCEPT that your young generation said 100% used *and* the "average freed full GC" says nearly 700M per collection. I've never used GCViewer, but if I'm reading that correctly, it's saying that you are averaging more than 50% turnover in your tenured generation during each full gc. (You have ~1300M in your tenured generation and 700M is being collected each time.) That's a HUGE amount of GC thrashing. Were these samples taken of a stably-running production system, or was this immediately after a restart, or in a lab or something? > When exactly can I expect to see my app freeze? Isn't it during > Full-GC? John has already answered this. Feel free to ask follow-up questions. > Does the increase in CPU during those Full-GC times make sense? Absolutely. Most of the time, applications are waiting for other things to happen: read/write from the network, disk, whatever. GC is 100% CPU-bound activity, so you'll see a spike in the CPU usage whenever the GC is running. Since some of the phases of CMS are concurrent (that's what the "C" stands for), they won't pause your application. Unfortunately, some phases are NOT concurrent, and the application needs to be paused (this is appropriately called "stop-the-world" because that's exactly what happens). Fortunately, those phases are designed to be very short in time. I have two recommendations for you, which really boils down to a single one: 1. Set Xms and Xmx to be the same value If you want to give 5G to your application, then give it all 5G. Don't wait for the application to lazily grow to fill the space. It just slows everything down. If you want a 2G heap, then use a 2G heap. Splitting the heap into initial and max sizes is silly for a server process. 2. Increase the young generation size by *at least* a factor of 2, possibly 4. If you do #1 above, the JVM will likely re-size the young generation for you anyway, since it will be starting with a bigger heap. So you might not have to do this one at all. Finally, the best course of action would be to upgrade to a more recent JVM. You said initially that you were stuck, but you might not be. You can use Oracle's JVM or OpenJVM running fairly easily, though you might have to maintain and/or update it manually if there is no package from RedHat for it. I've never used package-managed JVMs because they tend to require dozens or hundreds of other packages to be installed. Installation is typically untarring a tarball, upgrading is just as easy, and downgrading is a snap (just don't delete the old directory when upgrading). The only downside is that the package manager won't go fetch the archive and run the installer for you. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYLJCEAAoJEBzwKT+lPKRYyrkP/RuvH0SKRcEGfDGWybq8LQl1 MXy6fPk1HtHrkRAgEtQhxmEh/Za64E993R7hXnKNiGjwz2FVp2Fz4rq81Y/cxuSw PEO01mfwY7y+j97zO2PQvYubnEhHIiPZZ5IYnjVMqZtmdX6hETCiWAx6vFYcCnL/ 9ZGmHXDuCcI1uxDNJ4rq/mJcFyMjRLMR1uufrGwv37nbwXAKCQPIiYb6lALyof2X 7HwZUNAYi+MAJnQJSub4/QM/Bm4IUJn4h47RKia2ar2PaEIOSZihqLP7JRjTlTA7 U6KvDUfiBKNh7ECOvAXxFhZxjK3NEpjBU3/6beRIVcL5K5klOGfXTofDACEACH47 5bfmLrQChR0jPbsBlQcLwRQQxVdsj6RJi0u96Anyn5ElLfZiKUexQDx6X0oXeV6i n5o4En0Rme7GzVtcEh3FmY2y4vFqCAGgwZ3lK2caXH6AqpR0WsyRuLISK4UtjcxP NJIXpURtsfNMNqHTH/US6VftfC2lIQNJB0mRzMdnl7KrA6U6mXmn21ZAiPT64lkw O8JQ49fF3giszo+x37EVkaA+YFn86ap4UzxwH+Tz86xd8qckihFTvGLr48cCjlJn zhyR8x5ir+Q1CW9Q3GhSZJTtC5j2LY94vF7I5pZdln34aM/37u/iXlesBaEzwqGW Sx00lN+4sNzr9jPZez5C =Q0qd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
