blob: 835291223de22cf43efeff519bd381ff936bd22e [file] [log] [blame]
Brendan Gregg48fbc3e2015-08-18 14:56:14 -07001Demonstrations of disksnoop.py, the Linux eBPF/bcc version.
2
3
4This traces block I/O, a prints a line to summarize each I/O completed:
5
6# ./disksnoop.py
7TIME(s) T BYTES LAT(ms)
816458043.435457 W 4096 2.73
916458043.435981 W 4096 3.24
1016458043.436012 W 4096 3.13
1116458043.437326 W 4096 4.44
1216458044.126545 R 4096 42.82
1316458044.129872 R 4096 3.24
1416458044.130705 R 4096 0.73
1516458044.142813 R 4096 12.01
1616458044.147302 R 4096 4.33
1716458044.148117 R 4096 0.71
1816458044.148950 R 4096 0.70
1916458044.164332 R 4096 15.29
2016458044.168003 R 4096 3.58
2116458044.171676 R 4096 3.59
2216458044.172453 R 4096 0.72
2316458044.173213 R 4096 0.71
2416458044.173989 R 4096 0.72
2516458044.174739 R 4096 0.70
2616458044.190334 R 4096 15.52
2716458044.196608 R 4096 6.17
2816458044.203091 R 4096 6.35
29
30The output includes a basic timestamp (in seconds), the type of I/O (W == write,
31R == read, M == metadata), the size of the I/O in bytes, and the latency (or
32duration) of the I/O in milliseconds.
33
34The latency is measured from I/O request to the device, to the device
35completion. This excludes latency spent queued in the OS.
36
37Most of the I/O in this example were 0.7 and 4 milliseconds in duration. There
38was an outlier of 42.82 milliseconds, a read which followed many writes (the
39high latency may have been caused by the writes still being serviced on the
40storage device).