I have a server running Ubuntu Server 12.04, and I'd like to see disk IO stats. I've tried top and htop, and neither of them output anything resembling IO stats. Is there a command line tool that does this?
6 Answers
You are probably looking for iotop. It provides the information you are looking for per process. You will need to run it with super-user privileges if you run a recent kernel since some changes to the NET_ADMIN permissions have been done something like a year ago. Simply install it and run sudo iotop
Bwm-ng can also output some disk I/o stats when you cycle through the available methods. The advantage of bwm-ng on linux over iotop is that you don't need the NET_ADMIN capability so it will work as a normal user by default. It provides the information per device as you can see in the picture.
If you want to have the lifetime stats of your disk, try smartctl -a /dev/your/disk
-
Install
bwm-ng
withsudo apt install bwm-ng
and run it withbwm-ng -i disk
Mar 10, 2018 at 3:58
htop
can display per-process I/O rates, but you need to have added one of the IO_READ_RATE/IO_WRITE_RATE/IO_RATE
columns.
-
1
You can use pidstat (free and open-source):
The pidstat command is used to monitor processes and threads currently being managed by the Linux kernel. It can also monitor the children of those processes and threads.
With its -d option, pidstat can report I/O statistics, providing that you have a recent Linux kernel (2.6.20+) with the option CONFIG_TASK_IO_ACCOUNTING compiled in. So imagine that your system is undergoing heavy I/O and you want to know which tasks are generating them
You can use iostat:
- free and open source
sudo apt-get install -y sysstat
iostat -dx 3
will display extended device statistics since system start up in the first
report, and the deltas for the last 3 seconds in subsequent reports until interrupted.
Columns' meanings:
- Device: This column gives the device (or partition) name.
- tps: Indicate the number of transfers per second that were issued to the device.
- Blk_read/s: Indicate the amount of data read from the device expressed in a number of blocks per second.
- Blk_wrtn/s: Indicate the amount of data written to the device expressed in a number of blocks per second.
- Blk_read: The total number of blocks read.
- Blk_wrtn: The total number of blocks written.
- kB_read/s: Indicate the amount of data read from the device expressed in kilobytes per second.
- kB_wrtn/s: Indicate the amount of data written to the device expressed in kilobytes per second.
- kB_read: The total number of kilobytes read.
- kB_wrtn: The total number of kilobytes written.
- MB_read/s: Indicate the amount of data read from the device expressed in megabytes per second.
- MB_wrtn/s: Indicate the amount of data written to the device expressed in megabytes per second.
- MB_read: The total number of megabytes read.
- MB_wrtn: The total number of megabytes written.
- rrqm/s: The number of read requests merged per second that were queued to the device.
- wrqm/s: The number of write requests merged per second that were queued to the device.
- r/s: The number of read requests that were issued to the device per second.
- w/s: The number of write requests that were issued to the device per second.
- rsec/s: The number of sectors read from the device per second.
- wsec/s: The number of sectors written to the device per second.
- rkB/s: The number of kilobytes read from the device per second.
- wkB/s: The number of kilobytes written to the device per second.
- rMB/s: The number of megabytes read from the device per second.
- wMB/s: The number of megabytes written to the device per second.
- avgrq-sz: The average size (in sectors) of the requests that were issued to the device.
- avgqu-sz: The average queue length of the requests that were issued to the device.
- await: The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
- svctm: The average service time (in milliseconds) for I/O requests that were issued to the device.
- %util: Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.
(PS: +1 for iotop, that's the one I use the most)
If you want to see the overall current status and performance of your I/O, in my experience the easiest and clearest of all is atop
(packaged in most distros):
You can just read the "DSK" and "LVM" rows at the top and see what's going on. If your I/O is stressed, they are red and very easy to spot. This way, you can see whether you have a problem of I/O, if it's a read or write problem, what drive, etc., all in less than a second.
The other answers are fine too. I usually use htop
to identify what process is at fault if any, iotop
for more focused measuring, iostat
for long periods and pidstat
to monitor a specific process.
I like dstat
Dstat is a versatile replacement for vmstat, iostat and ifstat. Dstat overcomes some of the limitations and adds some extra features.
Dstat allows you to view all of your system resources instantly, you can compare disk usage in combination with interrupts from your controller, or compare the network bandwidth numbers directly with the disk throughput (in the same interval).
Dstat also gives you the most detailed information in columns and clearly indicates in what magnitude and unit the output is displayed. Less confusion, less mistakes, more efficient.
Dstat is unique in letting you aggregate block device throughput for a certain diskset or network bandwidth for a group of interfaces, ie. you can see the throughput for all the block devices that make up a single filesystem or storage system.
Dstat allows its data to be directly written to a CSV file to be imported and used by OpenOffice, Gnumeric or Excel to create graphs.
The above is an example from the command dstat -D total,sda,sdb,sdc,sdd,sde
for more information check the man page man dstat
-
-
-
@seanlinsley github.com/rpodgorny/dstat/tree/python3 has some preliminary work. Jul 6, 2017 at 17:38