Dotaz: saturace disku

[chtel_bych_se_zeptat]

Dobry den, chci si napsat maly skriptik, ktery me upozorni, jestlize bude nejaky z mych disku na serveru saturovany.

Chci se zeptat, jestli si myslite ze sledovani hodnoty %util z outputu "iostat -x" je pro tento ucel vhodne. Vim ze asi neni uplne nejstastnejsi predpokladat, ze zarizeni ktere je vyuzito na 100% je automaticky saturovane, ale pokud k tomu pridam nejakou casovou hodnotu - napr. velmi obecne, disk je busy na 100%, 5x checku po sobe = velmi velka pravdepodobnost, ze disk nestiha.

Predem dekuji za vsechny vase nazory. :)

Odpovědi

[Kolega]

Icinga pouziva check_iostats https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#iostats

[majales]

Sice je to pro vás asi kanón na vrabce, ale co takhle icinga2 a check_iostats nebo alespoň munin?

[dustin]

Když na disk budeš kopírovat něco většího z něčeho rychlejšího (nebo v opačném směru), pojede vždy naplno, ne? Klidně i hodinu v kuse, když to bude něco velkého.

[j]

Ani ve snu, linearni zapis/cteni generuje mizivou zatez.

[dustin]

Zápis i čtení souborů z filesystému není lineární přístup na médium. Na serveru se to navíc ještě namíchá strukturou raidu.

[dustin]

Samozřejmě mluvím o saturaci IOPS.

[j]

"Když na disk budeš kopírovat něco většího..."

Tak se vse co je v ceste od samotnyho disku az po system snazi sec muze z toho linearni cteni/zapis udelat. (mimochodem, tohle je jeden z duvodu, proc komercni pole pouzivaji disky s vlastnim firmwarem, aby to pole melo kontrolu nad tim, co se deje)

Typicky mnohem vetsi zatizeni generuje provoz databazi, protoze tam se jaksi neda moc predikovat, co se bude cist priste, nebo kam se bude priste zapisovat. Ostatne i kazdej bench ma random RW testy, ktery kupodivu podavaji vzdy mnohem horsi vysledky (a to i na SSD) nez prosty cteni nebo zapis nejakyho souboru.

[Peter Golis]

Pokiaľ sa minie SLC cache na TLC disku, tak výkon môže zletieť do priepasti. A aj zletí.

[j]

Na to nemusis mit ani zadnou cache, i linearni RW v ramce bude vykazovat podstatne vyssi prenosovy rychlosti, nez random. Jednoduse proto, ze ten "seek" nema nikdy nulovej vliv.

Rozdil je jen v tom, kolik seeku za sekundu ta ktera technologie zvladne. A to je vpodsate presne to, cemu se rika IOps. Akorat ze jako ve vsem (kapacita a MB neni jako MB), se i v tomhle vyrobci naucili velmi rychle podvadet. Takze zarimco u SAS disku bude uvedena "smesne nizka" stredni hodnota, u vetsiny sata disku (specielne samsung) hodnota maximalni. Ta stredni pak bude klidne o rad nizssi nez u toho sasu.

Proto se hromada tupcu strasne divi, kdyz jim SSDcko pod zatezi dava 20MB/s.

[Peter Golis]

Mne to kleslo na cca 33MB/s (264Mb/s) pri SSD ktorý papierovo zvládal zápis 500 MB/s. Trochu som si o tom µBlogol. Ale nedivil som sa tomu, ten disk som mal akoby zdarma. Skôr som sa divil že čo majú ľudia v tej mantre SSD a kadejaké NVMe. Divil som sa tomu aj pri nástupe SSD, keď žrali viac elektriky ako rotačné disky. A to sa pri notebookoch veľmi oplatilo.

[j]

Tool mas spravnej, a to co z toho chces jsou IOps. 15k disk umi (v nejlepsim pripade) 200. Ruzny pole se pak chovaji ruzne. Trebas mirror dvou disku ti je schopen dodat 400 na cteni, ale zapis ma porad jen 200. Atd.

Samo pomalejsi disky davaji min, kolik konkretne daji tvoje si muzes overit nejakym benchmarkem a vychazet z tech cisel.

Prakticky kazdej tool na sledovani ma zrovne tohle implementovany, ale pokud chces vazne jen tohle, tak nema smysl neco takovyho provozovat => ten script postaci, a muzes si to tim scriptem klidne ladovat do nejaky ty rrd* databaze a potazmo si z toho pak primitivne vygenerovat nejaky grafy.

*Pokud nevis jak to funguje, tak se deklaruje kolik hodnot si to ma jak dlouho pamatovat, a dal kolik trebas hodinovych prumeru, dennich prumeru atd. Tzn nepamatuje si to vsechny hodnoty za existenci sveta, ale postupne se stary prepisujou novejma a v delsich usecich se pak uz nepracuje s puvodnima hodnotama vubec. Ty pocitany hodnoty nemusi byt samo jenom prumer, muze to byt cokoli si prejes a muze jich byt v ramci casovy jednotky i vic (muzes si schovavat denni prumer + maximum a minimum trebas).

A samo, z takovy databaze se da vysat trebas "poslednich 5 hodnot" a neco na zaklade toho udelat.

Tuhle: https://oss.oetiker.ch/rrdtool/

[chtel_bych_se_zeptat]

Ahoj, IOps zni dobre, ale co kdyz mam situaci, ve ktere presne nevim, co je cilovy disk zac - treba pri nasazeni scriptu na vice serveru, kdy si jednotlive disky nactu z /proc/diskstats a pak je chci dale sledovat.

To bych je musel vzdy podrobit nejakem vstupnimu stress testu, abych vedel co z nich vymacknu a dostal nejakou dalsi hodnotu k porovnavani - nebo se pletu?

Jak tak koukam na ten /proc/diskstats, tak tam vidim hodnoty jako "cas straveny ctenim dat", "cas straveny zapisem dat", "pocet dokoncenych ctecich operaci", "pocet dokoncenych zapisu dat" Zajimalo by me, jestli by se bud z techto hodnot (a nebo jinych v tomto souboru) nedalo odovodit, kdy je disk pomaly a nestiha.

Taky si rikam, ze kdyz ten disk nestiha, tak se nekde ty operace musi radit do nejake fronty (fronta blokoveho zariceni?), nedala by se nejak sledovat?

Predem moc diky vsem za dalsi uzitecne informace :)

[Heron]

Různé checky už doporučili ostatní, tohle umí v podstatě každý monitorovací nástroj.

Ale jde o to, proč to chcete kontrolovat a čeho tím chcete dosáhnout. Jestli vám jde o pouhou kontrolu toho, jak jsou vytížené disky, tak ok. Pokud tím sledujete nějaký optimalizační cíl, tak tato hodnota toho zase tak příliš neříká. Linux má ionice, kterým lze nastavovat procesům různé priority diskových operací, takže když nějaké dlouhotrvající a na disk náročné úloze nastavíte idle, tak disk sice bude hodiny vytížen na 100%, ale v zásadě to žádnému dalšímu procesu nebude vadit. Dalším kamínkem do mozaiky je io scheduler. Výchozí je CFQ, který je obecně asi nejlepší, ale pro některé provozy se více hodí deadline nebo třeba i noop.

Obecně je vhodnější sledovat latence pro vás důležitých operací. (Tohle platí nejen u disku.)

[Andrej]

r_await a w_await vypovídají o "saturaci" možná lépe než nějaký odhad v procentech.

Neříkají ovšem příliš přesně, jak velký má tahle "saturace" celkový vliv na výkon systému. K tomu je nejlepší vážit hodnoty r_await a w_await hodnotami r/s a w/s. Tím se dá získat odhad ve stylu "jak dlouho celkově tento disk v nedávné době zdržoval systém".

Celý takový odhad je samozřejmě relativní, tj. má smysl při porovnání mezi jednotlivými disky a hledání disku, který výrazně převyšuje ostatní. Není to magický údaj v procentech (s definicí 100% kdovíkde).

[Max]

Jak už napsal andrej, měření iops, či toku dat nic neřeší. Tam se vytížení disku nepozná. To se až pozná na latencích, což je právě ono sledování "r_await" a "w_await".
Zdar Max