Re: Shared Memory Parameters?
Posted in 2000
You have only 21 chunks. In this situation may I know the reason for 56
NUMAIOVPS. Is it not possible to use KAIO ?
Alkesh Vipani.
----- Original Message -----
From: "COOPER, Joseph" <Joseph.COOPER@sema.co.uk>
To: "'Calvin Shoults'" <jcsatlcom.net@mindspring.com>;
<informix-list@iiug.org>
Sent: Wednesday, February 16, 2000 3:11 AM
Subject: RE: Shared Memory Parameters?
> > I am working with an existing database that has some onconfig
> > parameters
> > that I am questioning.
> >
> > One of our problems is extents, but another reason we get
> > hammered during
> > the day might be the following shm parameters.
> >
> > OL Engine Vers. 7.31 on HP 9000
> > Aprx. 400-600 users
> > Database - 14 gig
> > 6 - CPUS
> > 21 chunks used for database
> >
> > # Locks - 200,000
> > # Buffers - 300,000
> > # NUMAIOVPS - 56
> > # PHYSBUFF - 1024
> > # LOGBUFF - 128
> > # LOGMAX - 50
> > # CLEANERS - 22
> > # SHMVIRTSIZE - 1,400,000
> > # SHMADD - 131,072
> > # SHMTOTAL - 0
> > # LRUS - 56
> > # LRU_MAX_DIRTY - 5
> > # LRU_MIN_DIRTY - 2
> > # STACKSIZE - 32
> >
> > I am considering changing to
> >
> > # Buffers - 2,000
> > # LRUS - 50
> > # LRU_MAX_DIRTY - 60
> > # LRU_MIN_DIRTY - 50
> > # CLEANERS - 8
>
>
> As a general rule CLEANERS should equal LRUS.
> I am confused as to why you want 2000 buffers and 50 LRUS.
> That would put 40 buffers in each LRUS ? Am I missing something ?
>
> At first glance I would imagine you are getting
> hammered during the day by the 400-600 users.
>
> Perhaps you could be a bit more specific as to what performance problems
you
> are having.
> onstat -p # would let us decided on the real performance.>
> The number of chunks shouldn't make much difference as such but the
> positionining of the chunks is of greater importance.
>
>
> Jo
>
>
>
___________________________________________________________________________
> This email is confidential and intended solely for the use of the
> individual to whom it is addressed. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of
> Sema Group.
> If you are not the intended recipient, be advised that you have received
this
> email in error and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited.
>
> If you have received this email in error please notify the Sema Group
> Helpdesk by telephone on +44 (0) 121 627 5600.
>
___________________________________________________________________________