Řešení 1:
Pokud budete mít to štěstí, že zachytíte další období špičkového využití, můžete interaktivně studovat statistiky I/O jednotlivých procesů pomocí iotop.
Řešení 2:
Můžete použít pidstat k tisku kumulativní statistiky io za proces každých 20 sekund pomocí tohoto příkazu:
# pidstat -dl 20
Každý řádek bude mít následující sloupce:
- PID – ID procesu
- kB_rd/s – Počet kilobajtů, které úloha způsobila ke čtení z disku za sekundu.
- kB_wr/s – Počet kilobajtů, které úloha způsobila nebo má způsobit zápis na disk za sekundu.
- kB_ccwr/s – Počet kilobajtů, jejichž zápis na disk byl úlohou zrušen. K tomu může dojít, když úloha zkrátí nějakou špinavou mezipaměť stránek. V tomto případě se některá IO, pro kterou byla zaúčtována jiná úloha, neuskuteční.
- Příkaz – Název příkazu úlohy.
Výstup vypadá takto:
05:57:12 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command
05:57:32 PM 202 0.00 2.40 0.00 jbd2/sda1-8
05:57:32 PM 3000 0.00 0.20 0.00 kdeinit4: plasma-desktop [kdeinit]
05:57:32 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command
05:57:52 PM 202 0.00 0.80 0.00 jbd2/sda1-8
05:57:52 PM 411 0.00 1.20 0.00 jbd2/sda3-8
05:57:52 PM 2791 0.00 37.80 1.00 kdeinit4: kdeinit4 Running...
05:57:52 PM 5156 0.00 0.80 0.00 /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing
05:57:52 PM 8651 98.20 0.00 0.00 bash
05:57:52 PM PID kB_rd/s kB_wr/s kB_ccwr/s Command
05:58:12 PM 202 0.00 0.20 0.00 jbd2/sda1-8
05:58:12 PM 3000 0.00 0.80 0.00 kdeinit4: plasma-desktop [kdeinit]
Řešení 3:
Nic nepřekoná průběžné monitorování, po události jednoduše nemůžete získat zpět časově citlivá data...
Existuje několik věcí, které byste mohli být však schopen zkontrolovat, zda je zapletené nebo eliminovat — /proc je váš přítel.
sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats
Pole 10, 11 jsou akumulované zapsané sektory a akumulovaný čas (ms) zápisu. Tím se zobrazí vaše horké oddíly systému souborů.
cut -d" " -f 1,2,42 /proc/[0-9]*/stat | sort -n -k +3
Tato pole jsou PID, příkaz a kumulativní IO-wait ticks. Zobrazí se vaše horké procesy, i když pouze pokud stále běží . (Pravděpodobně budete chtít ignorovat vlákna žurnálování vašeho souborového systému.)
Užitečnost výše uvedeného závisí na době provozuschopnosti, povaze vašich dlouho běžících procesů a způsobu použití vašich souborových systémů.
Upozornění:nevztahuje se na jádra starší než 2.6, pokud si nejste jisti, podívejte se do dokumentace.
(Teď jděte a udělejte laskavost svému budoucímu já, nainstalujte Munin/Nagios/Cacti/cokoli;-)
Řešení 4:
Použijte atop . (http://www.atoptool.nl/)
Zapište data do komprimovaného souboru atop mohou číst později v interaktivním stylu. Měřte hodnotu (delta) každých 10 sekund. udělejte to 1080krát (3 hodiny; takže pokud na to zapomenete, výstupní soubor vám nedojde disk):
$ atop -a -w historical_everything.atop 10 1080 &
Poté, co se špatná věc stane znovu:
(i když stále běží na pozadí, každých 10 sekund se přidá)
% atop -r historical_everything.atop
Protože jste řekli IO, stiskl bych 3 klávesy:tdD
t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display
Řešení 5:
Použijte btrace . Použití je snadné, například btrace /dev/sda . Pokud příkaz není dostupný, je pravděpodobně dostupný v balíčku blktrace .
UPRAVIT :Protože debugfs není v jádře povoleno, můžete zkusit date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf nebo podobné. Protokolování chyb stránek samozřejmě není totéž jako použití btrace, ale pokud budete mít štěstí, MŮŽE vám to napovědět o procesech, které mají největší nároky na disk. Právě jsem vyzkoušel jeden z mých nejintenzivnějších I/O serverů a seznam zahrnoval procesy, o kterých vím, že spotřebovávají spoustu I/O.