On Wed, Apr 09, 2008 at 09:32:22AM +0100, Robin Taylor wrote: > For what it is worth, we currently run 5 Dspace instances in the same Tomcat > without any problems.
I have more than that running test environments on one 2GB 1gHz Pentium III HT host in one Tomcat, and another dual 3GB Xeon 3gHz host with three production DSpace instances in a single Tomcat. Each host also runs PostgreSQL for its local DSpaces, and has little else to do. Both are running Gentoo Linux. > 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. > We are running on a Sun/Solaris > v240. We run an Apache Webserver in front of Tomcat to avoid the user > having to append 8080 to the URL. Likewise, although I understand that JSVC can be used to start Tomcat, allocate privileged ports, then switch UIDs to get rid of privileges. I'm using Gentoo's packaged Tomcat, though, and its startup script doesn't use JSVC. > We allocate 2G of memory to Tomcat, my > understanding is that Tomcat doesn't like having more although that may be > just a vicious rumour. 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? It's not good to give *all* of your memory to the servlet container. The OS can improve I/O performance substantially if it has enough buffer cache to avoid frequent trips out to disk. One rule of thumb I've heard, strictly as a starting point, is to give your servlets 3/4 of the amount of physical memory, then measure and tune. That's the amount I've set, but I'm embarrassed to say that I've not yet started the "measure and tune" steps. When I *do* start measuring, at the recommendation of many on the Tomcat list I'll be using LambdaProbe to peek at Tomcat's memory layout. Hmmm, there should be some way to make an automatic periodic sampler using the same JMI hooks that LambdaProbe does. Don't forget to tune up your DBMS monitor with enough buffer space to work efficiently, either. (Another topic I need to pursue more diligently. )-: -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpMGLcX53Zur.pgp
Description: PGP signature
------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
