In the last episode (Feb 04), Poul-Henning Kamp said:
> Collecting number of operations and number of errors is a nobrainer.
>
> The timestamps cost something to make, and my plan was to only
> collect them while a monitoring program is running. (Is this a good
> idea ?)
>
> In difference from the devstat framework which measures how big a
> percentage of the time a drive has one or more outstanding requests,
> I think that measuring the responstime is a much more useful metric.
> (comments, input, references welcome)
Can we do both? :) %busy is a nice value if only because it's a nice
value to put on a status meter. If you're already timing each
transaction it won't cost much.
According to the devstat source, timestamping is cheap relative to
actually doing math on the values (end_transaction always gets the
time, but only uses the value when busy_count goes from >0 to 0). Is
this right?
> I pressume we also want to collect number of bytes transferred, and
> I will add that in the next iteration.
Definitely. What I'd like is enough statistics to be able to duplicate
Solaris' iostat -x output:
extended device statistics
device r/s w/s kr/s kw/s wait actv svc_t %w %b
r/s, kr/s reads/sec and Kbytes/sec
wait = average number of transactions waiting for service
actv = average number of transactions actively being serviced
svc_t = average time per I/O
%w = percent time there are transactions waiting for service
%b = percent of time the disk is busy
wait and %w may zero on FreeBSD. Do we allow queuing more transactions
than the physical device supports?
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
