I''m trying to write a SLAMD (http://www.slamd.com/) resource monitor
that can be used to measure the I/O throughput on a ZFS pool, and in
particular to be able to get the read and write rates. In order to do
this, I''m basically executing "zpool iostat {interval}" and
parsing the
output to capture the values in the "bandwidth read" and
"bandwidth
write" columns. I have other resource monitors that are able to capture
things like CPU utilization and network traffic, as well as one to
measure disk utilization using the standard iostat. These are all
useful to capture information about the state of a system while running
performance tests.
However, I''m running into a problem getting this information from ZFS
because it appears that the output of "zpool iostat" gets buffered
somewhere if standard output doesn''t go to a TTY. For example, when I
run:
zpool iostat 1
from the command line, I see output every second as I would expect.
However, if I run:
zpool iostat 1 | cat
then I see nothing for about 30 seconds and then all the data captured
during that period gets dumped to the screen and I have to wait for
another 30 seconds to see the next chunk. Compare this with:
vmstat 1 | cat
or
iostat -x -n 1 | cat
which still update their output every second even though it is being
redirected. My guess is that the reason that it works for them is that
they call fflush after each update whereas zpool iostat does not. Would
it be possible to add the fflush to zpool iostat as well?
Also, on a somewhat unrelated RFE, would it be possible to have an
option that makes it possible to skip the first set of output that shows
the average since system boot? Most of the time that I run commands
like this I''m primarily interested in what the system is doing right
now
and don''t really care what the historical average is. When
I''m looking
at the output, then it''s fine because I can just ignore it, but if
I''m
trying to capture and parse it, then I have to write code to skip over
it.
Neil
Neil A. Wilson wrote:>However, I''m running into a problem getting this information from ZFS >because it appears that the output of "zpool iostat" gets buffered >somewhere if standard output doesn''t go to a TTY. > > >Also, on a somewhat unrelated RFE, would it be possible to have an >option that makes it possible to skip the first set of output that shows >the average since system boot? > >We do a similar thing (capturing/parsing iostat output) in the application I work on, so this would be nice for us too. In fact, I''d like to go further and request an option to zpool iostat which gave you output intended solely for machine-readability - flushed every line, no historic first sample, written in something like CSV format so it''s easy to parse, always in the same units, and ideally timestamped. Something like: time,pool,capacity-used,capacity-avail,read-ops,write-ops,read-band,write-band 10:26:00,export,9290,8370,0,2,0,18.5 10:26:01,export,9290,8362,0,1,0,8 Of course, if no-one''s interested, we can do this ourselves from the source - assuming the interfaces in libzfs will be public/stable? -- Phil
On Thu, Dec 22, 2005 at 10:30:05AM +0000, Philip Beevers wrote:> Neil A. Wilson wrote: > > >However, I''m running into a problem getting this information from ZFS > >because it appears that the output of "zpool iostat" gets buffered > >somewhere if standard output doesn''t go to a TTY. > > > > > >Also, on a somewhat unrelated RFE, would it be possible to have an > >option that makes it possible to skip the first set of output that shows > >the average since system boot? > > > > > We do a similar thing (capturing/parsing iostat output) in the > application I work on, so this would be nice for us too.Yes, flushing output seems entirely reasonable. I will file an RFE.> In fact, I''d like to go further and request an option to zpool iostat > which gave you output intended solely for machine-readability - flushed > every line, no historic first sample, written in something like CSV > format so it''s easy to parse, always in the same units, and ideally > timestamped. Something like: > > time,pool,capacity-used,capacity-avail,read-ops,write-ops,read-band,write-band > 10:26:00,export,9290,8370,0,2,0,18.5 > 10:26:01,export,9290,8362,0,1,0,8This is a little less likely to happen any time soon. Your best bet is to build on the libzfs interfaces, assuming you''re OK using a private interface. We have no plans to make these interfaces public at the moment, but that''s not to say it won''t be done. We may also consider the libdtrace route and make the library private but the JNI public (which should be happening soon). - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock