Dotaz: RPM disku a I/O

[Jura Jurátor]

Dobfý den,

řeším pro kolegu toto:

Můžeme koupit disk 1,2 GiB ale otáčky jsou 5000/sec

nebo

600 Gib disk, ale otáčky jsou 1700/sec

Obojí disky mají I/O GiB/sec

myslím, že oba disky budou stejně rychlé co se týče zápis/čtení, ale ten s 1700ot/sec bude mít menší životnost a větší spotřebu energie. Ale na rychlosti práci virtuálky se to nepodepíše.

Zdraví

Jirka

Odpovědi

[Příchozí]

to jsou nějaké ďábelské disky, když mají 1700 otáček/s já jsem zvyklej na 7200 nebo 14400 otáček/m druhá věc, stejně rychlé při zápisu a čtení možná budou, ale IOPS budou mít uričtě jiné. Do normálních serverů se nic jiného než 7200 nedává. Pokud je to na data, tak klidně 5400 a klidně i míň otáček.

[Jura Jurátor]

Děkuji za odpověď

Omlouvám se, psal jsem to z hlavy máte pravdu ty otáčky jsou 7200 a cca 15000.

Tedy vyšší než jsem psal ale relativní poměr rychlosti zachován.

Měly by na tom běžet virtuálky obojí to má napsané I/O MiB. Tak nevím jak je to možné, že i při rozdílných otáčkách mají stejné I/O. Vysvětluji si to tím, že pravděpodobně ten větší a pomalejší, co se týče otáček, je novější typ (jedná se o starší server) a má lepší technologii zápisu (řadič disku ?, Frimware ?, jiný typ zápisu ? či kombinace všeho) a tak je rychlejší.

Zdraví

Jirka

[Příchozí]

No, nejlepší je semka hodit, co to je za disky ;) obecně 15k disky mají vyšší IOps. V zápisu/čtení bývají skoro stejné (rozhodně tam není 2x vyšší rychlost zápisu). Ale určitě hraje roli i stáří disku.

[lertimir]

Motáte dohromady dvě věci.

IOPS je množství elementárních operací s diskem. To přímo souvisí s rychlostí otáčení. Protože když data, která minou při otáčce místo, kde by mohla být hlavička a ještě není, tak se musí počkat než se otáčka dokončí a data znovu budou u hlavičky. V podstatě IOPS = 1/seek_time.

Rychlosti přenosu na druhou stranu popisují kontinuální datový tok, když hlava pořád čte (nebo píše). Obecně platí, že rychlejší disky jsou o dost méně kapacitní (hlavně díky tomu, že jsou menší na poloměru, a trochu i s menší hustotou) a proto na jednu otážku přečtou méně dat, ale doženou to více otáčkami.

[Jendа]

IOPS je množství elementárních operací s diskem. To přímo souvisí s rychlostí otáčení. Protože když data, která minou při otáčce místo, kde by mohla být hlavička a ještě není, tak se musí počkat než se otáčka dokončí a data znovu budou u hlavičky. V podstatě IOPS = 1/seek_time.

Ane. Moderní řadiče a operační systémy umí NCQ, operací tak může být i několikanásobně víc.

[Heron]

NCQ a elevatory jsou pouze techniky optimalizace pořadí diskových operací. S IOPS disku to nemá nic společného, IOPS by měla být hodnota náhodného zápisu / čtení daného zařízení.

Protože on ten moderní řadič má (může mít) i bateriově zálohovanou cache a když se data vlezou do cache, tak IOPS (třeba s 4K bloky, což jsou fyzické bloky daného disku) může vystřelit na stovky tisíc, což jistě dané zařízení nemá. Osobně NCQ v diskách považuji za marketing, u os s vhodným io schedulerem může situaci dokonce zhoršit (aneb OS ví lépe než firmware disku, kam dřív sáhnout).

[Jendа]

OK, asi mám nestandardní aplikaci. Mně zajímalo „tady mám 16320 pseudonáhodných adres na disku a chci mít v paměti co nejrychleji 4K bloky, které na těch adresách začínají, a je mi jedno, v jakém pořadí se tam naskládají“ a s tím mi NCQ velice pomohlo. A myslím, že i vytížený server určitě zpracovává víc požadavků paralelně a může je dát do NCQ fronty.

IOPS by měla být hodnota náhodného zápisu / čtení daného zařízení.

Hm, hm. Jenže bez paralelního NCQ-like frontování nevymlátíš rozumný výkon ani ze SSD - mně to dalo asi 5k IOPS, s NCQ to dá 10x tolik (řadič ATI SB7x0/SB8x0/SB9x0, SSD nějaká ADATA).

[anonym]

Jenže bez paralelního NCQ-like frontování nevymlátíš rozumný výkon ani ze SSD

tady nejde uplne o NCQ, ale vubec o frontu. SSD by melo byt jedno kde jsou data co cte (pokud nejsou v ramci jedne stranky, ale to by mel zmergovat uz OS). naopak cekani az OS pripravi dalsi pozadavek muze dost zdrzovat

pozor na to ze NCQ neni o tom ze disk ma frontu pozadavku, ale o tom ze si je v te fronte sam prehazuje jak se mu zlibi. ve svete SCSI tohle umime uz davno a lepe, jenom na ATA to uplne nefungovalo

[lertimir]

To jedině, když data jsou hodně blízko na stopách. Jedny z nejrychlejších disků 15k Cheetah (15k za minutu je 250 ot za vteřinu tedy 4ms na otáčku) mají average seektime rovný času jedné otáčky a full stroke (což je tedy doufám od nejmenší stopy k nejdelší mají přes 6ms pro read a více než 7ms pro write (strana 11). Tedy čas, který hlavy potřebují pro přenastavení polohy je srovnatelný s jednou otáčkou. A u levnějších disků budou hlavy ještě významně pomalejší. Přece jen se hlavy nastavují s přesností tuším cca 1/5 vlnové délky viditelného světla nad povrchem, který se pohybuje se rychlostí asi 4m/s. Pokud jsou disky levnějších kategorií, (nemluvě o notebook disku) mechanismus nastavení je ještě pomalejší. Pro data v různých trackách, žádné NCQ nepomůže. A vzhledem k tomu, jaké čísla mají všechny cheety pro track-to-track, (což je nemožný čas pro náhodné získání dat z vedlejší stopy v tom případě by musel být polovina rotační prodlevy) je podle mne average seek time průměrný čas pro nastavení hlav na cílovou stopu, ne pro čtení dat.