iotop для FreeBSD

top -m io -o total

Работает суперски, сейчас попробовал загрузить диск dd шкой, так она сразу взлетела в верх списка :)

Анализ нагрузки на диск на Debian Lenny

Часто приходится слышат: "дисковая подсистема - самое узкое место системы", но кто именно убивает винты никто конкретики обычно не дает. Мы как раз будем собирать конкретику прямо с работющей системы :)


Стаивим iotop:

apt-get install iotop -y

Запускаем процесс мониторинга:

nohup iotop --batch --delay 2 --only > /root/iotop_6may.log &

Теперь в файле лога мы увидим нечто вот такое (много-много подобных блоков):

Total DISK READ: 202.58 K/s | Total DISK WRITE: 35.40 K/s
PID USER DISK READ DISK WRITE SWAPIN IO COMMAND
2124 www-data 165.21 K/s 3.93 K/s 0.00 % 8.95 % nginx: worker process
2125 www-data 31.47 K/s 1.97 K/s 0.00 % 0.82 % nginx: worker process
25740 postfix 0 B/s 7.87 K/s 0.00 % 0.09 % tlsmgr -l -t unix -u -c
24583 root 0 B/s 3.93 K/s 0.00 % 0.00 % rsyslogd -c3
6827 www-data 0 B/s 1.97 K/s 0.00 % 0.00 % apache2 -k start

В идеале, оставить сбор лога на сутки, а потом его пропарсить, так данные будут очень точны.

На основе этой информации, можно составить мини-топ пожирателей жесткого диска, который, во-первых, покажет, кто вообще использует диск, во-вторых, каким образом он его использует (чтение / запись), а, в-третьих, позволит указать относительных лидеров по потреблению дисковых ресурсов. Без этих данных оптимизация дисковой системы бессмысленная и невозможна (ну да, SAS/SSD поставить разве что).

Для начала вырезаем заголовки, которые полезной информации нам не несут:

cat /root/iotop_6may.log | grep -v 'Total' | grep -v 'PID'

А теперь все это анализируем спец скриптом:

cat /root/iotop_6may.log | grep -v 'Total' | grep -v 'PID' | perl -MData::Dumper -e 'my$hs={}; for(<>){ chomp;s/^\s+//g; my@a=split"\\s+",$_; /%\s+([^%]*)$/; $hs->{$1}->{read}+=$a[2];$hs->{$1}->{write}+=$a[4];$hs->{$1}->{swap}+=$a[6]; $hs->{$1}->{io}+=$a[8]; } print "$_\nread: $hs->{$_}->{read} write: $hs->{$_}->{write} swap: $hs->{$_}->{swap} io: $hs->{$_}->{io}\n\n" for reverse sort { my$type="write";$hs->{$a}->{$type} <=> $hs->{$b}->{$type} } keys %$hs;'

Далее, варируя значение $type="write"; выбираем тип сортировки. В самом верху - самый грузящий процесс.

Также немного изменив скрипт, можно научить его делать детализацию не по процесса, а по пользователям:

cat /root/iotop_6may.log | grep -v 'Total' | grep -v 'PID' | perl -MData::Dumper -e 'my$hs={}; for(<>){ chomp;s/^\s+//g; my@a=split"\\s+",$_; /\d+\s+(.*?) /; $hs->{$1}->{read}+=$a[2];$hs->{$1}->{write}+=$a[4];$hs->{$1}->{swap}+=$a[6]; $hs->{$1}->{io}+=$a[8]; } print "$_\nread: $hs->{$_}->{read} write: $hs->{$_}->{write} swap: $hs->{$_}->{swap} io: $hs->{$_}->{io}\n\n" for reverse sort { my$type="write";$hs->{$a}->{$type} <=> $hs->{$b}->{$type} } keys %$hs;'

