Úvodem, monitorování disků řešíme zpravidla na třech rozdílných úrovních:

• monitorování stavu disku (S.M.A.R.T. pre-failure testy, teploty apod.),
• sledování velikosti volného místa,
• měření výkonnostních parametrů.

I když se jedná o poměrně izolované úlohy, v extrémních případech mohou často souviset – disk, jehož volná kapacita se téměř vyčerpala, bude pravděpodobně pomalý, protože velké soubory budou uloženy na různých, nesouvislých částech disku. Stejně tak pomalý bude disk, který vykazuje velkou chybovost při čtení nebo zápisu. Na druhou stranu můžeme mít disk, který je téměř prázdný a přesto je jasné, že jeho výkonnostní hranice už byla dosažena a je většinu času přetížený.

Obecně je dobré sledovat několik parametrů diskových oddílů a zařízení:

Stav disku, včetně například okamžité naměřené teploty; s tím vám pomůže balík S.M.A.R.T. Monitoring Tools (smartmontools), který umožňuje jednak zobrazení získaných dat, jednak spouštění pravidelných testů, které mohou upozornit na případné problémy.

Velikost volného místa; typicky nás zajímá, jak rychle se diskový prostor plní a jestli je na něm stále ještě dostatek místa s výhledem na dobu dostatečně dlouhou pro případné provedení údržby a nebo navýšení diskové kapacity, typickým zástupcem podobného sledováním jsou agenti a klienti monitorovacích systémů jako Nagios nebo Zabbix.

Statistiky filesystému; přestože je diskový oddíl téměř prázdný, může nás stále zajímat, jestli na disku opravdu nic není, nebo jestli jsou v 1 % prostoru desetitisíce malých souborů v jednom adresáři,

Výkonnostní statistiky; počet čtení a zápisů, velikost přenosů a čekání – přesně to, co nás bude dál zajímat nejvíc.

I/O wait

Začít můžeme u I/O waitu. Pokud se podíváte třeba na výstup programu top:

top - 00:01:20 up 36 days,  2:23,  3 users,  load average: 0.55, 0.38, 0.39
Tasks: 303 total,   2 running, 300 sleeping,   0 stopped,   1 zombie
Cpu(s):  4.7%us,  0.6%sy,  0.1%ni, 94.4%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8197104k total,  7986680k used,   210424k free,   403228k buffers
Swap:  2047992k total,    33512k used,  2014480k free,  4647348k cached

Uvidíte v hlavičce jako jednu z položek procentuální hodnotu I/O waitu (zde tučně zvýrazněna), neboli vytížení procesorů systému procesy, které čekají na dokončení I/O operace (typicky čtení nebo zápis na disky). Mimochodem, často takové procesy uvidíte v topu ve stavu D, což je "Uninterruptible sleep", stav, do kterého se dostane proces obvykle tak, že zavolá jádro pro vyřízení své diskové operace a čeká, až se provede; kvůli možným komplikacím v ovladačích a hardware se takový proces nedá přerušit (například zasláním signálu), než bude jeho volání vyřízeno.

Z pohledu výkonu je důležité, že procesy zahrnuté v I/O waitu neblokují přímo procesor – procenta v I/O wait by se dala zařadit do "idle", tedy do nečinných procesů, nicméně vysoká hodnota I/O wait znamená, že úzké hrdlo systému bude právě v I/O operacích, což je nejčastěji právě disk nebo celé diskové pole.

I/O wait je zajímavé vidět v čase a stejně jako u všech zátěžových charakteristik, i zde budou také důležitá špičková vytížení a doba, po kterou byla zátěž vysoká. Proto bude určitě dobré nasadit na server nějaký nástroj, který bude hodnotu I/O waitu pravidelně sledovat a zapisovat. Nástrojů, které vám to umožní, je celá řada – typickými zástupci jsou vmstat, iostat a sysstat a pak samozřejmě téměř každý monitorovací systém, který sleduje a rozlišuje diskovou zátěž.

Jak ale postupovat dál v případě, když zjistíme, že hodnota I/O waitu je vysoká? Odpovědí by mohly být statistiky jednotlivých disků a případně diskových polí.

Disková zátěž jednotlivých blokových zařízení

Základem pro sledování statistik blokových zařízení pro nás bude přímo kernel – hodně užitečných dat je uvedeno přímo v /proc/diskstats, kde uvidíte čísla jako:

   8    0 sda 114937041 430053244 14780673790 1005743712 305186779 4163834220 35954954496 
3124512376 0 1489630472 4132337912
   8    1 sda1 2253227 9898666 217398570 20016652 24548163 80016126 884139168 
972672204 0 261134948 992713188
   8    2 sda2 112683794 420154553 14563274860 985726944 280638616 4083818094 35070815328 
