Measurements: (was: Raw vs. Cooked files)

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Martin Fuerderer - 28 Jun 2005 10:32 GMT

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

> 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

> 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

> 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

> the IIUG Repository, so you can repeat that test or devise your own.
>
> Art S. Kagel

sending to informix-list

Reply to this Message

david@smooth1.co.uk - 29 Jun 2005 01:31 GMT

Can we get this done with IDS 10?

> Hi,
>
[quoted text clipped - 13 lines]
> IBM Informix Development Munich, Germany
> Information Management

Reply to this Message

david@smooth1.co.uk - 29 Jun 2005 01:32 GMT

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?

> Hi,
>
[quoted text clipped - 13 lines]
> IBM Informix Development Munich, Germany
> Information Management

Reply to this Message

Martin Fuerderer - 29 Jun 2005 09:30 GMT

Hi,

maybe. :)

This work was done by zSeries people (which are in a different
department/organization from us in IBM Informix Data Management ...).
They used IDS mainly for their purpose (to show zLinux capabilities
like scaling with a real, commercially available application).
Therefore we cannot directly demand from them to do this again
with IDS 10.00.

However, there is a possibility, that for their next round of measurements
they will use IDS 10.00 (as they made good experiences with IDS 9.4).
Though in that case I would not expect results before sometime next year
...

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list@iiug.org wrote on 29.06.2005 02:31:50:

> 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

sending to informix-list

Reply to this Message

Martin Fuerderer - 29 Jun 2005 09:30 GMT

Hi,

> Why is NOAGE set to 0? Surely it should be set to 1?

For this work the machine was dedicated solely to IDS
server. No other applcations were running on the machine.
Therefore NOAGE 1 vs. 0 would not have made much of a
difference as there were no other processes to compete
with IDS for CPU-time.

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list@iiug.org wrote on 29.06.2005 02:32:39:

> Nice but....
>
[quoted text clipped - 8 lines]
> >
> > 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

sending to informix-list

Reply to this Message