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