RE: OT: high WIO on Linux

        
           Are the depths of my I/O queues in any way "tunable" under
Linux?  (I'm pretty sure I recall tuning this under AIX...)  I would
expect that Linux will make some rather bland assumptions about the SCSI
or FC "disks" it finds in my (hypothetical) RAID-array.  Or is it smart
enough to query the device in the hope of learning the best queue depth
to use...  (I have no doubt that the SCSI standards permit such queries,
but that does not necessarily mean that the OS will bother to ask, nor
that the device will provide a "truthful" answer.)   Anyway, I would
expect a RAID-array with a few GB of NVRAM to be able to support queue
depths into the tens of thousands.  Is that irrational?

...this topic always turns into a bit of a cognitive reaction test
really. Here's the
deal. We are talking about Oracle generating this I/O demand, not a
microbenchmark. So,
if you have blisteringly fast I/O (e.g., SSD, or an oversized SAN array
cache), you will
be able to satifsy the I/O requests in sub millisecond service times.
When I/O is really 
fast for Oracle, it goes CPU bound. The only way to get Oracle to issue
more I/O in that
case is to either get a faster server, or shave off some of the code
that Oracle is
executing around the I/Os.  To summarize, a really fast I/O subsystem
makes queue depth
a bit of a non-issue. 

What about the other way around? That is, a slow I/O subsystem. What
effect does that
have on queue depth? If your downwind I/O subsystem can't drain the
I/Os, it doesn't
really help much to queue up. 

Queue-depth is tunable on Linux, but there is a balance that must be
struck between
queueing and servicing.  The bigger worry you should have is whether
your Linux
distro is taking Oracle's multiblock IOs (direct path read/write,
scattered read,
CCF,etc) and chopping them up into a bunch of little (e.g., 32KB, 64KB)
chunks
in the scsi mid-layer.


--
http://www.freelists.org/webpage/oracle-l


Other related posts: