Re: fastscan and maxpgio in Solaris 8?

From: <Riyaj_Shamsudeen_at_i2.com>
Date: Tue, 20 Feb 2001 07:51:37 -0800
Message-ID: <F001.002B8A09.20010220070027@fatcity.com>

Here is the url:
http://www.sun.com/software/solutions/blueprints/0101/SunOracle.pdf

kaio returning ENOSETUP is okay ? That really a surprise and going against few documents. If I understand correctly, kaio does not support I/O buffer size greater then maxphys or vol_maxio kernel parameters. If the I/O buffer size is greater than these values then kaio call returns ENOSETUP (errno=28). IO buffer size for the db writes is the product of db_file_direct_io_count * db_block_size post-oracle8. The default value for maxphys and vol_maxio is 128k. The default value for db_file_direct_io_count is 64 and ONLY for 2k db_block_size the kaio calls should work correctly (out of the box ) [ some task for me to test this out]. Hence if you want to make kaio calls work correctly, then you have to either decrease the db_file_direct_io_count or increase the maxphys and vol_maxio parameter to match this product OR disable the async IO completely.

BTW, in my opinion, the overhead of lwp based IO calls are very high. I created one tablespace of size 100M in my database to prove this. With Asynch_IO turned on (that is with lwp processes since we haven't set up these parameters yet due to other nontechnical reasons..), the tablespace creation took 9 seconds and with asynch_io turned off it took less than 1 second.

Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA
i2 technologies www.i2.com

                                                                                       
                       
                    "zabair                                                            
                       
                    ahmed"               To:     Multiple recipients of list ORACLE-L 
<ORACLE-L_at_fatcity.com>  
                    <zabaira_at_hotm        cc:                                           
                       
                    ail.com>             Subject:     Re: fastscan and maxpgio in 
Solaris 8?                  
                    Sent by:                                                           
                       
                    root_at_fatcity.                                                      
                       
                    com                                                                
                       
                                                                                       
                       
                                                                                       
                       
                    02/20/01                                                           
                       
                    02:20 AM                                                           
                       
                    Please                                                             
                       
                    respond to                                                         
                       
                    ORACLE-L

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).

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

--
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).




-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Riyaj_Shamsudeen_at_i2.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 - 09:51:37 CST