Hirdetés

  2. Fórumok
  3. Adattárolás
  4. RAID

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

  • #2881 janos666 nagyúr
    Új Válasz #2881
    Ú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

    janos666

    nagyúr

    Nos, két dologra jöttem ma rá:

    A HD-Tune teljesen alkalmatlan stripe-size tesztelésére, de főként az alloccation unit-éra, mert egy összefüggő kötetként megy végig a RAID-tömbön, nem is érdekli hogy van-e rajta partíció, valamint szinte ugyanazt az eredményt kaptam min-max-average speedre és acces timera is minden stripe sizevel (4K és 128K közt), csak a CPU-utilization változott és tűnt értékelhetőnek, de mértékadónak ezt sem nevezném.

    A fontosabb felfedezésem hogy a HD-Tune benchmark szerint rengeteget dob a sebességen (főleg a stripe-sizenél kissebb csomagokkal való tesztnél) ha a matrix storage managerben bekapcsolom a kötetszintű visszaírási gyorsítótárat, de másolgatós-stopperelős tesztem szerint majdnem másfélszeresen lassítja a kötetet! (talán nem véletlenül van alapértelmezésben kikapcsolva)

    Miután a benchmarkról lemondtam a fixált rendszerkötetemen összekészítettem magamnak egy mappát egy 700Mb-os AVI-val, 3 MP3 albummal és a windows könyvtárból méret szerinti kereséssel összehalászott apró fileokkal. Ezt többféle stripesizevel kreált és stripesizevel megegyező, vagy ha volt rá lehetőség (64K-ig) akkor annak kétszeresére vett foglalási egységgel formázott kötetre másoltam és ott duplikáltam miközben lemértem az időt stoperrel és néztem a taskmanagerben a CPU terhelést.

    Végül arra jutottam hogy 4K-s stripe sizenek állítottam be az egész tárkapacitást és 4K-s fe-vel formázom. Miért?

    A duplikálgatós teszt szerint koránt sem kell annyira félni a CPU használtattól mint a HD-tune mérésében, de ott is 20% volt a csúcs úgy hogy csak 1 magot használt a 2-ből, ez szerintem csúcsértéknek belefér a keretbe (ha 1000-rel ír a winyóra akkor úgyse nyúzza a program a CPU-t, ha meg a CPU-t nyúzza 1000-rel akkor nem akar a winyóra is veszettül írogatni mert gondolkodik mit kell írni...) Ezzel kár foglalkozni a stripe-size eldöntésekor.

    A vegyes méretűre válogatott mappám duplikálásakor eltelt idő stopperrel való mérése nem a legpontosabb, de nekem megtette a ~10ms pontosság is, főként hogy alig volt különbség a mérések közt, tehát gyakorlatilag másolás sebességben sincs nagy különbség stripe size kapcsán. A 4K és a 128K néhány század másodperccel elmaradt a 16K-s mellett (neten keresgélve is olvastam hogy 16K lehet a nyerő), de 4K sem volt számottevően lassabb, így valós életbeli sok véletlenszerű ide-oda írogatást-olvasgatást is feltételezve iskább bíztam a gépet 4K-s stripera.

    Az foglalási egység pedig stopperrel kimérhetetlen változást hozott duplikáláskor, a fent említett indokkal (esetleges sok random read) inkább 4K-ra tettem az fe-t is.

    Az align-al próbálkoztam és 4K-ra is lehetett volna tenni, de a biztonság kedvéért 64K-val igazítottam a partíciókat (ezt már nem teszteltem ki, de elvileg a stripezize felett minden páros szám jó, mely egész számú többszöröse a 8-nak, a default meg 63...)

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