Задался я по работе интересным вопросом - а как собственно узнать какое приложение под Linux грузит диск? Для CPU есть top - а для диска?
Дебианщики скажут - iotop, но там нужно свеженькое ядро, а у нас CentOS 5 на 2.6.18 - и что ж нам делать?
Оказывается есть минимум три выхода.
1. Если ядро 2.6.1 и новее - а оно наверно так и есть, можно сказать
% sudo sysctl vm.block_dump=1
и после чего в /var/log/debug начинает валиться что то типа
2. dstat - http://dag.wieers.com/home-made/dstat/
Тоже не "мегамагия", но на CentOS работает, хотя по дефолту выводит просто ИМЯ самого прожорливого до диска процесса - если их несколько (java?) то остается догадываться какой это именно процесс. В принципе плагины для него написаны на Питоне, и можно покопаться, но есть способ еще лучше.
3. SystemTap - http://sourceware.org/systemtap/
О, а вот это уже интересная штучка - аналог DTrace (который под Линукс нельзя портировать из за лицензионных ограничений). Поддерживается кучей контор, в т.ч. RedHat и IBM.
Полностью работоспособен в RHEL/Centos начиная с 5 версии. Для CentOS правда нужно доставить kernel-debug RPMки вручную (если у вас нестандартное ядро - придется их собрать и установить, но вся инфа есть тут - http://sourceware.org/systemtap/wiki/SystemTapOnCentOS)
Безопасен для production систем, вроде как - паники не вызывает.
Устанавиваем, идем на http://sourceware.org/systemtap/wiki/ScriptsTools, качаем disktop.stp, запускаем -
(На самом деле если копнуть глубже то цифрам трафика верить нельзя, но порядок нагрузки ясен. Почему обьяснено тут - http://dtrace.org/blogs/brendan/2011/10/15/using-systemtap/ )
Тулза, похоже, очень перспективная, нужно будет поковырять и изучить.
Дебианщики скажут - iotop, но там нужно свеженькое ядро, а у нас CentOS 5 на 2.6.18 - и что ж нам делать?
Оказывается есть минимум три выхода.
1. Если ядро 2.6.1 и новее - а оно наверно так и есть, можно сказать
% sudo sysctl vm.block_dump=1
и после чего в /var/log/debug начинает валиться что то типа
May 27 10:00:20 kex kernel: tail(11548): dirtied inode 14093100 (ld.so.cache) on sda1
May 27 10:00:20 kex kernel: tail(11548): dirtied inode 15269995 (libm.so.6) on sda1
May 27 10:00:20 kex kernel: tail(11548): dirtied inode 15270399 (libm-2.3.2.so) on sda1
...
May 27 10:00:20 kex kernel: tail(11548): dirtied inode 18154515 (locale-archive) on sda1
May 27 10:00:21 kex kernel: pdflush(140): WRITE block 76808312 on sda1
..
Это конечто не Бог весть что, но с помощью могучей магии Перла или шелла это можно распарсить и просуммировать - % grep sda1 /var/log/debug | grep READ | cut -d: -f4 | sort | uniq -c | sort -rn | head
1056 find(11566)
247 mysqld(11855)
43 mysqld(11751)
26 mysqld(11790)
21 tar(11717)
16 mysqladmin(11748)
13 mysqld(11899)
13 grep(4560)
12 mysqld(11863)
6 mysqld(11760)
В общем, хоть что то, но есть способ лучше -2. dstat - http://dag.wieers.com/home-made/dstat/
Тоже не "мегамагия", но на CentOS работает, хотя по дефолту выводит просто ИМЯ самого прожорливого до диска процесса - если их несколько (java?) то остается догадываться какой это именно процесс. В принципе плагины для него написаны на Питоне, и можно покопаться, но есть способ еще лучше.
3. SystemTap - http://sourceware.org/systemtap/
О, а вот это уже интересная штучка - аналог DTrace (который под Линукс нельзя портировать из за лицензионных ограничений). Поддерживается кучей контор, в т.ч. RedHat и IBM.
Полностью работоспособен в RHEL/Centos начиная с 5 версии. Для CentOS правда нужно доставить kernel-debug RPMки вручную (если у вас нестандартное ядро - придется их собрать и установить, но вся инфа есть тут - http://sourceware.org/systemtap/wiki/SystemTapOnCentOS)
Безопасен для production систем, вроде как - паники не вызывает.
Устанавиваем, идем на http://sourceware.org/systemtap/wiki/ScriptsTools, качаем disktop.stp, запускаем -
[root@localhost src]# stap -v disktop.stp
Pass 1: parsed user script and 72 library script(s) using 21380virt/12988res/2280shr kb, in 300usr/220sys/712real ms.
Pass 2: analyzed script: 6 probe(s), 33 function(s), 7 embed(s), 21 global(s) using 122028virt/45148res/4200shr kb, in 2430usr/3790sys/16852real ms.
Pass 3: translated to C into "/tmp/stapFxPYtp/stap_5caa87e008b9d53ed275791ebd211ed4_27487.c" using 119868virt/45400res/5432shr kb, in 660usr/290sys/1328real ms.
Pass 4: compiled C into "stap_5caa87e008b9d53ed275791ebd211ed4_27487.ko" in 4630usr/3600sys/11755real ms.
Pass 5: starting run.
Tue Jan 24 15:41:06 2012 , Average: 2Kb/sec, Read: 13Kb, Write: 1Kb
UID PID PPID CMD DEVICE T BYTES
500 3629 3621 pam_timestamp_c dm-0 R 13824
501 2759 2757 java dm-0 W 690
501 2545 2542 java dm-0 W 552
Tue Jan 24 15:41:11 2012 , Average: 2Kb/sec, Read: 13Kb, Write: 1Kb
UID PID PPID CMD DEVICE T BYTES
0 2395 1 VBoxService dm-0 R 13824
501 2545 2542 java dm-0 W 690
501 2759 2757 java dm-0 W 671
Tue Jan 24 15:41:16 2012 , Average: 2Kb/sec, Read: 13Kb, Write: 1Kb
UID PID PPID CMD DEVICE T BYTES
500 3629 3621 pam_timestamp_c dm-0 R 13824
501 2759 2757 java dm-0 W 690
501 2545 2542 java dm-0 W 671
Tue Jan 24 15:41:21 2012 , Average: 5Kb/sec, Read: 27Kb, Write: 1Kb
UID PID PPID CMD DEVICE T BYTES
0 2395 1 VBoxService dm-0 R 13824
500 3629 3621 pam_timestamp_c dm-0 R 13824
501 2545 2542 java dm-0 W 690
501 2759 2757 java dm-0 W 671
Последняя колонка - трафик в байтах. Ура, радуемся и крутим фонарики.(На самом деле если копнуть глубже то цифрам трафика верить нельзя, но порядок нагрузки ясен. Почему обьяснено тут - http://dtrace.org/blogs/brendan/2011/10/15/using-systemtap/ )
Тулза, похоже, очень перспективная, нужно будет поковырять и изучить.
