Monitoring with iostat

[mikiteleco]

Hi,
I have this output in Linux using iostat:

root@machine # iostat -xN 1 4 | grep ^[a-zA-Z]
Linux 2.6.32-358.2.1.el6.x86_64 (machine) 06/18/2018 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.23 13.05 2.25 1.39 119.74 115.26 64.48 0.08 22.02 1.13 55.82 0.88 0.32

I want to get r_await and w_await in FreeBSD, which definitions are:

• r_await: The average time (in milliseconds) for read requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
• w_await: The average time (in milliseconds) for write requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them

Is this possible? I'm trying iostat -xI and iostat -xIo but searching for value definitions in documentation I don't see the answer.

Thanks beforehand,
Mike.

 

[sko]

The tsvc_t/i value should come closest to what you are looking for. Also check the systat(1) tool if it may help your case.
However, when diagnosing disk I/O problems on FreeBSD I've always reverted to DTrace(1).

In /usr/share/dtrace/ you can find the disklatency and disklatencycmd scripts. IIRC they are included in the base system.
The dtrace-toolkit package contains lots of scripts for various tasks and also for Disk-based IO:

% ls -1 /usr/local/share/dtrace-toolkit/Disk/
bitesize.d
diskhits
hotspot.d
iofile.d
iofileb.d
iopending
Readme
seeksize.d

The iopending script might be the most interesting one for you.
DTrace syntax can be easily picked up by reading the scripts if you know some basic awk and C, at least to modify or salvage these existing scripts to get the informations you need.

 

[Bobi B.]

How about running gstat(8) for awhile (gstat -p)? High %busy or L(q) usually means you've more load than I/O system can handle.

PS: top -mio -ototal -SH will point you to programs making most I/O load.