Új hozzászólás Aktív témák

• #5217 Sunzi aktív tag fLeSs #5216

  Új Válasz 2010-03-30 17:06:18 #5217

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sunzi

  aktív tag

  válasz fLeSs #5216 üzenetére

  Nem egészen szerencsés elmélet.
  Ekkor ugyanis minden esetben több diszk fog egyszerre pozícionálni, és IO műveletet végezni.
  Ha tfh csak 1 clusternyi adat kell, 1 seek time mindenképp van, átlagosan addigra a másik diszk is odapozícionált, majd majdnem egyszerre kiolvassák az adatokat. (de, mindenképp igénybe vettünk 2 seek időt, ezt Neked nem kell elemeznem, mit jelent..)
  Ellenben, ha a cluster kisebb, vagy egyenlő, akkor van ugyanannyi seek time, a dupla hosszúságú beolvasás 1 IO- belül elfér, és nem mérhetően lassab, mindeközben a másik diszk ezzel egyidőben képes párhuzamosan egy másik műveletet végezni, pl. 1 ehhez hasonlót. Egyértelműen ez utóbbi megoldás a gyorsabb.
  Az én javaslatom a stripe size=cluster size megoldás. Illetve a cluster ugye max 64k windows alatt, tehát stripe>=cluster a helyes képlet.
  A túl kicsi stripe (2-8k pl.) viszont túl sok IO-t jelent, az sem mindenhol szerencsés.
  Ha pl. nincs párhuzamosítható IO, akkor a raid vezérlő sem tudja párhuzamosan hajtani a diszkekek, tehát az én javaslatom nem jelent jelentős gyorsulást, de lassulást sem.

  És akkor még nem firtattuk, hogy mi van melyik esetben mondjuk random read-nél, ahol ez a javaslat sikeresen hozza majd 1 diszk sebességét IO/sec számban
  Neked gondolom nem új, de az otthoni felhasználást leszámítva "elvileg" a szerver pontos igénybevétele dönti el, hogy ezeket hogyan konfiguráljuk, ez esteben ugyanis egy adott tömbön behatárolható, hogy milyen jellegű IO pattern várható.

  Otthonra meg nincs ideális beállítás. Max tesztekhez optimalizálás.... meg a windows boot ahogy hallom...

Új hozzászólás Aktív témák