I have a question concerning some tunables in /etc/system associated
with priority paging and Solaris 8.
In the Sun/Oracle Best Practices paper, it mentions that, in
addition to 'set priority_paging=1', that a couple of other tunables
be defined:
set fastcan=131072
set maxpgio=65536
Is fastscan and maxpgio still applicable in Solaris 8?
Thanks,
Lou Avrami ( [EMAIL PROTECTED] )
------------------------------
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2001 17:10:01 -0600 (CST)
Subject: RE: New Sun/Oracle Blueprint available
Hi Ross,
I forwarded your comments on to the author, Bob Sneed, who replies
below.
Dave Miller
Sun Microsystems, Inc.
>
>------------- Begin Forwarded Message -------------
>
>Date: Thu, 25 Jan 2001 09:58:14 -0800
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>X-Comment: Oracle RDBMS Community Forum
>X-Sender: "Mohan, Ross" <[EMAIL PROTECTED]>
>From: "Mohan, Ross" <[EMAIL PROTECTED]>
>Subject: RE: New Sun/Oracle Blueprint available
>X-ListServer: v1.0f, build 69; ListGuru (c) 1996-2000 Bruce
A. Bergman
>Mime-Version: 1.0
>
>Dave,
>
>The doc looks useful, so thanks for posting this URL. There
is plenty
in the
>document to recommend it.
>
>
>But, here is this gem from the document itself:
>#########################################################################
>"An AIO problem has often been perceived when truss is used
to observe
>Oracle I/O operations. With AIO on filesystems, a kaio(2) call
can be
>observed to routinely return ENOTSUP results, and the mistaken
conclusion is
>drawn that AIO is 'broken'. Actually, the kaio(2) system call
is not an
>exposed interface. That is, only the library functions aioread(3)
and
kin
>are published as supported by Sun, and kaio(2) is one of the
secrets to
the
>libaio.so implementation underlying the AIO API. In other words,
this
is not
>a bug - it's a feature!"
>#########################################################################
>
>
>Huh? An OS call returns an Error, but is really OK? The real
AIO is a
>hidden "secret" that Sun customers cannot track or read up on,
so it's
not
>a bug, but a "feature"?. Sequent ( now IBM ) has had Async IO
since
1995,
>and the calls never threw exceptions when viewed with truss.
Good comment! I despise all the 'Secrets of ...' books I see
in
bookstores, as they run against the grain of 'open', right?
In this case, there is indeed no man page for the kaio(2) call,
but
since it is cleary visible by truss, it is no real secret. The
Sun
libaio implementation has previously been discussed in SunWorld
online,
further reducing the 'secret' aspect of this. Don't expect to
see
kaio(2)
documented, though, as it is quite subject to change, and we
do try to
keep customers and ISV's out of the trouble that comes from interfacing
with moving targets in the OS.
Historically, most vendors have offered AIO only to RAW devices.
Some
vendors, like HP an IBM (pre-Dynix), have not historicaly offered
'truss'
(or 'strace', or similar) at the command online to allow users
to make
misdiagnoses such as we have seen so often with truss and libaio.
Our offering provides AIO to filesystem files via the same interface
as
for RAW, and this has proven to be a real workhorse. Since the
current
implementation must somehow branch between the file versus RAW
path,
the logic is a 'feature' because ...
if (ioctl() says it's RAW)
then do KAIO
else do LWP-based AIO
... would require an extra system call per I/O compared to the
way
it is now implemented ...
do KAIO
if (that failed)
then do LWP-based AIO
... and as it turns out, the extra kaio call for the LWP case
is a very
slight per-call overhead to the LWP-managed logic. I am sympathetic
to
the notion that 'clever' is merely 'irritating' when the documentation
is
not there. I would support a customer filing a bug report complaining
that
kaio(2) is not documented, and should be, even if only to say
that it is
not a 'supported' or 'exposed' interface.
>Much later, in the footnotes, the author acknowledges that "Certain
Oracle
>8.1 releases suppress AIO use on ordinary filesystem files ".
Suppress?
How?
The logic used was essentially "if file is not character special,
then
use pread/pwrite directly".
>And, why? Presumably, the "certain releases" referred to are
on
Solaris, and
>since there aren't that many "8.1" releases on Solaris, couldn't
a
specific
>version be cited? There appears to be a fair bit of work put
into this
>document, and this kind of sentence, which has more the feeling
of an
>unspecified assertion than a hard-won technical observation,
does not
do it
>credit.
Good comment. The constraint was removed at 8.1.7, and will
be with 9i,
I am told. 8.1.7 introduces a new init.ora parameter to allow
re-enabling
AIO to ordinary files. At the time the original copy was written,
the
8.1.7 news was not out.
>Overall, the document has a good intention, but in my humble
and
>hope-to-be-noninflammatory opinion, there is less meat on these
bones
than
>the author set out to provide.
I value all feedback (short of vulgar name-calling :-)), and
your
feedback
in particular is quite high quality.
Actually, the paper has been quite instrumental in meeting the
intended
goals of helping customers avoid common recurring pitfalls, and
in
promoting
a Best Practices mindset distinct from the wider body of knowledge
about
tuning techniques. The Blueprint is derivative of presentations
I've
given
over the last two years and whitepapers previously presented
at Sun
User's
and Performance Group (SUPerG) conferences.
>In particular, there is virtually no explicit
>evidence of the consensus approach to "Best Practices" that
he wants us
to
>redefine. Nor are there any Oracle employees cited, which --
given the
>supposedly extremely close
>coordination between Sun and Oracle -- is a disappointment.
The material has been test-flown with the collaboration of Oracle
folks
from the Oracle Centers of Excellence, and presented by invitation
at
Oracle internal symposia. Providing all the evidence of consensus
is
beyond the scope of the document, but the document does represent
the
consensus I've observed in my travels.
>Rather than a
>blueprint, the document is more like a series of cool technical
tidbits,
>flying in close formation.
Quite a valid comment. These particular tidbits seem to have
caused 80%
of
the grief we saw in 1999/2000, and much of the grief we continue
to see.
The real "blueprint" aspect here is the broad notion that common
factors
of success should be consistently applied and that common patterns
of
failure should be avoided. While this might make a paper all
by itself,
those topics have been well-covered in the literature on software
patterns
and anti-patterns ... which of course do not address the latest
news of
interest regarding Solaris technical minutae.
>On balance, I hope the author keeps this document going, and
continues
>to track and add the little tidbits of information and "how-to"
sketches
>that make it a good "version 1.0" technical note.
I would certainly like to 'keep it going', and perhaps provide
more
pointers to external knowledge collateral. I often point folks
to
the various books by Cockcroft, Alomari, and Mauro/McDougall
- with my
'breaking news' taking priority. The Blueprints program provides
a fast
time-to-market for knowledge distribution, and I hope to issue
a
revision
sometime in the months ahead. If this ever matures into a book,
"Best
Practices" will be only one chapter.
Thank you for your time and thoughtful comments. I'd be delighted
to
hear your feedback and experiences with these 'tidbits' and any
others
you think might fit the mould.
Best regards,
Bob Sneed
SMI PAE
>Ross
>
>
>
>-----Original Message-----
>Sent: Thursday, January 25, 2001 12:07 PM
>To: Multiple recipients of list ORACLE-L
>
>
>Hi Listers,
>
>Sun has just published a new Blueprint on Sun/Oracle Best Practices.
This
>is
>a technical document and covers a lot of topics I see on this
list all
the
>time. I know that several of them have been subjects of religious
wars, but
>thought people would be interested anyway. I hope this information
is
>useful.
>
>http://www.sun.com/blueprints/0101/SunOracle.html
>
>Dave Miller
>Sun Microsystems, Inc.
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: David Miller
> INET: [EMAIL PROTECTED]
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Louis Avrami
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
