biotop(8)

πŸ“¦
version 0.35.0 Β· 2 versions
  • 0.35.0 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 0.18.0 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’Ύ biotop(8) β€” System Manager's Manual πŸ’Ύ

✨ NAME ✨

biotop β€” Block device (disk) I/O by process top. πŸ’–

πŸŽ€ SYNOPSIS πŸŽ€

biotop [-h] [-C] [-r MAXROWS] [-p PID] [interval] [count]

πŸ“– DESCRIPTION πŸ“–

okay so this is top but for disks πŸ’…

It traces block device I/O (disk I/O) and prints a per-process summary every interval (1 second by default). The summary is sorted by the top disk consumers by throughput (Kbytes), so you can see who's really eating the disk. πŸ”₯ The PID and process name shown are measured from when the I/O was first created, which usually identifies the responsible process. 🫢

For efficiency, it uses in-kernel eBPF maps to cache process details (PID and comm) by I/O request, plus a starting timestamp for calculating I/O latency, and the final summary. the way that's so smart 🧚

It works by tracing various kernel blk_*() functions using dynamic tracing, and it will need updating to match any changes to those functions. bestie, keep that in mind πŸ™ˆ

⚠️ Since this uses BPF, only the root user can use this tool. no cap, you need to be root or it's a hard no πŸ’€

🧰 REQUIREMENTS 🧰

You'll need CONFIG_BPF and bcc. ✨

πŸ‘‘ OPTIONS πŸ‘‘

  • -C β€” don't clear the screen, keep the old output visible 🌸
  • -r MAXROWS β€” max number of rows to print. default is 20 πŸ’œ
  • -p PID β€” trace this PID only 🎯
  • interval β€” time between updates, in seconds ⏱️
  • count β€” how many interval summaries you want πŸ”’

πŸ’… EXAMPLES πŸ’…

Summarize block device I/O by process, with a 1 second screen refresh:

# biotop

Don't clear the screen:

# biotop -C

5 second summaries, 10 times only:

# biotop 5 10

πŸ¦‹ FIELDS πŸ¦‹

  • loadavg β€” the contents of /proc/loadavg 🌈
  • PID β€” cached process ID, if present. this usually (but isn't guaranteed to) identify the responsible process for the I/O πŸ†”
  • COMM β€” cached process name, if present. this usually (but isn't guaranteed to) identify the responsible process for the I/O 🏷️
  • D β€” direction: R == read, W == write. this is a simplification πŸ”„
  • MAJ β€” major device number πŸ”’
  • MIN β€” minor device number πŸ”’
  • DISK β€” disk device name πŸ’Ύ
  • I/O β€” number of I/O during the interval πŸ“¦
  • Kbytes β€” total Kbytes for these I/O during the interval πŸ“ˆ
  • AVGms β€” average time for the I/O (latency) from issue to the device, to its completion, in milliseconds ⚑

πŸŒ™ OVERHEAD πŸŒ™

block device I/O usually happens at a relatively low frequency (< 10,000/s), so the overhead for this tool is expected to be low or negligible. ✨ For high IOPS storage systems, though, test and quantify before use. πŸ™ˆ

🌐 SOURCE 🌐

This is from bcc. 🐝

https://github.com/iovisor/bcc

Also look in the bcc distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool. it's giving helpful πŸ“š

πŸ–₯️ OS πŸ–₯️

Linux 🐧

🚧 STABILITY 🚧

Unstable, still in development. πŸ› οΈ

🎨 AUTHOR 🎨

Brendan Gregg, Rocky Xing 🫢

πŸ’‘ INSPIRATION πŸ’‘

top(1) by William LeFebvre 🌟

πŸ”— SEE ALSO πŸ”—

biosnoop(8), biolatency(8), iostat(1) πŸ’œ


that's a wrap, bestie πŸŽ€ this page is from the USER COMMANDS section, dated 2016-02-06, and it's all about biotop(8) πŸ’–βœ¨