From: Dave F. <dav...@gm...> - 2012-01-03 19:51:16
|
We routinely run multiple eXist instances on our development server that is a bit "oversized", too (it has 24 Gb of physical RAM, so we'll often have 3 or 4 instances each configured to use up to 4Gb of memory if needed). Only major gotcha for multiple instances on a single server is make sure you use distinct port numbers for each of the instances. It's also a very good idea for each eXist instance to run under its own user account (as we do). Those two steps effectively eliminate the possibility for conflicts between instances. On Tue, Jan 3, 2012 at 1:44 PM, Palmer, Eric <ep...@ri...> wrote: > Dave > > Thanks > > Hadn't considered running multiple instances on a single server. I'll > have to think through that. Or we can buy 4 physical servers and make them > smaller. > > Humm, > > Things to think about. > > From: Dave Finton <dav...@gm...> > Date: Tue, 3 Jan 2012 14:41:16 -0500 > To: Eric Palmer <ep...@ri...> > Cc: "exi...@li..." <exi...@li...>, > Matthew Levy <ml...@ri...>, ~Web Services < > Web...@ex...>, "Gravely, Phillip" < > pgr...@ri...> > Subject: Re: [Exist-open] sizing eXist-db servers > > My brief answers are below. > > >> We are assuming that Sun Java JVM and exist-db >> >> - use 64 bit RHEL >> >> Yes they will > >> >> - Will use lots of Memory if needed and allocated >> >> As much as you want to give it (I've gone as high as 8Gb for a single > instance, and it will use it if it needs it) > >> >> - Support multi core multi thread servers >> >> That *could* be a question mark, there. While it definitely will run > quite well on a multi-core architecture (we use an Intel i7), I'm not > certain it really does a great job of taking advantage of all the > capabilities of having multiple cores. Now, if you have several instances > of eXist running in parallel, then certainly each instance will run quite > happily on whatever core the operating system chooses to allocate to it. > >> >> - We are assuming that we are over sizing the servers >> >> There is no such thing as over-sizing the servers. :^D > > On Tue, Jan 3, 2012 at 1:29 PM, Palmer, Eric <ep...@ri...> wrote: > >> Looking for anyone to challenge us to think differently on the following: >> >> The U of Richmond is getting ready to specify replacement servers. Today >> we serve up a variety of exist content, mostly indexed with Lucene. Some >> with range indexes and ngram. >> >> Today we have RHEL 32 bit dual - dual cores with 4 GB ram total (2 BG >> allocated to exist-db). And this runs on the same box that Oracle is >> running on. The server's performance is barely acceptable but we wish it >> could be better. And we know that eXist db usage is growing. >> >> 99% of our queries return small (1k to 10k ) chunks of xml. We *do not*use exist to transform that into html. Just xml results. >> >> In the next 3 years we will end up with 20,000 or more documents. We >> expect no more than 120 queries a minute at a peak. >> >> We do cache most xquery results so that is factored in the 120 queries a >> min. >> >> We have a couple of queries that return xml in the 12 MB size range. But >> we cache these queries in our apache server that front ends exist so that >> tends not to be a large factor. >> >> Operating system will be RHEL 64 Bit (6.x) >> We will probably have dual quad cores >> We are thinking 8 GB / Core or 16 GB total per server. >> >> >> We will load balance (session count balance) the two servers. >> >> Sun Java 1.6 today. >> >> We are assuming that Sun Java JVM and exist-db >> >> - use 64 bit RHEL >> - Will use lots of Memory if needed and allocated >> - Support multi core multi thread servers >> - We are assuming that we are over sizing the servers >> >> We will NOT be doing TEI and will not be managing large documents in >> exist. >> >> We do write up to 1000 documents into exist each day but these are http >> puts and not xquery updates. (we replace existing documents mostly). >> >> For the 99% queries we want subsecond performance (yes the xquery and >> indexes matter, we get that) and we want 3 standard deviations to perform >> (99.7%) within that 1 second. >> >> Thanks in advance for any advice or whatever. Sizing exist for us seems >> to be more difficult (a guess) than sizing apache httpd (but we have a lot >> more experience with that). >> >> >> Thanks >> Eric Palmer >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. Create >> new or port existing apps to sell to consumers worldwide. Explore the >> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >> http://p.sf.net/sfu/intel-appdev >> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> >> > > > -- > David Finton > -- David Finton |