I asked about the parameter aio-max-num; not present in 5.1, but present in 4.x,
in the context of needing to tune Sybase asynchronous I/O.
Dr. Blinn (dec.com address) sent me replies #1, #3, #4, and Roberto Romani (hp.com) reply #2,
which answered my query completely. Both answered very quickly!
Summarizing:
---- parameter is indeed gone, aio_task_max_num (per process parameter) is all
that is needed to be tweaked
---- sys_attrs_rt(5) man page exists in v5.1a and 5.1b, available online.
---- The Oracle tuning chapter in recent "System Configuration and Tuning" documents
has a section dealing with the aio_task_max_num parameter.
Thanks again to Dr Tom Blinn and Roberto Romani.
Extended excerpts from their replies follow my signature.
Oisin McGuinness
SMBC Capital Markets
277 Park Avenue
New York NY 10172
USA
phone: 1-212-224-4913, email: oisin_at_smbc-cm.com
Reply #1 from Tom Blinn excerpt:
"I don't have a V5.1 system handy for comparison (and anyway, V5.1 is going or
has already gone support end of life, you should be planning now how to get
to V5.1A or better yet to V5.1B).
V5.1B (which I do have handy) does have a sys_attrs_rt reference page, and it
also has an updated System Configuration and Tuning manual.
..................
There is a chapter in the System Configuration and Tuning manual on tuning
Oracle (but not on tuning Sybase), and that chapter (chapter 4) talks about
using this variable to control pages of memory "wired" for use by tasks.
......................"
Reply #2 from Roberto Romani:
The aio_max_num was eliminated because aio global data structs now
exist on a per-task basis. Since the structs are now on a
per-task basis, use the existing "aio_task_max_num" if you want to
increase the number of AIOs that a task can support.
Also on a V5.1A system, the sys_attrs_rt man page has the detail information for
the parameters..
#man -k sys_attrs| grep rt
sys_attrs_rt (5) - rt subsystem attributes
aio_task_max_num
A limit that indirectly controls the number of AIO requests that
can be wired in physical memory by restricting the amount of wired
physical memory available for a specified number of tasks. One page of
wired physical memory is available to the number of tasks specified by
aio_task_max_num.
Default: 102 (one page of wired memory per 102 tasks)
Minimum: 0
Maximum: 2,147,483,647
More from Tom Blinn:
I went and did some poking in the kernel sources. The internal variable in
V4.0x was called "aio_max" and its default value was "AIO_MAX" although it
could be tweaked with sysconfigtab (as you were doing). Basically, it was
used to size a NUMBER of the structures use for "aio" (asynchronous I/O).
In V5.1B, the closest corresponding tunable appears to be in fact what I
thought, aio_task_max_num, which corresponds to the internal variable (in
the kernel) called "aio_task_max" which also defaults initially to "AIO_MAX"
and is used to size various data structures.
So my guess (and it's only a guess unless I go dig lots deeper) is that you
want to tweak aio_task_max_num. The default is 64, I get the impression by
reading code that you tune it pretty much as you did before, although the
exact role it plays isn't totally obvious to me. But it does seem to be a
cap on the number of AIO tasks outstanding, that is, I/Os queued from user
space processes that are not yet completed. Whether the values you set up
for V4.0x are appropriate, I can't say, but it looks like if you have got
enough real physical memory, it won't hurt to use a large value.
So my belief is you should set aio_task_max_num as you were setting the old
aio-max-num and if it's good, don't mess with it further (that is, set it
high enough to get the SyBase errors to go away).
And excerpted from a last message from Tom Blinn:
...........................................................The V5.x code base split
off from V4.0x shortly after V4.0D and a LOT of stuff got rewritten, a
new naming scheme for the tunables got introduced, in the case of this
AIO stuff, it looks like a lot of changes got made in response to the
NUMA work done for V5.1 (there were BIG changes in a lot of the kernel
subsystems to deal with getting decent scalability and performance on
things like the new GS320 system, and this subsystem was one of those
that looks like it got a lot of real work). In any case, as I wrote
in the message that crossed paths with this one, it looks from reading
the kernel code that you just tune the new aio_task_max_num the same
way you would the older variable, the larger values allow you to have
more outstanding active I/Os and that seems to be what SyBase wants.
Received on Tue Nov 25 2003 - 22:41:52 NZDT