| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: fastscan and maxpgio in Solaris 8?
Hi
Where can i get this Sun/Oracle Best Practices paper.
TIA Zabair Ahmed
>From: "Louis Avrami" <avramil_at_concentric.net>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: fastscan and maxpgio in Solaris 8?
>Date: Mon, 19 Feb 2001 15:45:57 -0800
>
>
>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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: zabair ahmed INET: zabaira_at_hotmail.com 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 Tue Feb 20 2001 - 03:14:43 CST
 |
 |