| Age | Commit message (Collapse) | Author |
|---|
|
It now keeps track of I/O activity on a per-device basis (as well as a
cumulative system-wide view). ``I/O activity'' is defined as defined as
the time during which the device driver and device are activelty working
on at least one I/O. Here's a sample output:
==================== I/O Active Period Information ====================
DEV | # Live Avg. Act Avg. !Act % Live
---------- | ---------- ------------- ------------- ------
(254, 0) | 0 0.000000000 0.000000000 0.00
( 8, 17) | 0 0.000000000 0.000000000 0.00
( 8, 16) | 29 0.909596815 0.094646263 90.87
( 8, 33) | 0 0.000000000 0.000000000 0.00
( 8, 32) | 168 0.097848226 0.068231948 59.06
---------- | ---------- ------------- ------------- ------
Total Sys | 33 0.799808811 0.082334758 90.92
Also added a new btt -Z option that generates per-device and system-wide
I/O activity data that can be plotted.
Refer to the documentation updates (btt.1, btt.tex) for more information.
|
|
Create an overall system and per-device statistics file containing
MB-per-second and I/Os-per-second values. Format for each file is first
column contains an (integer) time stamp (seconds since start of run)
and a (double) value.
File names are:
sys_mbps_fp.dat - system-wide mbps (for all devices watched, of course)
sys_iops_fp.dat - I/Os per sec
Each device watched will have a file with the device preceeding the
_mbps or _iops section of the above file names.
|
|
Easy parsing for graph creation
|
|
|
|
This will output a data file containing the time stamp and number of
I/Os issued to underlying drivers per device. It will give you an idea
as to how many I/Os are being actively worked per device at any time
during the run.
|
|
Including Q2Q, Q2G, S2G, G2I, Q2M, I2D, M2D, D2C, Q2C.
S2G is part of Q2G, and shows the number of times we had to sleep to
get a request.
Ignored 0-byte I/Os - coming from barrier I/Os...
|
|
o Using valgrind, determined we had Q IOPs left over that weren't
used. Added "all" list, and then deleted these at end.
o Removed old debug stuff (COUNT_IOS, DEBUG, ...)
o Fixed a bunch of white space at end of lines.
Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
|
|
Also separated out DM-device calculations.
|
|
After a lot of fighting with maintaining a tree-styled design (each trace
having it's own node), it was just getting too cumbersome to work in all
circumstances. Taking a clue from blkparse itself, I decided to just keep
track of IOs at queue time, and updating fields based upon later traces.
The attached (large) patch works much faster, handles larger test cases
with less failures, and is managing some pretty large jobs I'm working on
(large Oracle-based DB analysis - 32-way box w/ lots of storage).
I've also added a Q2Q seek distance feature - it's come in handy when
comparing results of IO scheduler choice: We can see what the incoming IO
seek distances are (at queue time), and then see how the scheduler itself
manages things (via merges & sorting) by looking at D2D seek distances
generated.
As noted in the subject, I arbitrarily bumped this to version 2.00 as the
innards are so different. The documentation (btt/doc/btt.tex) has been
updated to reflect some minor output changes. I also fixed a bug dealing
with process name notification: there was a problem that if a new PID came
up with a name that was previously seen, btt wouldn't keep track of it
right. [When running with Oracle, a lot of processes have the same name but
different PIDs of course.]
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
amounts of memory to accomplish a run. After looking at the code, and
doing some testing, I determined the cause - please find a patch to the
latest tree that seems to fix the problem for me...
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
I guess majors 253 and 254 are both right.
Fixed typo in bilink_first_up.
I'm seeing stuff like:
253,0 0 13 30.716486276 31815 Q R 0 + 8 [mount]
253,0 0 14 30.718087082 3 C R 0 + 8 [0]
Without any intervening stuff (remaps and gets and inserts and ...). So
added some support for this case.
(Note: This requires the kernel patch I submitted on 2007/02/15 to make
any sense, although this code will "work" in any event.)
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
From: Alan D. Brunelle <Alan.Brunelle@hp.com>
Lots of changes to how we handle traces - adds robustness & quicker
This large patch contains the following changes to the trace handling
aspects of btt:
1. Use larger buffers for output options.
2. Use mmap to handle the input of trace data.
3. More precise btt statistics are output at the end.
4. Added in (under DEBUG) the display of unhandled traces. I was running
into the problem where traces were not being connected, and the rb trees
would get quite large. This would slow things down considerably. (See
below for details on why traces weren't being handled.)
5. Sprinkled some ASSERTs (under DEBUG).
6. Added a new btt-specific trace type: "links" - since 'A' (remaps)
contain two separate pieces of information, I broke them up into a link
and a remap trace. [Thus, it is easy to find either end of the remap.]
7. Added in the notion of retries of completes (and requeues). I'm finding
some discrepencies in the time stamps, in order to make btt handle these
better, I've added the notion of keeping the trace around for a bit,
to see if it gets linked up later.
8. Separated trace streams into: simple IOs, and remapped IOs.
9. Fixed up D2C averages - Q2I + I2D + D2C should equal Q2C averages.
----------------------------------------------------------------------------
I do not understand why it is so, but I am seeing two 'C' (complete)
traces for the same IO track at times. The sequence number is different
(+1 for the second one), and the time stamps are different (100's of
microseconds apart). I'm investigating this.
At least on an IA64, I am seeing time inconsistencies amongst CPUs on very
heavy loads (48 disks, 4 CPUs, almost 300 million traces). I find the 'D'
(issue) and 'C' (complete) traces coming out ahead of the associate 'I'
(insert) and 'M' (merge) traces. It would be good to get this fixed in
the kernel, but I figure it is also goodness to attempt to account for
it in post-processing as well.
----------------------------------------------------------------------------
This work was done in order to handle some of these large data sets, and
I've found that the performance is reasonable - here are some stats for
very large file (the largest of which used to take well over 12 minutes,
now it takes about 5 1/2 minutes - and a lot of that is just getting the
18GiB of data read in):
Size Real User System
----- -------- -------- -------
7GiB 123.445s 80.188s 11.392s
10GiB 179.148s 137.456s 16.680s
13GiB 237.561s 156.992s 21.968s
16GiB 283.262s 187.468s 26.748s
18GiB 336.345s 225.084s 31.200s
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Added in -t and -T options to allow bounding of traces analyzed. Be
forewarned: this can result in some excessive numbers of orphaned traces
(partial IO streams before the -t tiem and after the -T time won't
be analyzed).
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Two major updates:
(1) Added in some robustness - can accept out-of-order traces, and can
"orphan" unfinished IO streams.
(2) Added in ability to put IO streams to a file, sending Q-to-C traces
on a per-IO bases.
The additional robustness comes at some expense (performance), and
so I will look into that next. (Perhaps see what those Judy trees buy
us... :-) )
Signed-off-by: Alan D. Brunelle <Alan.Brunelle@hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
