Fwd: IDS i/o and Solaris

No, DIRECT_IO is SPECIFICALLY NOT a mount option for many reasons (see the discussion groups from last year on the subject in various Linux lists) it is an open() system call mode (O_DIRECT) effective when opening the file just like O_SYNC but lower overhead and MUCH faster. FYI, while Linus T. allowed O_DIRECT into the 2.4 kernel so he could deprecate RAW eventually, he seems to also want to deprecate O_DIRECT. He feels ALL applications, even databases like IDS that need to manage their own buffer cache, should go through the Linux buffers and use the Linux madvise() or POSIX posix_fadvise() functions to mark a cache page that's no longer needed and manage the OS cache that way. He said: The whole notion of "direct IO" is totally braindamaged<SIC>. Just say no. This is your brain: O This is your brain on O_DIRECT: . Any questions? I should have fought back harder. There really is no valid reason for EVER using O_DIRECT. You need a buffer whatever IO you do, and it might as well be the page cache. There are better ways to control the page cache than play games and think that a page cache isn't necessary. So don't use O_DIRECT. Use things like madvise() and posix_fadvise() instead. Linus AND: *From: Linus Torvalds* [email blocked] Subject: Re: O_DIRECT question Date: Wed, 10 Jan 2007 19:15:48 -0800 (PST) On Wed, 10 Jan 2007, Linus Torvalds wrote: > > So don't use O_DIRECT. Use things like madvise() and posix_fadvise() > instead. Side note: the only reason O_DIRECT exists is because database people are too used to it, because other OS's haven't had enough taste to tell them to do it right, so they've historically hacked their OS to get out of the He is stuck in filesystem and whole file IO and has no understanding of the realities of the database world! <SIGH!> Art On Wed, Nov 5, 2008 at 2:56 PM, Frank Langelage <frank@lafr.de> wrote: > Neil Truby wrote: > > IDS 10.0FC8W2 on Solaris 10. > > > > We're just migrating to a new server from IDS 10.0FC8W2 on Solaris 9. > > > > The customer's SysAdmin has seen great results on Oracle using Solaris > > 10 Direct i/o onto file system containers (ie cooked files), and really > > wants to try same on the Informix database. > > > > Any reason not to give it a try? > > Not having dedicated filesystems for the informix datafiles would be a > reason against that. > Direct IO is a mount option for the whole filesystem, so all I/O to > files on this filesystem bypass the buffer chache of the OS. > No problem for the informix data as there is the cache of IDS, but other > file IO will suffer. > But why not use raw devices? > From our experience this will give the best performance. > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Hello Neil, Frank and Art have their valid points and I am always greatful for their help. So I hope that I don't offend when I say that I think direct I/O (DIO) could be faster and is worth a test. To be honest, DIO has its pluses and minuses. An old fashioned cooked filesystem (without DIO) puts disk reads into memory twice. That is because Informix cooked reads actually make their requests to the operating system. Then the operating system tries to keep all "its" disk reads in its I/O memory and then Informix does too (called BUFFERS). Kinda wasteful. The good news is that if the operating system I/O memory is bigger than BUFFERS, you will actually have more memory reads than you think you have in Informix. So therefore I still think that it is worth testing both DIO and "no DIO". Whichever is faster wins! One final note. Ideally you and your system administrator should tune together. -L.S.

"LIGHT SCANS" <light_scans@yahoo.com> wrote in message news:858b0793-7a03-4404-a82b-8bbc03e8c604@n33g2000pri.googlegroups.com... > Hello Neil, > > Frank and Art have their valid points and I am always greatful for > their help. So I hope that I don't offend when I say that I think > direct I/O (DIO) could be faster and is worth a test. To be honest, > DIO has its pluses and minuses. An old fashioned cooked filesystem > (without DIO) puts disk reads into memory twice. That is because > Informix cooked reads actually make their requests to the operating > system. Then the operating system tries to keep all "its" disk reads > in its I/O memory and then Informix does too (called BUFFERS). Kinda > wasteful. The good news is that if the operating system I/O memory is > bigger than BUFFERS, you will actually have more memory reads than you > think you have in Informix. So therefore I still think that it is > worth testing both DIO and "no DIO". Whichever is faster wins! Thanks LS, Art and Frank.. Well, I plan to populate this new server via a redircted restore, so that's a pretty good i/o test. I'll try both and let you know what we find.

