From Riyaj_Shamsudeen@i2.com Tue, 20 Feb 2001 07:51:37 -0800 From: Riyaj_Shamsudeen@i2.com Date: Tue, 20 Feb 2001 07:51:37 -0800 Subject: Re: fastscan and maxpgio in Solaris 8? Message-ID: MIME-Version: 1.0 Content-Type: text/plain Hi 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 Subject: Re: fastscan and maxpgio in Solaris 8? Sent by: root@fatcity. com 02/20/01 02:20 AM Please respond to ORACLE-L Hi Where can i get this Sun/Oracle Best Practices paper. TIA Zabair Ahmed >From: "Louis Avrami" >Reply-To: ORACLE-L@fatcity.com >To: Multiple recipients of list ORACLE-L >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@avaya.com ) > >------------------------------ > > From: David Miller > 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 > >X-Comment: Oracle RDBMS Community Forum > >X-Sender: "Mohan, Ross" > >From: "Mohan, Ross" > >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@oregon.West.Sun.COM > > > > > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: Louis Avrami > INET: avramil@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@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@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@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@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@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).