Current File : //usr/share/doc/bpftrace/examples/writeback_example.txt
Demonstrations of writeback, the Linux bpftrace/eBPF version.
This tool traces when the kernel writeback procedure is writing dirtied pages
to disk, and shows details such as the time, device numbers, reason for the
write back, and the duration. For example:
# ./writeback.bt
Attaching 4 probes...
Tracing writeback... Hit Ctrl-C to end.
TIME DEVICE PAGES REASON ms
23:28:47 259:1 15791 periodic 0.005
23:28:48 259:0 15792 periodic 0.004
23:28:52 259:1 15784 periodic 0.003
23:28:53 259:0 18682 periodic 0.003
23:28:55 259:0 41970 background 326.663
23:28:56 259:0 18418 background 332.689
23:28:56 259:0 60402 background 362.446
23:28:57 259:1 18230 periodic 0.005
23:28:57 259:1 65492 background 3.343
23:28:57 259:1 65492 background 0.002
23:28:58 259:0 36850 background 0.000
23:28:58 259:0 13298 background 597.198
23:28:58 259:0 55282 background 322.050
23:28:59 259:0 31730 background 336.031
23:28:59 259:0 8178 background 357.119
23:29:01 259:0 50162 background 1803.146
23:29:02 259:0 27634 background 1311.876
23:29:03 259:0 6130 background 331.599
23:29:03 259:0 50162 background 293.968
23:29:03 259:0 28658 background 284.946
23:29:03 259:0 7154 background 286.572
[...]
By looking a the timestamps and latency, it can be seen that the system was
not spending much time in writeback until 23:28:55, when "background"
writeback began, taking over 300 milliseconds per flush.
If timestamps of heavy writeback coincide with times when applications suffered
performance issues, that would be a clue that they are correlated and there
is contention for the disk devices. There are various ways to tune this:
eg, vm.dirty_writeback_centisecs.
Mini Shell