Re: Raw I/O vs files (was Re: Raw partitions / cooked files)

In <2506@coyote.UUCP> gainer@slowmo.almaden.ibm.com (P. Gainer) writes: >In a recent append, lparsons@exlog.com (Lee Parsons) writes... [stuff deleted] >And this is what I am curious about. What are the "small" perf gains? >Are they worth the expense of avoiding the filesystem altogether? >>I think that is because you, I and everybody else already know the >>answer. The only way your are going to see a *significantly* faster >>raw benchmark is if something else somewhere is not tuned well. >I don't necessarily think this is true. If you look at the TPC-A/B/C >benchamrks, all the leaders get their numbers using raw I/O. This implies >raw I/O can be faster when tuned. Without actually doing a huge benchmark >comparison, I would be curious to know what others have observed. >How many DBAs are running Oracle/Informix/etc etc using raw I/O? Any? With OnLine, Informix have always recommended that raw i/o should be the default choice, and that cooked i/o only be used for demo, training or development databases etc. At Pyramid, where the databases we deal with tend to be large, we tend to default to raw i/o with Oracle as well as Informix, as raw devices allow us to use our Asynchronous I/O package as a performance enhancer. Also, with Oracle Parallel Server running on a Pyramid Valence Cluster, raw devices are *required* to allow the database to be shared by multiple nodes. Certainly in a competitive benchmark, I would always use raw devices and asynchronous i/o, although I have never had the time to measure how large a gain this gives. I believe that it is very difficult to benchmark the difference, as I no of no easy way to introduce (or measure) the fragmentation which I believe would slow down the cooked devices over time in a real-world scenario. >>Before I get flamed I should say there are cases where going raw is >>the thing to do, but those cases are rare and usually in situations >>where doing the Right thing is not an option. I am not convinced by this at all. I feel that the cases where I could be persuaded to go cooked (which I think of as the Wrong thing, but maybe that's my Informix-oriented heritage) are rare (or unimportant, eg a non-production requirement). I cannot see these supposedly many advantages in going cooked, so the thought that it *might* be slower is sufficient to vote raw. graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.