Mark H. Wood wrote: >> Using Tomcat manager allows us to stop/start/deploy >> one instance without affecting the others. > > Very handy! Every time you do this, though, it gobbles up some > PermGen memory. I'm doing frequent stop/start cycles on the test box > right now, and after a dozen or so Tomcat goes into a spin burning > 100% of one pipeline and I have to restart Tomcat. On the production > machines, which have a scheduled reboot once a week, I usually have no > such problems. I've tweaked up PermGen a bit to make Tomcat last > longer between restarts.
That depends on a number of factors. I'm using the Oracle JDBC drivers, and I've pushed those up into the Tomcat shared level. I'm also relying on Tomcat providing DBCP, and have excluded these JARs when the WAR is bundled. This is saving me something in the region of 4MB of PermGen per application. It also means that when I undeploy an application, the JVM can garbage collect the ClassLoader of the web application, cleaning up the PermGen allocated to it. For the standard DSpace with JSPUI, it is only the threading in DBCP and (possibly) the JDBC drivers that is causing the ClassLoader to not be eligible for garbage collection. By pushing this into the Tomcat ClassLoader, you remove this problem, and gain in lowering the overhead at the same time. (* I think, unless you are running on Windows - iirc, you will also have to disable the URL caching by creating a startup servlet). As I alluded to, I'm running the JSPUI, and I'm precompiling the JSPs - giving me faster starts, and better pegging the PermGen usage. I've also copied the 6 or so lines from the web.xml for dspace-oai, and pasted them into the main application, so I'm running the OAI interface within the same webapp as the user interface, saving an entire web application and the 4MB-10MB of PermGen that it consumes. The quick benchmarking of XMLUI I've done suggests a minimum of 40MB PermGen per application, plus it was growing on subsequent requests (presumably due to the SAX parser String.intern() ing the element names, but there could be other causes). I've also not done a successful undeploy that allows the ClassLoader to be garbage collected - but I've not pushed at it that hard either. And in terms of the possible future, code generation libraries (ie. CGLIB and Javassist) are notoriously bad at stopping ClassLoaders from being garbage collected (and in generating / modifying classes are allocating more PermGen) - I wouldn't be surprised if this is down to the tricks they have to perform for thread safety. Of course, any PermGen allocated through a ClassLoader can not be reclaimed at all, unless the entire ClassLoader is disposed of and it - and everything loaded through it - is eligible to be garbage collected. (This is written in the Java Language Specification). Err... back from the rant... with the deployment tweaks that I outlined earlier, as I said elsewhere, I've got 24 DSpace instances running in the same Tomcat - which is using just 106MB of PermGen (although it has 256MB set aside, with room to grow). And I can do redeployments without killing it. > What I've been told, by several sources, is that Sun's 32-bit JVM > won't manage more than 2GB, but their 64-bit JVM will. So if you have > a 32-bit CPU and much more than 2GB of memory then you *may* want to > run multiple Tomcats to make use of it. However, does anybody > actually have measurements of DSpace's memory behavior over long > intervals? That is, at what point does more memory allocated to > Tomcat just mean longer intervals between longer GCs? Or does it > reach a steady-state usage level after a while? Core 2 Duo, 64-bit OS and JVM. Currently have 4GB allocated. I'm using Concurrent Mark and Sweep to better utilise the having a dual core server, and keep the application responding. G This email has been scanned by Postini. For more information please visit http://www.postini.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
