|
Line 1 contains the total number of I/O-Requests (Start Subchannel
(SSCH) instructions) processed during the observation period, in
this example it was 56881.
Line 2 contains the number of 512B-blocks transferred during the
observation period, in this example it was 5270816 which is approximately
2.5GB.
Lines 3 and 4 contain either times (microseconds) or sizes (512-Byte
blocks), depending on the context, as explained below.
- Histogram of sizes (512B secs)
- Lines 6 and 7 indicate the distribution of the amount of data
which was transferred with the SSCHs, line 6 corresponds with
line 3 and line 7 with line 4. In this case there were, for example,
1039 SSCHs which transferred between 8 and 16 blocks of size 512B,
i.e. they transferred between 4KB and 8KB.
- Histogram of I/O times (microseconds)
- Lines 9 and 10 indicate the distribution of the total time needed
for the I/O-Requests, starting at the point where the DASD driver
accepts the request from the kernel until the DASD driver informs
the kernel about the completion of the request. Line 9 corresponds
with line 3 and line 10 with line 4. In this case there were,
for example, 109 I/O-Requests which needed between 2 milliseconds
and 4 milliseconds until completion, and 1390 I/O-Requests which
needed between 128 milliseconds and 256 milliseconds until completion.
-
- Histogram of I/O times per sector
- Lines 12 and 13 are not relevant.
-
- Histogram of I/O time till ssch
- Lines 15 and 16 indicate the distribution of the time the I/O-Request
is queued by the DASD driver. This time starts when the DASD driver
accepts the I/O-Request from the kernel and ends when the SSCH
is issued. Typically, these requests have to wait because the
particular subchannel is busy. In OS/390 terminology, this is
similar to the I/O Subsystem Queueing Time (IOSQ). Line 15 corresponds
with line 3 and line 16 with line 4. In this case there were,
for example, 11527 I/O-Requests which needed between 4 milliseconds
and 8 milliseconds until the SSCH was issued, and 118 I/O-Requests
which needed between 256 milliseconds and 512 milliseconds until
the SSCH was issued.
-
- Histogram of I/O time between ssch and irq
- Lines 18 and 19 indicate the distribution of the time between
SSCH and Channel End / Device End (CE/DE), i.e. the time needed
by the Channel Subsystem and the Storage Subsystem to process
the request. It helps to understand the performance of the Storage
Subsystem. Line 18 corresponds with line 3 and line 19 with line
4. In this case there were, for example, 23896 I/O-Requests which
needed between 1 millisecond and 2 milliseconds between SSCH and
CE/DE, and 62 I/O-Requests which needed between 64 milliseconds
and 128 milliseconds between SSCH and CE/DE.
-
- Histogram of I/O time between ssch and irq per sector
- Lines 21 and 22 are not relevant.
-
- Histogram of I/O time between irq and end
- Lines 24 and 25 indicate the distribution of the time the DASD
driver needs from accepting CE/DE until presenting the IRQ to
the kernel. In this case there were 43393 I/O-Requests which needed
between 8 microseconds and 16 microseconds between CE/DE and IRQ.
-
- # of req in chanq at enqueuing (1..32)
- Lines 27 and 28 indicate the status of the DASD driver's queues.
For each subchannel the DASD driver has a 5-deep queue, after
enqueuing an I/O-Request from the kernel the number of elements
in the respective queue is counted. In this example there were
56861 cases where the subchannel-queue was full after accepting
the I/O-Request from the kernel.
-
On a DASD request queue there is usually one request that is currently
running and up to four requests that are prepared to run. The exception
to this rule are requests in order to recover errors.
If an I/O request returns with an error condition, Linux performs
the recovery procedures which are appropriate for the device.
In the simplest case the failed request is just retried. The original
request stays in the queue and Linux creates a new recovery request
and puts it at the head of the queue. If the recovery request
fails again, Linux might create further requests and the request
queue gets even longer. If the recovery succeeds, Linux removes
the recovery requests and the original request from the queue.
Note that DASD statistics is a summary for all devices. An IOCTL
interface is available to collect the statistics for individual
devices.
|
