Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/ 2Gb ram
and 4 processors that seems very slow on a large sequential write (I suppose
that the problem resides in the dbspaces on filesystem...). Any suggestion?

My onconfig it's set as follow:

# System Configuration

SERVERNUM 0 # Unique id corresponding to a OnLine
instance
DBSERVERNAME sbn # Name of default database server
DBSERVERALIASES sbn_tcp # List of alternate dbservernames
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed
env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)

MULTIPROCESSOR 1 # 0 for single-processor, 1 for
multi-processor
NUMCPUVPS 4 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to
one

NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors

# Shared Memory Parameters

LOCKS 120000 # Maximum number of locks
BUFFERS 262144 # Maximum number of shared buffers
NUMAIOVPS # Number of IO vps
PHYSBUFF 64 # Physical log buffer size (Kbytes)
LOGBUFF 64 # Logical log buffer size (Kbytes)
CLEANERS 1 # Number of buffer cleaner processes
SHMBASE 0x0A000000L # Shared memory base address
SHMVIRTSIZE 8000 # initial virtual shared memory segment size
SHMADD 32768 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 64 # Stack size (Kbytes)

--

Laverio wrote:
> Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/ 2Gb ram
> and 4 processors that seems very slow on a large sequential write (I suppose
> that the problem resides in the dbspaces on filesystem...). Any suggestion?
>
> My onconfig it's set as follow:
>

The $ONCONFIG is one thing, but some information from the instance / O/S
/ usage / expectations / load on machine / etc. etc. would be some of
the other things needed to really provide some decent tuning suggestions
however ...
> # System Configuration
>
> SERVERNUM 0 # Unique id corresponding to a OnLine
> instance
> DBSERVERNAME sbn # Name of default database server
> DBSERVERALIASES sbn_tcp # List of alternate dbservernames
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed
> env.
> RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
>
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for
> multi-processor
> NUMCPUVPS 4 # Number of user (cpu) vps
Limit to 1, give the O/S some
> SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to
> one
>
> NOAGE 0 # Process aging
Set to 1, don't let the O/S bring ya down in priority
> AFF_SPROC 0 # Affinity start processor
> AFF_NPROCS 0 # Affinity number of processors
>
> # Shared Memory Parameters
>
> LOCKS 120000 # Maximum number of locks
> BUFFERS 262144 # Maximum number of shared buffers
512Mb of buffers, can ya give any more?? Depends on what else is on your
machine.
> NUMAIOVPS # Number of IO vps
Humm, blank entry is bad, specify a number (something like Number of
"active" chunks to start with and then search on this newsgroup for I/O
stuff)
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 1 # Number of buffer cleaner processes
Humm, 1 is ... low, increase to what you have increased NUMAIOVPs to to
start with
> SHMBASE 0x0A000000L # Shared memory base address
> SHMVIRTSIZE 8000 # initial virtual shared memory segment size
Humm, seems low, check onstat -g seg, add all the ones with a V type,
and increase this value to that.
> SHMADD 32768 # Size of new shared memory segments (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 300 # Check point interval (in sec)
> LRUS 8 # Number of LRU queues
Humm, OLTP vs MIS - OLTP - with BUFFERS set to 512MB suggest 65, for MIS
suggest 17
> LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
Whoa there Lesley, if you care about checkpoint duraction, take this
down to 4 / 2 (i.e. 4% of 512Mb of BUFFERS is about 8Mb; should be able
to clear in under a second or two.
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>

BUT ... you should test this first

"Laverio" <laverioNO@z-1000.net> wrote in message
news:cac7sg$e8v$1@newsreader.mailgate.org...
> Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/ 2Gb ram
> and 4 processors that seems very slow on a large sequential write (I
suppose
> that the problem resides in the dbspaces on filesystem...). Any
suggestion?

Can you post the service times and queues you're getting from the relevant
disks using, say, vmstat or sar?

> My onconfig it's set as follow:
> RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)

Set to 1. (I *think* this is good on Solaris ....)

> NOAGE 0 # Process aging

Ditto.

> # Shared Memory Parameters
> NUMAIOVPS # Number of IO vps

You imply you're using cooked files, so no kaio. In this case you should
set this parameter equal to the number of physical disks that contain
chunks, plus some.

> CLEANERS 1 # Number of buffer cleaner processes

Have this to 8, or the number of physical disks, whichever is the higher.

> SHMVIRTSIZE 8000 # initial virtual shared memory segment
size

Ugh! What does onstat -g seg show?

> LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit

You could reduce thse to, say, 10 and 5 or lower.

Captain Pedantic wrote:
> "Laverio" <laverioNO@z-1000.net> wrote in message
> news:cac7sg$e8v$1@newsreader.mailgate.org...
>> Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/
>> 2Gb ram and 4 processors that seems very slow on a large sequential
>> write (I suppose that the problem resides in the dbspaces on
>> filesystem...). Any suggestion?
>
> Can you post the service times and queues you're getting from the
> relevant disks using, say, vmstat or sar?
>
>> My onconfig it's set as follow:
>> RESIDENT 0 # Forced residency flag (Yes = 1, No
>> = 0)
>
> Set to 1. (I *think* this is good on Solaris ....)
>
>> NOAGE 0 # Process aging

