Resolving The Problem

Look for the column indicating that queues are full. (“qfull” on AIX)

- Indicates how many times an i/o request was blocked because the OS queue for the disk was full
- Value represents a count since the last time iteration
- Consistently high numbers are bad
- Is an indication that there isn’t enough parallelism at the OS layer
- Might be an indication that queue depth is incorrectly set
- non IBM disk subsystems have a default value of 1
- most IBM disk subsystems have a default of 32 or are set correctly. XIV can be set to 64.
- Remember, queue_depth is at the LUN level. For parallelism it can be better to have 10 100GB LUNS rather than 1 1TB LUN.

Look at the “tps” column under xfers. This is the indicator for IOs per second (IOPS).

- Fibre Channel or SAS ~150 IOPS would be "normal"
- SATA ~90 IOPS would be "normal"
- SSD can now achieve IOPS in the thousands and be "normal"

Long averages of read/write/service times can indicate a problem. There are different opinions on what constitutes a “long service value.” Tivoli Storage Manager likes service values less than 5ms for log and DB reads/writes.

In the following example output the reads/writes were snipped. This is an example of high qfull and tps:
Disks: xfers queue
-------------- -------------------------------- --------------------------------------
%tm bps tps bread bwrtn avg min max avg avg serv
act time time time wqsz sqsz qfull
hdisk16 31.5 6.1M 566.7 3.1M 3.0M 0.7 0.0 19.1 0.0 0.0 218.4
hdisk20 31.5 6.0M 569.3 3.1M 3.0M 0.6 0.0 15.1 0.0 0.0 212.6