ADSM-L

Re: AIX and async I/O--additional info

2003-04-24 16:23:52
Subject: Re: AIX and async I/O--additional info
From: Paul Ripke <stixpjr AT BIGPOND.NET DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 25 Apr 2003 06:23:16 +1000
On Friday, Apr 25, 2003, at 01:18 Australia/Sydney, PINNI, BALANAND
(SBCSI) wrote:

Direct I/O does not enhance raw I/O performance. Raw I/O performance is

I did say almost...

still slightly faster than direct I/O, but if you want the benefits of
a JFS
and enhanced performance, direct I/O is highly recommended

Which is why it's enabled by default.

Summary
Direct I/O requires substantially fewer CPU cycles than regular I/O.
I/O-intensive applications that do not get much benefit from the
caching
provided by regular I/O can enhance performance by using direct I/O.
The
benefits of direct I/O will grow in the future as increases in CPU
speeds
continue to outpace increases in memory speeds.

Exactly - raw I/O and direct I/O bypass the buffer cache, hence the
pager
thread doesn't need to spend anywhere near as much time looking for
victim
pages.

What types of programs are good candidates for direct I/O? Programs
that are
typically CPU-limited and perform lots of disk I/O. "Technical" codes
that
have large sequential I/Os are good candidates. Applications that do
numerous small I/Os will typically see less performance benefit,
because
direct I/O cannot do read ahead or write behind. Applications that have
benefited from striping are also good candidates.

I'd add: Any application which does it's own "smarter" cache management
(TSM bufferpool for DB, Oracle block cache in SGA, etc). The OS cache is
pretty much LRU, whereas most RDBMs implement LRU/MRU/??? based on
usage.

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout

<Prev in Thread] Current Thread [Next in Thread>