-----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
