Measurements: (was: Raw vs. Cooked files)

Hi, if you are interested : http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf (There's a part where they tested raw devices vs. file system files as well. These measurements were all done on zSeries, not by myself as I did not get to do such extensive work. But this document is really extensive ...) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 19.05.2005 16:43:23: > Martin Fuerderer wrote: > > Hi, > > I emailed a simple response yesterday, but the link seems to be lost. > Here's another more detailed one: > > It does not matter HOW much memory the OS has for a buffer cache. There are > still several reasons why RAW will ALWAYS be faster than COOKED devices or > OS filesystem files: > > 1) If the OS cache is too small bulk server IO like checkpoints and peak > load LRU flushing will thrash the cache killing OS and server performance. > - Thanks for pointing that out Jake. > > 2) All IO to a COOKED device or FS file MUST first be copied from the IDS > buffers to the OS buffers before the actual IO operation. This MUST be > extra overhead not needed on a RAW device - by definition! > > 3) If you are writing to an FS file chunk instead of a COOKED device you > have the additional overhead of the filesystem and directory and inode > maintenance. While so called 'fast filesystems' reduce these particular > overhead items they can do nothing to eliminate it or to eliminate the > effects of #2! > > 4) The cache buys you nothing for writing because IDS correctly opens all > COOKED chunks in O_SYNC mode which means that the buffer is immediately > flushed to disk as soon as it is copied from the IDS buffer and IDS still > has to wait for this write to complete as it does for RAW. However, for RAW > IDS does not have to wait for the second buffer copy. > > 5) On the read side, it's counterintuitive, but, there is little gained from > the OS cache. Why? Reasons: > - Everything that IDS needs is already in its own cache and also in the > SAN cache and also on the disk drives' caches! You're just adding one more > redundant cache! > - Each block read has to be copied first to the OS buffer cache before > it can be handed to IDS if it's not already in OS cache. Raw doesn't have > this overhead. > - Because IDS's cache management is RDBMS behavior specific, chances > are if a page is in the OS cache, then it's already in the IDS cache and > will never be read from OS cache again. Is this redundant to the first > point? Maybe but so is the OS cache ;-) [OK cheap shot. Back to serious > points...] > > 6) Filesystem file chunks will be fragmented on disk and not contiguous like > COOKED device chunks and RAW chunks. Some filesystems are better than > others at reducing file fragmentation, but none are perfect. > > You state that on Linux with lots of cache you find AIO to FS files will > outperform KAIO on RAW device. Prove it Martin. I posted my test results, > post yours (and don't forget to post O_SYNC #'s if you are using a direct to > disk test as I did rather than a DB timing -- admittedly difficult to time > accurately which is why I use a direct-to-disk test). My test was performed > using my ul.ec utility to read a large IDS table writting to disk files, raw > and cooked devices using the identical query with and without the -U flag to > enable/disable O_SYNC IO (with -U is how IDS does it, but I was curious what > the real cost of that O_SYNC setting was). A pre-test run of ul.ec with the > same query primed the cache of whatever records would be likely to remain > after a completed run. The source for ul.ec is in my utils2_ak package in > the IIUG Repository, so you can repeat that test or devise your own. > > Art S. Kagel sending to informix-list

Can we get this done with IDS 10? Martin Fuerderer wrote: > Hi, > > if you are interested : > > http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf > > (There's a part where they tested raw devices vs. file system files as > well. > These measurements were all done on zSeries, not by myself as I did not > get to do such extensive work. But this document is really extensive ...) > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management >

Nice but.... Can we get this done with IDS 10? Set RESIDENT to -1 to make everything resident. Why is NOAGE set to 0? Surely it should be set to 1? Martin Fuerderer wrote: > Hi, > > if you are interested : > > http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf > > (There's a part where they tested raw devices vs. file system files as > well. > These measurements were all done on zSeries, not by myself as I did not > get to do such extensive work. But this document is really extensive ...) > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management >