IIslaves setting

On Jul 26, 15:11, Michael McGarrigle wrote:
> Subject: Optimum number of slaves
> Does anybody have any knowledge of what the optimum number of slave
> processes should be?  We currently have 4 dbms server processes with
> 8 slave processes per server ..

I have heard various odd statements about slaves, but what seems to make
the most sense to me is:  two slaves, minimum.
			  one slave per ingres data location, minimum.
If a data location is on a fast or buffered drive, maybe two slaves for
that location.
If a data location is a multidrive array (eg a striped RAID setup), one
slave per drive.
I doubt that having a few too many slaves hurts anything other than using
up memory, so maybe start with the above for a first guess and then
toss in another slave or two.

Take a look at the number of write-behind threads you have, too.
I believe there is no point in having more write-behinds than slaves.

-- 
Karl Schendel            Phone: (412) 963-8844
Telesis Computer Corp      Fax: (412) 963-1373
wiz@telesis.com



From: Roy Hann 
Subject: Re: iislave

>We have Ingres 6.4/06 running on a HP-D270 machine with 128Meg RAM.  We
>are running one IIDBMS process and two IISLAVE processes.
>
>Would it increase the performace of the db if we ran more IISLAVE
>processes?

Almost certainly.  I reckon on starting with one per location per server,
plus a few for luck.  The maximum you are allowed is thirty per server.  Add
more write-behind threads too.  My rule of thumb is to have one WB thread 
fewer than the number of slaves.   Too many slaves is benign, too few is
potentially a serious bottleneck, so err on the side of too many.  Each
server process will get its own set of slaves.  If you configure 10 and
start two iidbms servers, you will end up with 20 slaves.

>Is it possible to run more than one IIDBMS process on a machine that has
>a cpu count of one?

Yes, and in 6.4 it is an excellent way of getting more CPU time for Ingres.
(Also you can create named server classes and vector different users or jobs
to different servers.  For instance it is often worthwhile segregating OLTP
and batch jobs, or OLTP and reporting, because batch jobs tend to be
sort-intensive, which has the unexpected side-effect of making Ingres less
responsive.  I'll give you the procedure if you don't already know it.)

One problem you've got is that you don't have a heck of a lot of memory, so
make sure you don't start paging like crazy when you add more processes.
 
Roy Hann
BKB Client/Server (UK) Ltd.
Ingres Q & A
To William's Home Page
Email William