Under Linux,
Raw devices should be used for Informix storage whenever possible.

The major reason for that is that Linux virtual memory
implementation is optimized for 'traditional' (like web server)
file system access, not for database servers.

The biggest problem is that Linux kernel doesn't distinguish
between physical memory pages allocated to applications and
pages allocated to the file system cache. That is, Linux doesn't give
any preference to applications.

When heavy query is running in a database server, configured
with cooked file access, the following is happening:

1. Linux is trying to keep all the data read by Informix engine
in the buffer cache;

2. Because most of these pages are marked as 'recently accessed',
Linux kernel is trying to keep them in memory;

3. Because Linux needs to place more and more pages to the
'free list' (from which physical memory pages can be allocated
to applications and to the newly arrived disk cache buffers),
instead of releasing useless 'clean' disk cache pages,
Linux kernel (in particular, 'kswapd' daemon - kernel daemon thread,
responsible for keeping the amount of 'free' memory at specific level)

swaps out physical memory pages allocated to Applications
(like Informix shared memory paged) not recently accessed by
applications.

As a result, considerable portion of Informix virtual memory pages
becomes swapped out!!!!!

This is not just a theory. This is what I've observed many times...

AFAIK many operation systems (the only exceptions I know is HPUX)
do not allow to limit the size of the file system cache. Like Linux,
they allocate memory to applications and disk buffers from a single
physical memory pool, not giving any preference to the application's
memory pages. As a result, when huge file system read/write activity
occurs, OS simply swaps out 'unnecessary' pages, not recently accessed
by the database server....

Just another hint: never run any application heavilly accessing
the large amounts of date from the local file system on the same
Linux machine where Informix engine is running!!!
Never backup Informix onto local file system under Linux!

RAW device implementation under Linux is very good.
I can just confirm, that Linux is not caching data from raw devices.



-Alexey


> -----Original Message-----
> From: owner-informix-list@iiug.org
[mailtowner-informix-list@iiug.org] On
> Behalf Of Martin Fuerderer
> Sent: Monday, January 24, 2005 7:05 AM
> To: mark@vuntec.com
> Cc: informix-list@iiug.org; owner-informix-list@iiug.org
> Subject: RE: KAIO
>
> Hi,
>
> I'm not sure. I happen to know this for Linux, but for other OSs I
don't
> really
> know. I think it is always said that on Solaris you should use raw
devices
> (rather than cooked files) for better performance, but it's been a
long
> time
> that I had a look at the difference myself. For others (e.g. AIX,
HP-UX) I
> just don't know.
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> owner-informix-list@iiug.org wrote on 22.01.2005 03:18:56:
>
> > Are there any other OS's where the FS caching mechanism is very
> > efficient and therefore should be taken advantage of when memory is
not
> > an object?
> >
> > -----Original Message-----
> > From: owner-informix-list@iiug.org
[mailtowner-informix-list@iiug.org]
> > On Behalf Of Martin Fuerderer
> > Sent: Friday, January 21, 2005 3:57 AM
> > To: Markus Bschorer
> > Cc: informix-list@iiug.org; owner-informix-list@iiug.org
> > Subject: Re: KAIO
> >
> > Hi,
> >
> > a) there's no KAIO support in 9.40.x (as others have already noted).
> > You can use raw devices, but not KAIO.
> >
> > b) KAIO will be supported with the next version. This is what the
> > Beta-Tester most probably was talking about.
> >
> > c) To judge the effect/benefit of KAIO on Linux is quite difficult
> > and depends heavily on the situation/circumstances of the
> > system:
> >
> > - if you have a lot of spare memory on your system (i.e. that
> > you do not need for BUFFERS in the server and that is not
> > used by anyone else, that Linux will use that memory for
> > file system caching. And this is known to be very effective.
> >
> > For a system like this, KAIO will not have much benefit, as
> > filesystem I/O is very efficiently done via Linux's file system
> > caching.
> >
> > - if you have a system that uses all the (physically) available
> > memory for applications (most prominently IDS), then Linux
> > will have very little memory for file system caching. That will
> > significantly slow down file system I/O.
> >
> > This is a system where KAIO will provide the most benefit,
> > and this benefit will normally be perceived as significant.
> >
> > The notion that "KAIO is a magic bullet" is to be judged on the
> > background, that the general assumption is IDS will be
> > configured to use as much memory (BUFFERS) as possible.
> > And, not to forget, on other UNIX flavours, where the file system
> > caching is not as efficient as on Linux, KAIO always had a huge
> > performance benefit.
> >
> > TIA,
> > Martin
> > --
> > Martin Fuerderer
> > IBM Informix Development Munich, Germany
> > Information Management
> >
> > owner-informix-list@iiug.org wrote on 20.01.2005 15:04:48:
> >
> > > Hi all,
> > >
> > > on some websites, you can read wonderful things concerning KAIO,
like
> > > dramatically better performance in high-traffic-scenarios.
> > > Linux Kernel 2.6 supports KAIO. I talked to a Beta-Tester of IDS
> > Version
> > 9.4
> > > UC5, which supports KAIO under Linux 2.6. He told me, that there
is no
> > > appreciable performance-benefit when using KAIO.
> > >
> > > Does anyone know, whether that's because of a bad
> > informix-implenattaion
> > of
> > > KAIO, or a of bad linux-implementation of KAIO?
> > > Is KAIO really such a magic bullet?
> > >
> > > Thanks in advance!
> > >
> > > Bye Markus
> > >
> > >
> >
> > sending to informix-list
> >
> > sending to informix-list
>
> sending to informix-list


sending to informix-list