On Tue, 25 May 2004 08:51:20 -0400, Reinhard Habichtsberg wrote:
> Art S. Kagel wrote:
>> Once you have a running system, run onstat -g iov, as Madison suggests. If
>> there are a few aio VPs with io/wkup less than 1.0 then you are OK. If
>> there are many such you can reduce them, but check across a peak load
>> first. If there are none with io/wkup < 1.0 then you definitely need more
>> AIO VPs.
>
> Correct me if I'm wrong: onstat -g iov has no column io/wkup in the output
> only io/wup which never falls below 1.0 here. Did you possibly thought of
> the column io/s?
NO, io/wup can indeed fall below 1.0 if you are configured correctly, and I
DO indeed mean you shoule monitor io/wup. If you are showing io/wup 1.0 or
above for all aio VPs then you will improve performance (EVEN if all of your
chunks are RAW and you are using KAIO for chunk accesses) by increasing the
number of AIO VPs until at least one of these show io/wup <1.0 (ie: 0.9 or
0.8). A value < 1.0 means that at least some of the time when that VP was
awakened to perform work because all other AIO VPs were busy, some other VP
had completed what it was doing and handled the request before the newly
awakened VP could get to the queue. This is GOOD THING and means that you
have some extra capacity to perform even more IOs without waits affecting
performance. If every AIO VP has io/wup >= 1.0 that means that some
percentage of IOs are waiting for a VP to free up which is slowing you down.
As I said this is even true if you are using KAIO for all chunk access, as the
message and console log IO and IO to event files like .af files are handled by
the AIO VPs, so eliminating wait time for the administration of the engine's
internals will also improve performance.
Art S. Kagel