Art Kagel wrote: > FYI, while Linus T. allowed O_DIRECT into the 2.4 kernel so he could > deprecate RAW eventually, he seems to also want to deprecate O_DIRECT. > He feels ALL applications, even databases like IDS that need to manage > their own buffer cache, should go through the Linux buffers and use the > Linux madvise() or POSIX posix_fadvise() functions to mark a cache page > that's no longer needed and manage the OS cache that way. He said: > >> The whole notion of "direct IO" is totally braindamaged<SIC>. Just say no. >> >> This is your brain: O >> This is your brain on O_DIRECT: . >> >> Any questions? >> I should have fought back harder. There really is no valid reason for EVER >> using O_DIRECT. You need a buffer whatever IO you do, and it might as well >> be the page cache. There are better ways to control the page cache than >> play games and think that a page cache isn't necessary. >> >> So don't use O_DIRECT. Use things like madvise() and posix_fadvise() >> instead. >> >> Linus > > AND: > >> >> So don't use O_DIRECT. Use things like madvise() and posix_fadvise() >> instead. >> >> Side note: the only reason O_DIRECT exists is because database people are >> too used to it, because other OS's haven't had enough taste to tell them > > to do it right, so they've historically hacked their OS to get out of the > > > He is stuck in filesystem and whole file IO and has no understanding of > the realities of the database world! <SIGH!> > > Art I agree with your comment. It calls into question the future of Linux as a platform for serious databases. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

On Nov 6, 8:48 am, Ian Goddard <godda...@hotmail.co.uk> wrote: > Art Kagel wrote: > > He is stuck in filesystem and whole file IO and has no understanding of > > the realities of the database world!  <SIGH!> > > > Art > > I agree with your comment.  It calls into question the future of Linux > as a platform for serious databases. > > -- > Ian Absolutely not! Take the comments made by Linus with a grain of salt. There are still several things that discount the issues that could be raised... First there's this guy named Moore who created this funny thing called "Moore's Law" that computing power will double every 18 months. So far, in the last 20+ years, his law has held true. Add to this ... HP's new research in their "memresistor" not sure what they are calling it. Its in fact potentially a new fast non-volitile memory that could replace the hard drive as we know it. Not to mention that there's a paradigm shift in application designs (cloud) that reduce the reliance on pulling data from disk in real time. And of course the bigger issue. What sort of applications are put on Linux machines as database servers? They are for their most part not apps that require fast I/O performance. You can take a hit on the OS I/ O but make up for it using technologies like SAS or U320 SCSI over SATA drives. (Add in the fiber channels etc ...) The point is that as machine performances increase, you can afford to lose some efficiencies elsewhere. If you're going to go out and build lighting fast machines for RDBMS servers, then you're not going to start with a Linux box. Try IBM or Sun servers. But what percentage of people are building these types of boxes? There's more to the reasons why database vendors don't want direct i/o to go away, but my point is that its a moot argument for not choosing an OS and hardware platform.

