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

Home -> Community -> Mailing Lists -> Oracle-L -> RE: New Sun/Oracle Blueprint available

RE: New Sun/Oracle Blueprint available

From: David Miller <djm_at_oregon.West.Sun.COM>
Date: Thu, 25 Jan 2001 17:10:01 -0600 (CST)
Message-Id: <10752.127554@fatcity.com>


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
>
>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
Received on Thu Jan 25 2001 - 17:10:01 CST

Original text of this message

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