The data I posted was collected as Tomcat was restarted and for the next
19 hours.
You see too much GC thrashing, are you saying the GC process finds too
much G to clean up? Should I urge the developers to do some GC of their own?
I give 2G to start with because it may not actually /need /5g, and
experience has shown that it doesn't. I know giving it all at the start
is better but I don't have memory to spare. I'll probably up from 2/5 yo
3/5.
To boost YoungGen, should I do it with an explicit setting or with the
radio thingy? Set it to 3, perhaps?
On 16-Nov-16 6:59 PM, Christopher Schultz wrote:
-----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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
