Your apparently have the (understandable) misconception that Perm space is used for storing very long-living objects. That is not the case. Perm space is used only for Class objects and other JVM internal metadata. You need to increase the Perm space only if you really have a LOT of classes such as when using XSP or JSP.
For user objects, garbage collection uses four areas: 1.) Young generation Eden space 2.) Young generation Survivor space 1 (from) 3.) Young generation Survivor space 2 (to) 4.) Old generation Tenured space A new object is always created in Eden space. When Eden becomes full, the still alive objects are copied to Survivor space 1 and Eden is cleared. When Survivor space 1 becomes full, all still alive objects are copied to Survivor space 2, Survivor space 1 is cleared, and the roles for Survivor space 1 and 2 are swapped. This process is called a minor GC. Each time an object survives a minor GC, its survival counter is incremented. When the counter reaches the -XX:MaxTenuringThreshold, the object is copied to the Tenured space. Objects stay in the Tenured space until they die. (The do *not* go into the Perm space). When the Tenured space becomes full, a full GC tries to free space by sweeping out all dead objects. If that cannot free any space, the JVM dies with OOM. The sizes of Eden / Survivor / Tenured space can be controlled by JVM -XX parameters. Unfortunately the default values are not very well suited for webservers. Ideally what you want to achieve is to avoid as far as possible that object die just after being copied. For a webserver that means: 1.) Request-scope objects should stay in Eden. 2.) Objects living a few minutes (short-term caches, possibly sessions) should stay in Survivor space. 3.) Only really long-lived objects should end up in Tenured space. The default values in your configuration use tiny Eden and Survivor spaces (38MB each) and a large Tenured space (930MB). Together with the large number of concurrent threads, Eden and Survivor spaces constantly overflow and request-scoped object end up in tenured space. You should try to use increase the young generation spaces and watch the frequency of minor and major GCs. The aim is to have major GCs not more than once per hour. These are the GC related settings we are using with 1.4.2_10: -Xms3000m -Xmx3000m -XX:MaxPermSize=200m -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+DisableExplicitGC -XX:NewRatio=2 -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=10 Whether you have a memory leak is hard to judge. With 100 active threads maybe 1000MB just is not enough to run. Try to tune the GC parameters and double the memory. If you still get OOM (after a longer time), then you really need to look for leaks. Java 1.4.2_10 and Java 5 contain the jmap tool which allows to dump the number of objects and memory used for each class in a running JVM. That may already allow to identify the type of object a real leak produces. HTH, Alfred. -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Nowak Sent: Donnerstag, 2. März 2006 11:45 To: users@cocoon.apache.org Subject: Re: Scaling Cocoon to handle a heavy load Ralph Goers <[EMAIL PROTECTED]> wrote: > > I had problems in production recently. When it hangs get a JVM stack > trace. You may find that you have lock contention or something else > that will readily show up. http://www.biochip.pl/hs_err_pid17443.log.txt So what does it tell you? It tells me only that: - Java seems to dont care about my -XX:MaxPermSize=256m, (do you see the PSPermGen, OldGen?) - If that crashed because of a PermSpace, why has it logged "OutOfMemoryError: Heap space" not "OutOfMemoryError: PermGen space"? -- T. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
