Administrace komentářů

No právě - brzdit by to nemělo, a to ani při krásné sekvenční zátěži, na které prakticky není co optimalizovat Tam by měl být vliv NCQ cca nulový.
Na čem by měl být vidět přínos NCQ? Na směsi náhodných zápisů a snad náhodného čtení (nejlépe ve více vláknech). A spíš než podle subjektivního dojmu v jednom konkrétním vlákně by se to mělo hodnotit podle agregátní průchodnosti měřené v IOps (třeba utilitou iostat z balíku sysstat). Nebo časem na dokončení nějaké dávkové úlohy / benchmarku. Když se podpora NCQ v Linuxu objevila, doprovodné komentáře v LKML tuším zmiňovaly urychlení kompilace jádra o nějaké desítky procent. Dovedu si představit, že by rychleji mohla běhat databázová zátěž ve stylu write-mostly, nebo i s vysokým podílem čtení, ale v mnoha vláknech.

Čtení s asynchronním dokončením =neblokující už Linux umí, ale zatím není mnoho aplikací, které by ho používaly - vlákno obvykle čeká na návrat funkce read() apod., než podá další požadavek. Kdežto při zápisu se uplatňuje systémový write-back buffering, takže tam není problém mít naráz ve frontě mnoho požadavků.

Mám takový svůj testovací prográmek, který umí generovat náhodnou zátěž na úrovni blokového zařízení. By default jenom čte, ale dá se mu říct, aby i zapisoval - pak je ovšem destruktivní k datům (zničí na disku filesystém). Když čte, tak blokujícím způsobem => jedním vláknem nic neotestujete. Náhodný zápis, to je jiné kafe - pokud na disku nemáte zatím data.

Pak si vzpomínám na benchmark Bonnie++2, který benchmarkuje především filesystém. Protože jede nad filesystémem, není destruktivní ke stávajícím datům, přestože i zapisuje (vytváří si k tomu své vlastní soubory). Konkrétně specialitou tohoto prográmku je sadistický benchmark na vytváření a rušení velikého množství souborů a adresářů, který způsobuje velmi zajímavý mix náhodných transakcí na blokové vrstvě. Nejlíp když ho pustíte párkrát paralelně ve dvou či více adresářích. Bohužel v dobách, kdy jsem si s ním hrál (2.6.18 - 2.6.24) měl pod Linuxem drobnou nectnost: dokázal dostat do kolen většinu filesystémů, se kterými jsem si v té době hrál. Vybavuji si Ext3 a XFS. Při spuštění nad Ext3 se stávalo, že operační systém zahnil zajímavým způsobem - běžící programy v zásadě reagovaly, ale jenom do chvíle, kdy jste program ukončil a měl se vrátit shell (bash). V tu chvíli konzole umřela a už to nešlo vyprostit. Totéž při pokusu spustit další program z shellu. Přitom iostat ukazoval 0 Tps. Jediný FS, který to vždycky přežil, byl Reiser 3. Dneska už je doba někde jinde, aspoň doufám...

Nějaký základní bencmark disku umí provést tuším taky HDPARM.

Je zajímavé sledovat, jak různé disky "škálují" IOps podle toho, jak moc dobře jim řadíte náhodné transakce výtahovým algoritmem - tzn. nakolik blízko sebe transakce jsou. Některým diskům to jde výborně (Velociraptor, Cheetah), jiným to moc nejde (desktopové disky). Vlastně jsem o tom už něco napsal... Dá se třeba ladit hloubka fronty v OS, dá se taky použít "short stroking" na disku - tzn. omezit zátěž na nějaký oddíl (podmnožinu) celého povrchu disku.

Pokud jsem schopen posoudit, tak při dokonale náhodném seekování nemá fronta o hloubce 32 transakcí příliš velký vliv. U externích RAIDů na SCSI mívalo smysl zvětšit hloubku fronty na hostitelském HBA v serveru až na 128-256 transakcí. Každopádně hostitelský operační systém má mnohem víc RAMky a lze ho vyladit na ještě mnohem větší hloubku fronty (i když je to vždycky "něco za něco" a Linux není v této oblasti úplně tou největší hvězdou).
Kouzlo NCQ uvnitř disku by mohlo spočívat třeba v tom, že disk zná přesnou fyzickou geometrii a umí inteligentně řadit "lokálně rozházené" transakce tak, aby minimalizoval rotační latenci - tzn. skákat mezi blízkými stopami v rámci jedné otáčky - tzn. optimální pořadí nemusí odpovídat prostému seřazení seeků podle vnějších LBA adres. Jinak si myslím, že NCQ může mít nějaký vliv spíš u operačních systémů, které samy nedokážou seeky dost dobře optimalizovat. Teoreticky by mohlo být přínosem také obejdení latence "dotaz-odpověď", která vynikne bez použití TCQ/NCQ - vedle přenosových zpoždění může jít také o manipulaci s transakcemi na straně disku i hostitele, to všechno se bez TCQ/NCQ serializuje. Netuším, kolik tato "manipulační latence" činí, a dost možná se bude lišit u různých kategorií disků.