Thanks all for your responses. I might see what happens if I renice the
oninit processes to make them run more often/longer. I can't help but
think that one of the reasons that performance is better is that adding
more CPUVPs effectively doubles the amount of CPU time IDS is getting.

-----Original Message-----
From: owner-informix-list@iiug.org [mailtowner-informix-list@iiug.org]
On Behalf Of Darryl Priest
Sent: Tuesday, February 08, 2005 12:36 PM
To: informix-list@iiug.org
Subject: Re: More CPUVPs than processors

I also had fear about breaking from the golden rule, but got much
better performance on 9.40 on AIX 5.2 with 4 physical processors using
up to 12 CPUVPs.

I think the test, test, test mantra is appropriate here, and it's easy
to do, since the CPUVPs can be added dynamically.


sending to informix-list

"Mark" <mark@vuntec.com> wrote in message news:<1107909506.05b010d31b61d05ef5b592c7476757b2@ teranews>...
> Thanks all for your responses. I might see what happens if I renice the
> oninit processes to make them run more often/longer. I can't help but
> think that one of the reasons that performance is better is that adding
> more CPUVPs effectively doubles the amount of CPU time IDS is getting.
>

I assume you have NOAGE set to 1 and it works on your platform?

This keeps bugging me...with more CPUVPS than physical CPUS we should
just be spending more time context switching between VPS. Threads can
migrate from one VP to another so e.g. 6 Physical CPUS = 6 active
CPU VPs..where do the other ones run? Surely all we are getting is
more context switching, more CPU cache flushing, more CPU time spent
in the OS scheduler code so where is the benefit? All I can think of
is a) Informix latch issue which scales with more CPUS(More latches =
more concurrency) b) OS is crap? c) more CPU VPS = more KAIO requests
which can be outstanding at one time so we can keeping the queue of
requests per controller deeper and so elevator sorting is more
effective..do the KAIO queues have a fixed max depth? Informix need to
investigate..

Can someone check onstat -g spi sorted bu num waits and see if it is
different?
Otherwise Informix (IBM) need to do some serious investigation why
this is happening!!

"David Williams" <smooth1x@hotmail.co.uk> wrote in message
news:264b3403.0502091543.3c381450@posting.google.c om...
> "Mark" <mark@vuntec.com> wrote in message
> news:<1107909506.05b010d31b61d05ef5b592c7476757b2@ teranews>...
>> Thanks all for your responses. I might see what happens if I renice the
>> oninit processes to make them run more often/longer. I can't help but
>> think that one of the reasons that performance is better is that adding
>> more CPUVPs effectively doubles the amount of CPU time IDS is getting.
>>
>
> I assume you have NOAGE set to 1 and it works on your platform?
>
> This keeps bugging me...with more CPUVPS than physical CPUS we should
> just be spending more time context switching between VP ...

Well, yes, I too fail to understand how, conceptually, having more cpu vps
than cpus can work. Since several respected people have reported that it
does, it would be terrific if some IBM Informix God such as Madison or
Jonathan could explain to us how it might.

Neil Truby wrote:
<SNIP>
>>This keeps bugging me...with more CPUVPS than physical CPUS we should
>>just be spending more time context switching between VP ...
>
>
> Well, yes, I too fail to understand how, conceptually, having more cpu vps
> than cpus can work. Since several respected people have reported that it
> does, it would be terrific if some IBM Informix God such as Madison or
> Jonathan could explain to us how it might.

Here's my take, there are at least 2 advantages I see to more CPU VPs than
CPUS to explain why it does indeed help:

1- with multi-pipelines CPUs, multiple threads of execution are possible in
each CPU so we SHOULD be executing code concurrently in as many as 2x #CPUs
CPUVPs on such machines. This would be especially true in the hyperthreaded
P4's and similar architectures like the latest SPARC generation.

2- the KAIO thing. There is only one KAIO thread per CPU VP, and while the
VP will put more IOs into it's queue while some execution threads sleep and
others run, that thread can only issue and reply to requests at a limited
rate. Note that once all of the threads assigned to a VP are waiting on
IOs, nothing is getting done until some data comes back, so the CPU VPs are
still blocking waiting on IO when the KAIO queue backs up. One of the posts
showed a CPU VP with a max queue length of >480 requests. Unless there are
several hundred threads running on that BP, something is waiting at that
point. With more CPU VPs, there will be more KAIO queues so the queue
length of any one will be shorter and more IOs will be submitted to the OS
concurrently keeping everything moving.

Art S. Kagel

Solaris has something called turnstiles in the thead management code
that was written to help alleivate mutex locking and priority problems.
In particular it removes the priority inversion problem associated with
sleep queue implementation of thread and resource control. This code
was re-written in Solaris 7, AFAIR this was when the 450+ processes
starting to be more common.

Have a look at the Solaris Internals book by Jim Mauro

David Williams wrote:

> "Mark" <mark@vuntec.com> wrote in message news:<1107909506.05b010d31b61d05ef5b592c7476757b2@ teranews>...
>
>>Thanks all for your responses. I might see what happens if I renice the
>>oninit processes to make them run more often/longer. I can't help but
>>think that one of the reasons that performance is better is that adding
>>more CPUVPs effectively doubles the amount of CPU time IDS is getting.
>>
>
>
> I assume you have NOAGE set to 1 and it works on your platform?
>
> This keeps bugging me...with more CPUVPS than physical CPUS we should
> just be spending more time context switching between VPS. Threads can
> migrate from one VP to another so e.g. 6 Physical CPUS = 6 active
> CPU VPs..where do the other ones run? Surely all we are getting is
> more context switching, more CPU cache flushing, more CPU time spent
> in the OS scheduler code so where is the benefit? All I can think of
> is a) Informix latch issue which scales with more CPUS(More latches =
> more concurrency) b) OS is crap? c) more CPU VPS = more KAIO requests
> which can be outstanding at one time so we can keeping the queue of
> requests per controller deeper and so elevator sorting is more
> effective..do the KAIO queues have a fixed max depth? Informix need to
> investigate..
>
> Can someone check onstat -g spi sorted bu num waits and see if it is
> different?
> Otherwise Informix (IBM) need to do some serious investigation why
> this is happening!!


--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #