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 |
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.
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
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?