Doh! I just noticed I forgot to include the total number of unique titles in our repository: ~7,600.
And thanks to Keith Gilbertson for the replies. I've dug through catalina.out for the past few days, and the only errors we're seeing is typical broken pipe warnings, from users moving on before a thread finishes. Hmm... maybe it's safe to scale back the nightly tomcat reboot to a weekly reboot? --Hardy > -----Original Message----- > From: Pottinger, Hardy J. [mailto:pottinge...@umsystem.edu] > Sent: Thursday, September 30, 2010 5:36 PM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] DSpace Setup > > 1. Contact Info: Hardy Pottinger, University of Missouri (MOspace) > (message sent from my main e-mail address, use that). > > 2.a. DSpace 1.6.2 (XMLUI) with local mods for user interface, and > Shibboleth special groups handling > 1 assetstore at 1TB, 35GB used (big plans! really!) > Number of items: > > 2.b. Oracle Database 10g Enterprise Edition Release 10.2.0.4.0, running > on another server (unknown spec) > > db.maxconnections = 50 (anything less than 50 is unstable) > db.maxwait = 5000 > db.maxidle = 0 (idle connections are nailed by the firewall on the > Oracle server, sysadmins will not change) > > 2.c. All RHEL-provided, Tomcat 5.5.23, running behind Apache 2.2.3 via > mod_proxy > > 2.d. DSpace and Tomcat are on one server, Oracle db is on a shared > server. > > Server: Dell PowerEdge 2950 > Memory size: 8110 MB > CPUs: 4 x Intel Xeon 5160 @ 3.00 GHz > OS: Red Hat Enterprise Linux Server release 5.5 (kernel 2.6.18- > 194.3.1.el5PAE) > > 2.e. JAVA_OPTS="-Xmx512M -Xms256M" (this will likely change soon, need > to bump up PermGen) > > 3. Back when we were running on DSpace 1.5.1, after a period of about > 24-36 hours of uptime, Tomcat became unavailable. Apache reported 503: > service unavailable. Looking at a dump after killing all Java processes, > it appeared that all database connections were unavailable. Changing the > db.maxconnections and db.maxidle settings (see above) was helpful, but > we are proactively rebooting tomcat and apache every night, to "clean > out the cobwebs". Have not disabled the nightly reboot since the upgrade > to 1.6.2, so do not have current data/log files. I'm willing to try > other config settings. I'm pretty sure I saw an interesting looking > patch that drops database connections (mainly for streaming situations) > that I can't seem to find right now, but might help this particular > stability issue. > > 4. Volunteer to help? Of course! I am a fledgling Java developer, > reasonably competent application manager, and working with XSLT only > makes me want to cry a little bit, nowadays. :-) We have a development > server with a snapshot of our live repository, and are willing to do > load testing, run a profiler, whatever it takes to help. We're certainly > not experts in any the various tech running under the hood of DSpace, > but keeping our repository running smoothly is our main job, and we aim > to please. You may use my address as the main contact, but we have two > more developers here who are willing to pitch in. > > --Hardy > > > -----Original Message----- > > From: George Stanley Kozak [mailto:g...@cornell.edu] > > Sent: Wednesday, September 29, 2010 11:28 AM > > To: dspace-tech@lists.sourceforge.net > > Subject: [Dspace-tech] DSpace Setup > > > > Hi... > > Based on Tim Donohue's suggestion to share configuration and setup > > information, here is Cornell University's Dspace configuration: > > > > 1. Server: Sun sun4v T5140 > > Memory size: 65312 Megabytes (4 CPUs) > > > > 2. Running DSpace 1.6.2 (JSPUI) with local mods for User Interface, > > Embargo, and Refworks. > > db.maxconnections = 50 > > db.maxwait = 5000 > > db.maxidle = 5 > > 2 assetstores at 300GB each (using currently 323 GB) > > Number of items: 14,960 > > Number of Communities/Collections: 789 > > > > 3. Java 1.5.0_24 > > > > 4. Apache 2.29 running mod_jk to tomcat > > > > 5. Tomcat 5.5.26 > > JAVA_OPTS="-server -Xms1024m -Xmx2048m -Xmn64m > > -Dfile.encoding=UTF-8 > > -XX:+UseParallelGC -verbose:gc > > -Xloggc:/dspace/dspace/log/gc.log > > -XX:+HeapDumpOnOutOfMemoryError > > -XX:PermSize=1024m -XX:MaxPermSize=1024m > > -XX:-UseGCOverheadLimit" > > > > 6. PostGreSQL 8.3 > > max_connections = 300 > > shared_buffers = 32MB > > max_fsm_pages = 204800 > > > > Though we experienced some performance problems in the past, that > seemed > > to disappear after we went to DSpace 1.5.2. > > > > George Kozak > > Digital Library Specialist > > Cornell University Library Information Technologies (CUL-IT) > > 501 Olin Library > > Cornell University > > Ithaca, NY 14853 > > 607-255-8924 > > > > ---------------------------------------------------------------------- > -- > > ------ > > Start uncovering the many advantages of virtual appliances > > and start using them to simplify application deployment and > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > DSpace-tech mailing list > > DSpace-tech@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------ > ------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