But reduce NUMCPUVPS to 3 or you'll probably discover the machine is
crippled for other reasons.

Sorry, gotta go now, but i'll try to throw in a bunch more ideas on tuesday
(monday is a public holiday for us here in australia. God Save the Queen. I
knew there had to be a good reason to retain the monarchy.)

Laverio wrote:
> Hi guys, I'm trying to speed up an IDS 9.30 on a Sun 7.5 system w/
> 2Gb ram and 4 processors that seems very slow on a large sequential
> write (I suppose that the problem resides in the dbspaces on
> filesystem...). Any suggestion?


The following is my standard advice, what I consider a starting point.

1) get the chunks out of filesystem and into raw spaces! I understand that
Solaris offers a filesystem switch which makes it unbuffered, and therefore
nearly as efficient (give or take a few structural disk reads) as raw
spaces. At the very least, get this option switched on for the filesystem.
This still won't let you reap the benefits of KAIO which only works with raw
spaces (unless I don't know enough about Solaris)

> SERVERNUM 0 # Unique id corresponding to a OnLine
instance

The files always say zero. One day some dummy might start a new engine, and
then they'll smash each other. Change this number the next time you bounce
the engine. It's a long-shot piece of paranoia that might save you one day.

> RESIDENT 0
Set RESIDENT to -1 because you have so much memory, you want to GUARANTEE
that nothing ever pushes it out to swap space. I understand that Solaris
will dynamically steal pages for lots of file buffering, and that's most
likely going to happen since you are using filesystems to store chunks. Take
control of the system and mandate the use of resident engine memory.

> NUMCPUVPS 4 # Number of user (cpu) vps
> NOAGE 0 # Process aging
> AFF_SPROC 0 # Affinity start processor
> AFF_NPROCS 0 # Affinity number of processors

If it's a 4-cpu machine, set all of these to (in order) 4,1,2,3 or 4,1,1,3.
The 3rd parameter changes depending on how Solaris numbers the CPU's. You
should leave the first CPU for the O/S, hardware and user processes, and let
IDS take over the others. If you find that the user processes are not
getting enough (unlikely if it's only 4GL programs or similar) then reduce
NUMCPUVPS and AFF_NPROCS to 2. See also below for advice on NETTYPE

> BUFFERS 262144 # Maximum number of shared buffers

That's close enough to 1/2 a gig. You're probably happy with that.

> NUMAIOVPS # Number of IO vps

There's a formula for the default here. I don't know it. I ain't going to
look in the manual :-()

Set this to N * 1.5, where N = number of chunks you have in the dbspaces.
It's a start.

> CLEANERS 1 # Number of buffer cleaner processes

No way enough. One per chunk. Helps during checkpoints. I don't know how
many disks and chunks you have (please reply) but then again, using files in
filesystems sort-of interferes with my usual advice on this. Did I suggest
you use raw spaces?

> SHMVIRTSIZE 8000
> SHMADD 32768

This is NOTHING! the output of onstat -g seg probably has 30 lines... Look
at the output of onstat -g seg, count up all the segments marked as class V,
then allocate that number * 32768 as the SHMVIRTSIZE. Add another 20% for
good luck. Make SHMADD about 25% of that number.

> LRUS 8 # Number of LRU queues

Match this to the number of cleaners you choose. When not doing checkpoints,
the cleaners will sometimes flush pages from your LRU queues. Give them one
each so they don't get jealous.

> LRU_MAX_DIRTY 60
> LRU_MIN_DIRTY 50

If your checkpoints are horribly long, reduce these factors. Look in the
message file for checkpoint times, and especially look for long checkpoints.
If they are more than 2 or 3 seconds sometimes, then you need to drastically
reduce these percentages to limit the number of dirty pages. If your worst
checkpoint is 30 seconds (for example) and you desire 3 second checkpoints,
then the factor is 30/3 = 10. Reduce your LRU_*_DIRTY by a factor of 10 each
and see what happens. Monitor your checkpoint durations.

That's a start. But get your data into raw spaces and start using KAIO.

Andrew Hamm wrote:
>
> See also below for advice on NETTYPE

hmmm - there wasn't any 'cos you didn't post your NETTYPE parameters :-)

make sure your nettypes look something like:

NETTYPE soctcp,1,100,NET
NETTYPE ipcshm,3,50,CPU

NOTE: soctcp might be tlitcp on Solaris.

Always run soctcp/tlitcp on NET processes. Allow each one to handle a
maximum of maybe 200 connections, therefore the first number starts to rise
once you exceed the need for 100-200 tcp connectors.

and always run ipcshm on CPU processes. Allow them to handle upto maybe
150-200 connections each. Make the first number equal to the NUMCPUVPS
parameter - this improves load balance. If you must make the 2nd number
greater than maybe 200 (check the manual for advice on load capacity, I
forget the details) then it's probably a hint that you might need another
CPU or two.