Wow. Thanks for all the info Peter! Can you tell me what kind of special configuration this took, or is it all specified in the dspace.cfg file?
That would be great if it is! Thanks again, Sue ------------------------------------------------------------------------ Sue Thornton Office: (757) 224-4130 Mobile: (757) 506-9903 [email protected]<mailto:[email protected]> From: Peter Dietz [mailto:[email protected]] Sent: Friday, May 17, 2013 1:02 PM To: Thornton, Susan M. (LARC-B702)[LITES] Cc: dspace-tech ([email protected]); Dedmond, Nicole K. (LARC-B702)[LITES] Subject: Re: [Dspace-tech] Postgres configuration with DSpace Hi Sue, Here at Ohio State Libraries we've gone through a server "refactoring", trying to improve DSpace performance, by reducing server load, and its worked really well. So, about a year ago, our server situation was a Production DSpace server running everything: Apache, Tomcat, Postgres, SOLR, Elastic Search. An incoming user request hit, makes the server's apache process shuffle it to tomcat, tomcat then has the DSpace code do some logic, which probably makes a request to the database, and by the end, the event gets logged into SOLR and Elastic Search. At each point, each service is competing for server resources and attention. So, we have changed things, and now have a separate Apache server, a separate Postgres server, a separate Elastic Search server, and we plan to sunset using SOLR in the next few months. · The apache server is now the central entry point for all of our Library webapps, theres several dozen things running through it, and all it does is hand off requests more or less. · The postgres server, is currently also sitting on the same server as our MySQL server (for LAMP apps), and its running fine enough. We have configured our production-dspace and staging-dspace to use our centralized postgres server to do all the postgres stuff. · We've pulled Elastic Search off of our dspace server, and that actually made the most performance improvement (you probably don't use elastic search statistics, so dont worry about that one). I don't think we have cold hard data of how beneficial this was, but, there's much less on-call 2am issues to respond to. Each server is siloed, and does one thing. When a request comes in, each server does what it needs to, and finishes, not holding things open, waiting for resources to free up, then getting back to it. We've been making tons of DSpace-code modifications to speed up certain requests (i.e. login, /submissions page, community/collection list, start a new submission - select collection step), but, I do attribute a better server architecture too. If your database ever became the bottleneck, then you would be able to clearly identify what the issue are. Disk IO, network traffic, CPU, memory, for that one box. As opposed to getting mixed signals from tomcat also running on the same box. One thing that I believe postgres does really well, but haven't used it in practice, is clustering. If you run into problems, and need to scale, you could add multiple postgres servers to form a pool, and they will distribute the work-load, automatically become replicas, and lots of magic. I think thats called Postgres-XC. Peter Dietz On Fri, May 17, 2013 at 12:42 PM, Thornton, Susan M. (LARC-B702)[LITES] <[email protected]<mailto:[email protected]>> wrote: [cid:[email protected]] Hello, Can anyone tell me if it’s a workable solution to put Postgres on a separate server from your Dspace application? In the past, we’ve had them on the same server, but are considering configuring a Postgres-only server so that we don’t have Postgres instances all over the place. We currently have most of our Dspace instances on Sun Solaris 10/Unix machines. If this is possible (I’m thinking it is), can anyone list pros and cons of implementing this configuration? Are they any performance issues we need to be aware of, etc? Thanks in advance, Sue ------------------------------------------------------------------------------------------------------------------------- Sue Thornton Software Developer/DBA SGT, Inc. ~ LITES Contract NASA Langley Research Center 130 Research Drive, Hampton, VA. 23666 Office: (757) 224-4130<tel:%28757%29%20224-4130> Mobile: (757) 506-9903<tel:%28757%29%20506-9903> Fax: (757) 224-4001<tel:%28757%29%20224-4001> [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ DSpace-tech mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
<<inline: image001.gif>>
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