Установка iotop на CentOS пока невозможна :(

Офсайт сабжа: http://guichaz.free.fr/iotop/

В 0.4 версии iotop наконец-то начал поддерживать Python 2.4, поэтому появилась возможность его запускать на CentOS без особых извращений.

Ставим зависимости:

yum install -y python-ctypes

Проверяем наличие требуемых возможностей ядра (есть в ядрах от RHEL 164 и выше, а также в 128х ядрах OpenVZ):

zcat /proc/config.gz | egrep 'TASK_IO_ACCOUNTING|TASK_DELAY_ACCT'
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

Или вот так:

cat /boot/config-`uname -r` | egrep 'TASK_IO_ACCOUNTING|TASK_DELAY_ACCT'
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

Стягиваем дистрибутив:

cd /usr/src
wget http://guichaz.free.fr/iotop/files/iotop-0.4.tar.bz2
tar -xf iotop-0.4.tar.bz2
cd iotop-0.4

Запускаем:

./iotop.py

И при этом сильно обламываемся, получая в ответ "CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %"

Вот тут трабл :( По-видимому, при бэкапортинге io-аккаунтинга в новые rhel ядра (164+) интерфейс netlink для забора этих данных не бэкпортнули.

Аналог iotop / dstat на ядрах младше 164

Есть такой вот интересный способ мониторинга нагрузки на диск, если на текущей платформе не работает iotop (например, на CentOS c 128 ядрами).

cd /opt/
wget http://aspersa.googlecode.com/svn/trunk/iodump

Отключаем syslog, иначе весь винт забьет логами:

/etc/init.d/syslog stop

Активируем сброс ядром всей информации о вводе-выводе:

echo 1 > /proc/sys/vm/block_dump
while true; do sleep 1; dmesg -c; done | perl iodump
echo 0 > /proc/sys/vm/block_dump

Чтобы увидеть результат работы скрипта, необходимо подождать минут 5 и потом нажать CTRL+C, при этом на экране будет вадан список самых грузящих диск приложений.

После окончания работы не забываем включить syslog.

http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

dstat (iotop), боевые примеры

Следим за нагрузкой на "железо":

root@libvirt ~ # dd if=/dev/md0 of=/dev/null &
[1] 16974
root@libvirt ~ # dstat --top-bio
----most-expensive----
block i/o process
dd 57M 0
dd 58M 0
dd 58M 0
dd 58M

При этом мониторинг нагрузки "на софт":

root@libvirt ~ # dd if=/dev/md0 of=/dev/null &
[1] 16978
root@libvirt ~ # dstat --top-io
----most-expensive----
i/o process
dd 56M 56M
dd 60M 60M
dd 54M 54M
dd 60M 60M

Как говорится - разница налицо :)

Установка dstat как замены iotop на CentOS 5 Linux на ядрах 164+

Вкратце, dstat - утилита, позволяющая определить, какой именно процесс грузит Вам диск; мануал: http://dag.wieers.com/home-made/dstat/dstat.1.html

Подключаем RPM-Forge:

wget -O/tmp/rpm-forge.rpm http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm && rpm -ihv /tmp/rpm-forge.rpm

yum -y install dstat

Прежде чем продолжить, небольшой дисклеймер по поводу содержимого /proc/self/io:

rchar - bytes read
wchar - byres written
syscr - number of read syscalls
syscw - number of write syscalls
read_bytes - number of bytes caused by this process to read
from underlying storage
write_bytes - number of bytes caused by this process to written from
underlying storage

Мониторим по read_bytes / write_bytes (нагрузка на "железо"):

dstat --top-bio

Мониторим по rchar/wchar (нагрузка на "по", т.е. включая обращения к всяким виртуальным ФС):

dstat --top-io

dstat --list
internal:
aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw,
socket, swap, swapold, sys, tcp, time, udp, unix, vm
/usr/share/dstat:
battery, battery-remain, cpufreq, dbus, disk-util, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io,
innodb-ops, lustre, memcache-hits, mysql-io, mysql-keys, mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets,
nfs3, nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, rpc, rpcd, sendmail, snooze, thermal, top-bio, top-cpu,
top-cputime, top-cputime-avg, top-io, top-latency, top-latency-avg, top-mem, top-oom, utmp, vm-memctl, vmk-hba, vmk-int,
vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

А сами плагины лежат тут:

/usr/share/dstat

P.S. даже не пытайтесь собрать глючащий iotop под CentOS, я на это уйму времени потратил и все без толку, dstat - наше все.

Debian: как узнать, какой процесс забивает io?

Легко:

apt-get install -y iotop

И запускаем:

iotop