My Tomcat 8 is hosted on an Amazon EC2 large instance (8GB of ram), with a 64-bit Oracle Java 7u51 JVM. The 2GB PermGen is is an oversized value to guarantee I wont run out of memory in case I need do redeploy my applications several times in the same day, but the maximum I ever used was about 512MB.
I admit I don't understand 100% of the script. Actually I prefer the set the less configuration parameters possible. Some months ago my Tomcat 7 was "locking" (process using 100% of CPU and not responding). I found this script when I was looking for a solution for this, and as it was well documented I decided to use it. I don't remember facing this "locking" issue since them. My Tomcat 7 was running fine with this script, but last friday morning I started Tomcat 8 setting only this: *-Xms2048m -Xmx2048m -XX:MaxPermSize=1024m -Dorg.apache.el.parser.COERCE_TO_ZERO=false* and the applications crashed too. So I'd say that the problem is not my JVM config, but I'm interested on improving it. What arguments do you recommend to tune GC? Last friday afternoon I created a new Amazon EC2 instance with Tomcat 7 to check, and the problem is still there, so It was a damn coincidence that this problem started after I migrate to Tomcat 8. As I had a connection pool leak with Tomcat 8 it contributed for me to think that it could be something wrong with it. I still didn't solved it, I'll continue it here: http://forum.primefaces.org/viewtopic.php?f=3&t=36823 Any help is appreciated. Thanks 2014-03-13 17:51 GMT-03:00 Christopher Schultz <ch...@christopherschultz.net >: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Felipe, > > On 3/13/14, 3:33 PM, Felipe Jaekel wrote: > > Hmm I didn't looked at the server status yesterday, but the times I > > faced OOEM in the past nothing responded, page rendering didn't > > even started. And today problem is happening again with half the > > memory free. > > > > My best guess for the PermGen issue problem is Hibernate. I read a > > lot of forum threads and articles about it, tried lots of > > monitoring tools with no success. So I gave up and configured a > > large size and restart the server periodically to flush it. Never > > had problems again. I mentioned that I restart server daily to give > > a notion of how long the jvm was running. > > > > I was always curious about this ClientAbortException. I think its > > caused by connection problem on the client(mobile internet for > > example), so the user gives up loading the page. > > > > My web.xml is 3.0. > > > > I'm using a fresh Tomcat 8 install. > > > > I'll attach my setenv.sh, I found it on GitHub and changed the Xms, > > Xmx and PermGen values. > > > > Thanks again > > > > #! /bin/sh # > > ================================================================== > > # ______ __ _____ # /_ __/___ ____ > > ___ _________ _/ /_ /__ / # / / / __ \/ __ `__ \/ ___/ __ `/ > > __/ / / # / / / /_/ / / / / / / /__/ /_/ / /_ / / #/_/ > > \____/_/ /_/ /_/\___/\__,_/\__/ /_/ > > Uh, oh. You are using someone else's script without understanding it? > Things could work out great, but they could also not be so great. I'm > particularly interested in this part: > > > # Oracle Java as default, uses the serial garbage collector on the > > # Full Tenured heap. The Young space is collected in parallel, but > > the # Tenured is not. This means that at a time of load if a full > > collection # event occurs, since the event is a 'stop-the-world' > > serial event then # all application threads other than the garbage > > collector thread are # taken off the CPU. This can have severe > > consequences if requests continue # to accrue during these 'outage' > > periods. (specifically webservices, webapps) # [Also enables > > adaptive sizing automatically] export CATALINA_OPTS="$CATALINA_OPTS > > -XX:+UseParallelGC" > > "Parallel GC" is still a stop-the-world collector for the tenured (aka > "Old") generation. Technically, what you want is the "Parallel Compacy > GC" which is in fact what you get if you use this option on Java 6+. > Before that, you'll get the "old" parallel GC implementation which is > in fact stop-the-world. > > > # This is interpreted as a hint to the garbage collector that pause > > times # of <nnn> milliseconds or less are desired. The garbage > > collector will # adjust the Java heap size and other garbage > > collection related parameters # in an attempt to keep garbage > > collection pauses shorter than <nnn> milliseconds. # > > http://java.sun.com/docs/hotspot/gc5.0/ergo5.html export > > CATALINA_OPTS="$CATALINA_OPTS -XX:MaxGCPauseMillis=1500" > > If you don't need this, you shouldn't use it. By placing limits on the > GC, you can run out of memory even if you don't need to because the GC > can't catch up. 1500ms is pretty reasonable, but I always wonder why > people mess with things if they don't have to. > > > # A hint to the virtual machine that it.s desirable that not more > > than: # 1 / (1 + GCTimeRation) of the application execution time be > > spent in # the garbage collector. # > > > http://themindstorms.wordpress.com/2009/01/21/advanced-jvm-tuning-for-low-pause/ > > > > > export CATALINA_OPTS="$CATALINA_OPTS -XX:GCTimeRatio=9" > > > > # The hotspot server JVM has specific code-path optimizations # > > which yield an approximate 10% gain over the client version. export > > CATALINA_OPTS="$CATALINA_OPTS -server" > > > > # Disable remote (distributed) garbage collection by Java clients # > > and remove ability for applications to call explicit GC collection > > export CATALINA_OPTS="$CATALINA_OPTS -XX:+DisableExplicitGC" > > This can actually be a problem IMO. We have an admin console that > allows us to call System.gc() if we think something is wrong to check > to see if memory gets reclaimed when we do it. We rarely use it, but > it's a handy tool. The above setting would prohibit that kind of tool > from doing its job. > > I'm sorry, I have no idea why your application is falling-over, but it > seems like you have made some hasty decisions about JVM configuration > without much in the way of analysis, which can easily get you into > trouble. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTIhpBAAoJEBzwKT+lPKRYUSoP/RsM45xsulEGzK5B52rUk9Fs > AOCdSlX+ABaqJuT6wAjH8zv+d5MMxeod/C37gCYF2XLcx6bxvwTboGH8jyHNXn9Y > jSl36OoxjdPWgv24aLo8gS/NX6PdJvgpXWcvzvuypCsO01m9N6UVHaw2uN63bXXZ > w62bgtwMf99BDbVxtaz5W9fbXTPoRT8Ll9LFtQ4hxXr76xB6ieorPCehW+B6rInc > 4WUoYFpMyMhgbsMtzUup+e1LMk9nrGejXez0PyxIJP+wC6YQusjBcnlb2dg8Q0x0 > A589lKPqtoEdGY6Mhub6c4Z1hyF9q/GKRPncOSfbKdBL2q9wFOhLKX5aBvpypjzg > XUDW7ihjuh4S5q6K+bNz0dJYy1YxLzeTbe3rKFD2noOuT+d4CsxLjRAoVtIoDI68 > Ly0JtELBIt+wjflPuIVr08vgn+oZelyNSY+YtQd8J1EIk8IMRbI4X53d8HTEwAUs > oaC7m3IjkXqNdeXw7H3OaFwzSbGhL7+1FpmGgJbHs/Iv6IzMUP5LbEidHgCn1zWV > VGu7M/yUD/hTXA5CNQPQgc3xdub1dGMZZe2V9yUZl4iBeleDEm7D1FlCDCj06usx > rhUAKvmxoZS+j12tcJCCDCf/NOs0HzVyjcHbkQoaQk6dyrfaXX+HFSJlFelR/1Vh > iS+mdnaibeAf8ujPCgxI > =jq4x > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
