Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Filesystem for Linux production database server?

RE: Filesystem for Linux production database server?

From: Craig I. Hagan <>
Date: Fri, 04 Jul 2003 16:30:42 -0700
Message-ID: <>

> As far as the max-readahead option, I don't understand the specific
> relevance to fibre-attached storage. I would imagine, though admittedly
> I no longer have large storage arrays to play with, that setting
> readahead to be higher could damage performance against arrays with
> "intelligent" caching algorithms. Having the OS handle read-ahead

this has less to do with the caching than bw utilization. (someone ought to test for async) and/or for filesystem io. Also, this is only for reads (obviously).

nutshell is that the default fs *max* readahead is the current block (4k) + 31blocks for a total of ~128k. If you mess with a lot of io to fibre arrays (through fs or raw) you'll find that 128k sized io's is right at the base of the ramp-up for efficiently using your bus bandwidth for streaming io's (e.g. range or fast full scans).

If you look at what happens, you start with current block + min-readahead blocks (default is 7) for a total of 64k. if the readahead is successful, then it doubles the number of pages read ahead for that file. repeat until you are at max-readahead.

This PITA is that you really are trading streaming io throughput for a percentage of random io with a caveat that a higher readahead change much if you don't do that much sequential io happening (e.g. an OLTP database).

> rather than the array will likely fool the array into thinking that the
> i/o patterns are more sequential than they are. This will cause them to
> pre-allocate cache regions and pre-fetch more tracks off disk, which
> could adversely impact performance.

again, this comes back to *know* your io pattern. A large db_multiblock_read setting can yield similar results if used incorrectly (the trick with fs readahead is that there is variance)

> Totally separate from that, Redhat strongly advises _against_ tuning
> that parameter.

if you are doing async io, yes. Likewise, if you know what is really going on under the hood and understand your io patterns, then it is handy to have.

> I happen to be doing I/O testing right now anyway, so maybe I'll gen up
> some workloads on different filesystems and go nuts.

whatcha got for storage and machines? [reply to me offline]

          .- ... . -.-. .-. . - -- . ... ... .- --. .

                            Craig I. Hagan

   "Never let your sense of morals prevent you from doing what is right."
                - Mayor Hardin from Isaac Asimov's Foundation

Please see the official ORACLE-L FAQ:
Author: Craig I. Hagan

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Fri Jul 04 2003 - 18:30:42 CDT

Original text of this message