2151840172 0 1370196108 3139654780
   8   16 sdb 112700642 433871634 14780179842 1050568364 305161181 4163860194 35954954496 
3300799732 0 1487769204 58597844
   8   17 sdb1 2244945 9941296 217750364 19536000 24546583 80017717 884139168 
972636000 0 253918440 992186472
   8   18 sdb2 110455679 423930311 14562429118 1031032232 280614598 4083842477 35070815328 
2328163732 0 1373252724 33614047

   9    0 md0 22506458 0 200730458 0 98611624 0 788892992 0 0 0 0
   9    1 md1 931707817 0 11778397630 0 4345944235 0 34767553888 0 0 0 0

 253    0 dm-0 650959631 0 6208280794 3865397712 887806974 0 7102455792 
2976043268 0 1058890020 2555681032
 253    1 dm-1 221739238 0 1836898146 1093817892 17095066 0 136760528 
1943946316 0 92143064 3037860680
 253    2 dm-2 58342653 0 3727888282 325955128 3419853914 0 27358831312 
3225694340 0 478127940 3639197436

Jak je na první pohled vidět, jedná se o bloková zařízení sda a sdb, MD (Multiple Device) zařízení md0 a md1 (obvykle implementace softwarového RAIDu) a DM (Device Mapper) zařízení (typický oddíl s šifrovaným souborovým systémem, popř. oddíly z LVM, Logical Volume Manager). Co ale jednotlivé sloupce znamenají?

Přesný význam jednotlivých hodnot je popsán v dokumentaci k linuxovému jádru (Documentation/iostats.txt), kde se dozvíme především, že nejdříve je:

Major číslo zařízení, minor číslo zařízení a jméno zařízení.

A pak:

Pole 1, počet dokončených čtení,

pole 2, počet operací čtení, které byly spojeny – když jádro dostane dva požadavky na čtení dvou po sobě jdoucích sektorů, může je spojit v jeden; toto pole pak udává počet takových událostí,

pole 3, počet přečtených sektorů,

pole 4, doba strávená čtením v milisekundách,

pole 5, počet dokončených zápisů,

pole 6, počet spojených operací zápisů, podobně jako Pole 2 pro čtení,

pole 7, počet zapsaných sektorů,

pole 8, doba strávená zápisem v milisekundách,

pole 9, délka fronty I/O operací (méně je lépe),

pole 10, doba strávená I/O operacemi v milisekundách,

pole 11, vážený počet milisekund strávených v I/O, téměř každá operace zvyšuje čítač o jedničku, ten je následně vynásoben dobou v I/O od poslední aktualizace hodnoty.

Interpretace je pak snadná, velikost přenosů za určitý čas nám pomůže určit, jestli jsme na hranici výkonnosti daného zařízení. Počet jednotlivých zápisů a čtení nám pak řekne, jak konkrétní vytížení ve skutečnosti vypadá. A konečně délka fronty nám naznačí, jak se systém se zátěží vyrovnává – jako jediná hodnota by se tato měla blížit k nule.

Ukázky grafické interpretace

Asi nejlépe jsou hodnoty vidět, když jsou v závislosti na čase vykresleny na grafu. Samotné grafy by nebyl problém vytvořit ručně periodickým čtením souboru /proc/diskstats, ale rovnou se nabízí použít některý monitorovací nástroj, například:

• collectd
• Dstat
• Munin
• Zabbix
• Cacti

Prakticky

Nástrojů, které umožňují monitorovat diskovou zátěž je celá řada. Jako nejlepší řešení se po dlouhém hledání ukázal Munin rozšířený o plugin linux_diskstats (v Debian Squeeze už bude přímo v distribuci, v upstreamu byl Muninu zařazen do hlavní větve) a současně bez všech ostatních pluginů, které nejsou relevantní. S Muninem se můžete seznámit v souvisejícím článku Munin – monitorování serverů.

Instalace je pak jednoduchá – na uzlech, kde budeme měřit výkon, nainstalujeme munin-node, v konfiguračním souboru povolíme přístup pro server, odstraníme všechny pluginy kromě df, df_inode, iostat, load, open_files, open_inodes a vmstat a přidáme linux_diskstat s (nejlépe pomocí munin-node-configure --shell přímo pro konkrétní blokové zařízení).

Výstup pak bude podobný ukázce na demo serveru.

Závěr

Na základě zjištěných statistik bychom měli mít jasný obrázek, jak je na tom náš spravovaný systém s I/O výkonem; s předstihem tak zvládneme naplánovat potřebné posílení diskového pole (obecně disky s více otáčkami za minutu jsou rychlejší, stejně tak větší počet zařízení může pole zrychlit) a budeme znát specifika obvyklé zátěže.