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:

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čů

scheduler tps prumer tps pomer vykonu %
deadline 1507 1598 1558 1519 1626.00 100.00
noop 1549 1595 1573 1562 1569.75 96.54
anticipatory 1498 1503 1476 1502 1494.75 91.93
cfq 1400 1430 1446 1429 1426.25 87.72

Poměr výkonu PostgreSQL v závislosti na plánovači

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.

Příspěvek byl publikován v rubrice CentOS, Linux, PostgreSQL, RAID. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

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

  1. Martin napsal:

    Ahoj,

    Jestli máš naměřené hodnoty scheduleru deadline v tabulce správně, máš špatně vypočítaný průměr tps. Napsaný máš 1626 ale průměr z naměřených dat je 1545,5. Takže by to znamenalo, že deadline se posune na druhé místo a nejrychlejší bude scheduler noop s průměrem 1569.75 tps.

    Jinak můžu potvrdit, že nasazení deadline scheduleru na velmi vytížených serverech (Debian Etch, Lenny, Squeeze) sníží load systému a nedochází k pádům(například při každodenním nočním zálohování 50 až 100GB) jako s schedulerem sfq, kdy docházelo k tomu, že se systémem nebylo možné vůbec pracovat, load systému v aplikaci htop ukázal klidně i několik tisíc a server odpadl kvůli nedostatku paměti (měl jí 8GB + 10GB Swap).
    Ovšem změna scheduleru byla v těchto případech jen dočasným řešením. Bylo nutné klasický systémový(é) disk SAS či SATA vyměnit za SSD, potom už problémy se odezvami nebyly :o)

    • Heron napsal:

      Ahoj

      Kurnik, máš pravdu. Netuším, kde ta chyba mohla vzniknout, celé je to z Calcu (včetně funkcí).

      Jaké máš zkušenosti se SSD jako serverovým diskem?

  2. Martin napsal:

    No s SSD disky mám zkušenosti takové jak píši v předchozím příspěvku. Když už je server zahlcen požadavky na zápis/čtení a harddisk je nestíhá obsluhovat, hromadí se tyto požadavky ve frontě a roste LOAD systému :-(. Pak je většinou nutné nahradit stávající rychlostně nedostačující SATA, SAS či SCSI disky SSD disky(většinou vše v hardwarovém či softwarovém RAID 1). Zatím jsem takto musel postupovat asi u 15 serverů. Jednou byl použit SSD OCZ Vertex 2 Series 240GB, na jedné instalaci byl použit Intel SSD 710 – 200GB a na všech ostatních Intel SSD 510.
    Pokud se server předtím jen líně plazil, po změně na SSD letěl jako střela!
    Nevím jak je to s problémy s SSD(blue screen) u Widlí, ale pod Linuxem jsem ještě žádný problém(s chybami či s nekompatibilitou) nezaznamenal a SSD disky běží v serverech 24x7x365(řídících metropolitní sítě) již více než rok…

Komentáře nejsou povoleny.