Měření diskového výkonu v závislosti na nastavení kernel scheduleru

Přetížil se mi server IO požadavky. Už podruhé. Chtěl jsem po něm docela obyčejnou věc. Asi 5 paralelních IO požadavků různé povahy (4x čtení a 1x zápis). Skripty pro převod obrázků, samba nad RAID5 diskovým polem a iSCSI target nad samostatným diskem. Tedy, ne že by ty IO nevyřizoval vůbec, to zase jo. Na terminál reagoval, ovšem příkaz kill načítal několik desítek sekund.Odpovědnost za plánování IO má kdo jiný, než plánovač (elevator). CentOS 5.5 nabízí 4:

• deadline
• noop
• anticipatory
• cfq

Poslední jmenovaný je výchozím plánovačem. Postupně jsem je otestoval standardním testem pgbench pro PostgreSQL server.

Podmínky testů

• HW: Intel(R) Core(TM)2 CPU 6320; 8GB DDR2-800; HDD SAMSUNG HD103UJ
• SW: CentOS 5.5 64b (2.6.18-194.11.1.el5.centos.plus); postgresql-8.4.4
• FS: Vyladěný XFS
• Test byl spuštěn 4x, výsledky zprůměrovány.

Testovací skript

Inicializace DB pro test a nastavení plánovače pro disk nesoucí soubory DB:

# deadline, noop, anticipatory, cfq
echo "deadline" > /sys/block/sda/queue/scheduler
pgbench -i -s 10; sync

Test samotný, vždy 4x:

pgbench  -c 64 -M prepared -t 1000

Výsledky testů plánovačů

Test tedy vyhrál plánovač deadline. Výchozí plánovač v CentOSu a dalších distribucí Linux, cfq dopadl nejhůře s výkonem o 13% nižším.

Změna výchozího plánovače

Plánovač lze změnit kdykoliv za běhu a může být pro každé blokové zařízení jiné. Změna se provede prostým zapsáním do souboru ve speciálním systému souborů /sys. Například pro disk sda a plánovač deadline:

echo "deadline" > /sys/block/sda/queue/scheduler

Aktivní plánovač a seznam dostupných lze získat jednoduše přečtením souboru scheduler:

cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq

Aktuální plánovač je vypsán v hranatých závorkách.

Takto provedená změna ovšem není trvalá, tu lze nastavit v parametrech jádra. V souboru /etc/grub/grub.conf, plánovač se zde uvádí jako parametr elevator:

kernel /vmlinuz-2.6.18-194.11.1.el5 ro root=/dev/system/root elevator=deadline

Pokud chceme použít pro každé blokové zařízení jiný plánovač (každý se hodí na jiný typ pracovní zátěže), je možné dát jejich nastavení např. do /etc/rc.d/rc.local.

Závěr

Ale zpět k problému. Výchozí plánovač se snaží být fér (Completely Fair Queuing — zcela spravedlivý plánovač), bohužel tak moc, že zcela zablokuje přístup k disku. Zatímco plánovač deadline přidělí každému IO požadavku určitý čas, pak se věnuje dalšímu požadavku ve frontě a tak dále (samozřejmě s optimalizací pro minimální seek). Tedy se každý požadavek nakonec dostane ke slovu a bude vyřizován poměrně dlouho (ve výchozím nastavení 500ms, za tuto dobu lze na moderním disku přečíst i několik desítek MB dat).

Systém se chová o poznání předvídatelněji. Při pěti požadavcích je práce s diskem samozřejmě pomalá, ale každý program se k němu nakonec dostane.