Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> fastscan and maxpgio in Solaris 8?

fastscan and maxpgio in Solaris 8?

From: Louis Avrami <avramil_at_concentric.net>
Date: Mon, 19 Feb 2001 16:20:41 -0800
Message-ID: <F001.002B845E.20010219154557@fatcity.com>

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 ( avrami_at_avaya.com )


 From: David Miller <djm_at_oregon.West.Sun.COM>  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 <ORACLE-L_at_fatcity.com>
>X-Comment: Oracle RDBMS Community Forum
>X-Sender: "Mohan, Ross" <MohanR_at_STARS-SMI.com>
>From: "Mohan, Ross" <MohanR_at_STARS-SMI.com>
>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: djm_at_oregon.West.Sun.COM
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Louis Avrami
  INET: avramil_at_concentric.net

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: ListGuru_at_fatcity.com (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).
Received on Mon Feb 19 2001 - 18:20:41 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US