On 10/10/2014 12:35 PM, Nathan Scott wrote:
[ ... ]
$ iostat -t -x 2 10 > iostat.10
$ iostat2pcp iostat.10 iostat.pcp
[26] Time: 03:49:59 PM
Device: number of values? expected 12, found 3
It looks like iostat2pcp doesn't understand this timestamp format,
and the parser is attempting to treat the line "Time: 03:49:59 PM"
as a set of device values. Is LC_TIME set in the environment when
iostat is being run?
no. it fails on f19 too, with iostat v10, which is probably
the same version Bud is running.
And which version of iostat being used? (rhel5 in output - is it
an old version?) I think we can attempt to cater for this output
form, but it's worth reading the iostat2pcp(1) man page, from the
section starting:
"The best results are obtained when iostat(1) was run with [...]"
# S_TIME_FORMAT=ISO iostat -t -x 2 10 > iostat.out
this gives more parseable timestamps, e.g. "2014-10-10T14:28:15+1100"
and we get past the timestamp problem, but then hit the next problem :
# iostat2pcp iostat.out iostat.pcp
[20] sda 0.00 0.00 0.50 0.00 2.00 0.00 8.00
0.04 87.00 87.00 0.00 87.00 4.35
Device: number of values? expected 12, found 14
version 10 and later iostat -x has await split into await, r_await
and w_await, e.g.
2014-10-10T14:28:17+1100
avg-cpu: %user %nice %system %iowait %steal %idle
15.51 0.00 1.45 1.18 0.00 81.87
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz
avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.50 0.00 2.00 0.00 8.00
0.04 87.00 87.00 0.00 87.00 4.35
Once you get past that the resulting pcp archive also needs to
include disk.dev.read_rawactive and disk.dev.write_rawactive
so pmiostat can replay it, which is what I suspect Bud was going
to try next ... I'll try and find some time over the w/e to fix it.
Regards
- Mark
|