Ian Michael Gumby wrote: > On Nov 6, 8:48 am, Ian Goddard <godda...@hotmail.co.uk> wrote: > >> Art Kagel wrote: >> > > >>> He is stuck in filesystem and whole file IO and has no understanding of >>> the realities of the database world! <SIGH!> >>> >>> Art >>> >> I agree with your comment. It calls into question the future of Linux >> as a platform for serious databases. >> >> -- >> Ian >> > > Absolutely not! > Take the comments made by Linus with a grain of salt. There are still > several things that discount the issues that could be raised... > OK > First there's this guy named Moore who created this funny thing called > "Moore's Law" that computing power will double every 18 months. So > far, in the last 20+ years, his law has held true. > > But - I want ALL of that performance increase. > Add to this ... HP's new research in their "memresistor" not sure what > they are calling it. Its in fact potentially a new fast non-volitile > memory that could replace the hard drive as we know it. Not to mention > that there's a paradigm shift in application designs (cloud) that > reduce the reliance on pulling data from disk in real time. > I couldn't agree with you less - most commercial entities like their confidential data where they can see it. > And of course the bigger issue. What sort of applications are put on > Linux machines as database servers? They are for their most part not > apps that require fast I/O performance. You can take a hit on the OS I/ > O but make up for it using technologies like SAS or U320 SCSI over > SATA drives. (Add in the fiber channels etc ...) > So what - I paid for this x.y.z.a.b.c gizzmo but I can't get the best out of it because why? Because Linus bloody somebody says so. Oh - right - thanks. -- Clive

On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: > > First there's this guy named Moore who created this funny thing called > > "Moore's Law" that computing power will double every 18 months. So > > far, in the last 20+ years, his law has held true. > > But - I want ALL of that performance increase. Really? So you still code 100% of your stuff in C? The point is that none of the systems are as efficient as they could be. The cost in upfront software development needed to squeeze those extra cycles is more than the cost of just upgrading the hardware. Microsoft, the king of bloatware is re-marketing/re-releasing Vista. Why? because the current/new desktops being sold have enough cpu/ memory horsepower to run their OS and look halfway decent. >> Add to this ... HP's new research in their "memresistor" not sure what > > they are calling it. Its in fact potentially a new fast non-volitile > > memory that could replace the hard drive as we know it. Not to mention > > that there's a paradigm shift in application designs (cloud) that > > reduce the reliance on pulling data from disk in real time. > > I couldn't agree with you less - most commercial entities like their > confidential data where they can see it. Huh? Maybe you're misinterpreting my "cloud" comment. I'm not talking about putting one's corporate data in the "Cloud" as in Amazon's product offering but as in "cloud computing" where the objects persist in memory and are cached to disk behind the scenes. This way your applications always get the data from memory and not hitting disk. Yeah this means that you need a lot of memory and interconnected machines. This is why you're seeing "in memory" databases as a "front end" to relational database systems. This is what large "commercial" entities are paying the big bucks for, when they want/need speed. And that gets to the true point. When are we "fast enough"? Wal*Mart pushes out a bunch of store POS/Inventory systems to each store. Do these systems need to be quad core cpu, with 32GB of memory and hot swap SAS drives to do their job? Somehow I don't think so. They could easily run on a Linux box, with *cooked* disk chunks and still do their job without an issue. >> And of course the bigger issue. What sort of applications are put on > > Linux machines as database servers? They are for their most part not > > apps that require fast I/O performance. You can take a hit on the OS I/ > > O but make up for it using technologies like SAS or U320 SCSI over > > SATA drives. (Add in the fiber channels etc ...) > > So what - I paid for this x.y.z.a.b.c gizzmo but I can't get the best > out of it because why? > Because Linus bloody somebody says so. > Oh - right - thanks. > That's like saying "Gee I've spent over $1.0 Million USD for a Bugatti Veyron, but the darn government won't allow me to open it up on the road... thanks". So if the fastest you can legally drive in the US is 70 mph on certain roads, why would you want to spend that sort of money for a car that can cruise at speeds over 150 mph? I think you're being a tad unrealistic .

Ian Michael Gumby wrote: > On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: > > >>> First there's this guy named Moore who created this funny thing called >>> "Moore's Law" that computing power will double every 18 months. So >>> far, in the last 20+ years, his law has held true. >> But - I want ALL of that performance increase. > Really? > So you still code 100% of your stuff in C? Assembler. C is for pussies. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com

Ian Michael Gumby wrote: > On Nov 6, 8:48 am, Ian Goddard <godda...@hotmail.co.uk> wrote: >> Art Kagel wrote: > >>> He is stuck in filesystem and whole file IO and has no understanding of >>> the realities of the database world! <SIGH!> >>> Art >> I agree with your comment. It calls into question the future of Linux >> as a platform for serious databases. >> >> -- >> Ian > > Absolutely not! > > Take the comments made by Linus with a grain of salt. There are still > several things that discount the issues that could be raised... > > First there's this guy named Moore who created this funny thing called > "Moore's Law" that computing power will double every 18 months. So > far, in the last 20+ years, his law has held true. > > Add to this ... HP's new research in their "memresistor" not sure what > they are calling it. Its in fact potentially a new fast non-volitile > memory that could replace the hard drive as we know it. Not to mention > that there's a paradigm shift in application designs (cloud) that > reduce the reliance on pulling data from disk in real time. > > And of course the bigger issue. What sort of applications are put on > Linux machines as database servers? They are for their most part not > apps that require fast I/O performance. You can take a hit on the OS I/ > O but make up for it using technologies like SAS or U320 SCSI over > SATA drives. (Add in the fiber channels etc ...) > > The point is that as machine performances increase, you can afford to > lose some efficiencies elsewhere. If you're going to go out and build > lighting fast machines for RDBMS servers, then you're not going to > start with a Linux box. Try IBM or Sun servers. But what percentage of > people are building these types of boxes? > > There's more to the reasons why database vendors don't want direct i/o > to go away, but my point is that its a moot argument for not choosing > an OS and hardware platform. > You're missing the point. If stuff doesn't get written to disk in the sequence in which the RDBMS programmer intended because the OS cache designer tried to double-guess what was needed the system's ability to survive a crash with the database's ACID properties intact is greatly diminished. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

Obnoxio The Clown wrote: > Ian Michael Gumby wrote: >> On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: >> >> >>>> First there's this guy named Moore who created this funny thing called >>>> "Moore's Law" that computing power will double every 18 months. So >>>> far, in the last 20+ years, his law has held true. >>> But - I want ALL of that performance increase. >> Really? >> So you still code 100% of your stuff in C? > > Assembler. > > C is for pussies. > P is for pussies. C is for the other word :O

TBP wrote: > Obnoxio The Clown wrote: >> Ian Michael Gumby wrote: >>> On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: >>> >>> >>>>> First there's this guy named Moore who created this funny thing called >>>>> "Moore's Law" that computing power will double every 18 months. So >>>>> far, in the last 20+ years, his law has held true. >>>> But - I want ALL of that performance increase. >>> Really? >>> So you still code 100% of your stuff in C? >> Assembler. >> >> C is for pussies. >> > P is for pussies. > > C is for the other word :O Clive? :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com

Obnoxio The Clown wrote: > TBP wrote: >> Obnoxio The Clown wrote: >>> Ian Michael Gumby wrote: >>>> On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: >>>> >>>> >>>>>> First there's this guy named Moore who created this funny thing >>>>>> called >>>>>> "Moore's Law" that computing power will double every 18 months. So >>>>>> far, in the last 20+ years, his law has held true. >>>>> But - I want ALL of that performance increase. >>>> Really? >>>> So you still code 100% of your stuff in C? >>> Assembler. >>> >>> C is for pussies. >>> >> P is for pussies. >> >> C is for the other word :O > > Clive? :o) Clown! -- Daniel A. Morgan

DA Morgan wrote: > Obnoxio The Clown wrote: >> TBP wrote: >>> Obnoxio The Clown wrote: >>>> Ian Michael Gumby wrote: >>>>> On Nov 6, 10:46 am, Clive Eisen <cl...@serendipita.com> wrote: >>>>> >>>>> >>>>>>> First there's this guy named Moore who created this funny thing >>>>>>> called >>>>>>> "Moore's Law" that computing power will double every 18 months. So >>>>>>> far, in the last 20+ years, his law has held true. >>>>>> But - I want ALL of that performance increase. >>>>> Really? >>>>> So you still code 100% of your stuff in C? >>>> Assembler. >>>> >>>> C is for pussies. >>>> >>> P is for pussies. >>> >>> C is for the other word :O >> Clive? :o) > > Clown! OK, I'll give you that one. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com