[RAID-5] na 3xWD Green 2TB - wolny odczyt, szybki zapis

[premiero]

Witajcie. Mam problem z moim raidem na Platform Controller Hub (PCH).

 

Konfiguracja:

Asus Z87-Pro

i7-4770K

16GB RAM

RAID-5 na 3xWD20EURX

 

Przeczytałem chyba gazylion stron na temat konfiguracji i optymalizacji RAID-5, i chociaż wszędzie piszą olać RAID5, dołożyć dysk i zrobić 10, to ja mam tylko 3 dyski i zależy mi aby mieć zabezpieczenie danych.

Początkowo nieświadomie utworzyłem Volumin ze stripem 128k. W połączeniu z klastrem 4k dało to opłakane rezultaty w crystal marku - około 50 MB/s odczyt, zapis około 40 MB/s. Masakra. Oczywiście kopiowanie dużych plików śmigało nawet nawet (transfery rzędu 100 MB/s) ale daleko to było od moich oczekiwań. Natomiast kopiowanie małych plików, to już była tragedia - od 300kB/s do około 6Mb/s.

 

Poświęciłem więc mnóstwo czasu, wyczyściłem cały wolumin i zacząłem tworzyć po kolei różne kombinacje. Do tej pory przetestowałem:

16k stripe / 4k cluster

16k stripe / 8k cluster

16k stripe / 16k cluster

16k stripe / 32k cluster

16k stripe / 64k cluster

64k stripe / 4k cluster

64k stripe / 8k cluster

64k stripe / 16k cluster

64k stripe / 32k cluster

64k stripe / 64k cluster

128k stripe / 4k cluster

 

Idzie to jak krew z nosa, bo inicjalizowanie trwa około doby. Dla świętego spokoju przetestuję jeszcze warianty 32k i 128k

 

Najlepsze wyniki w CrystalMarku na razie uzyskałem na konfiguracji 64k stripe / 64 cluster, ale za każdym razem zapis wychodzi szybszy niż odczyt. Wychodzi mi więc odwrotnie za każdym razem niż większości użytkowników, którzy narzekają na wolny zapis RAID-5 a szybki odczyt. Przykładowo przy konfiguracji 64stripe/64cluster sekwencyjny odczyt 150MB/s, zapis 270MB/s (dodam że włączenie w Intel RST opcji "opóźniony zapis" powoduje spowolnienie zapisu, gdzie teoretycznie powinno przyspieszyć!)

 

Na razie nie wiem w czym jest problem.

1. Czy to problem WD-ków, bo już znalazłem w necie wątek VERY slow RAID5 on ICH10R with WDC Green series, ale tak na prawdę z niego nic nie wynika i problem dotyczy zapisu a nie odczytu i innego chipsetu.

2. A może to problem z Option ROM-em płyty głównej? Choć nie jestem pewny do końca jak to działa, bo wydaje mi się że Option ROM ma znaczenie tylko do momentu załadowania sterowników w systemie operacyjnym (mój driver to 13.​1.​0.​1058, natomiast wersja w BIOS-ie płyty głównej to zdaje się 12.7.0.1963)

3. A może CrystalMark daje [gluteus maximus]? Bo test HDD  z AIDY przy liniowym odczycie pokazuje inne wartości (dużo wyższe)

 

Co ciekawe, robiłem też testy podczas inicjalizacji woluminu, i o ile zapis rzeczywiście notuje drastyczny spadek, o tyle odczyt nie zmienia się praktycznie wcale.

 

Jeśli nic mi się nie uda zrobić, to chyba będę musiał rozważyć opcję SSD-cache dla RAID-5, tylko nie wiem jak ona miałaby mi przyspieszyć odczyt? Jak wrócę do chaty, to wrzucę screeny z CrystalMarka dla każdej konfiguracji, może przyda się dla potomnych walczących z doborem rozmiaru paska vs klastra, bo tutaj ewidentnie widać zależności, natomiast problem ogólnego wolnego odczytu dla mnie na razie pozostaje nierozwiązany.

 

Jeśli macie jakieś sugestie, bardzo proszę, jestem otwarty na nowe rozważania. Może ktoś z was ma u siebie RAID-5 na 3-ech dyskach i podzieliłby się wynikami z CrystalMArka?

 

Znalazłem jeszcze jedną ciekawą informację odnośnie dopasowania pod względem podzielności:

1. Partition offset (in kb) / stripe unit size(in kb) = integer
2. Stripe unit size(in kb) / File allocation size(in kb) = integer.
3. For 4K sector drives: Partition offset (in kb) / 4K = integer (this is usually meet when satisfying rule 2 above)

Muszę sprawdzić jak to u mnie wychodzi.

 

Sprawdziłem, jest ok. Partition offset wynosi 135266304 bajty = 132096 kilobajtów jest podzielne przez 128k (stripe) w całości, więc dla każdego niższego warunku (64,32,16,8,4) również będzie liczbą całkowitą. Tak na marginesie, ta reguła wcale nie potwierdza się w testach, co można zobaczyć niżej (przykład 16k stripe/64 cluster = 0,25 a daje lepsze wyniki niż 16k/16k = 1.)

Edytowane 16 Lipca 2014 przez premiero

[premiero]

Obiecane zrzuty:

 

Na początek pojedynczy dysk, odpowiednio 0%, 42%, 88% zapełnienia.

 

A tu benchmarki z RAID-5 3xHDD WD20EURX, odpowiednio:

 

ROZMIAR STRIPE | ROZMIAR CLUSTRA

 

Stripe 16k - | Inicjalizacja 4k | 4k | 8k | 16k | 32k | 64k |

 

Stripe 32k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k | 64k WriteBack ON |

 

Stripe 64k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k |

 

Stripe 128k - | Inicjalizacja 64k | 4k | 8k | 16k | 32k | 64k |

 

 

Dodatkowo wrzucam testy:

RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [Write Back Cache Enabled]

W porównaniu do Cache'u wyłączonego widać spadek wydajności przy zapisie 512k a zapis 4k dostał 4 krotnego boosta. Reszta porównywalnie, zostawiam opcję WYŁĄCZONĄ.

 

A tutaj zrzut z AIDY dla 64k/64k Cache Write Back wyłączony.

 

Wygląda to lepiej niż w CrystalMarku. Zrobiłem również Linear Read i Linear Write test i tam również wyniki oscylują na początku dysku w granicach ~ 270MB/s dla odczytu/zapisu.

 

______________

A tutaj screeny przy wykorzystaniu funkcji Intel Smart Response (SSD Cache).

Do tego celu użyłem dysku SSD Kingoston SH103S3120G 120 GB, na którym miałem system operacyjny. Ponieważ na dysku miałem około 50GB wolnego miejsca, zmniejszyłem partycję systemową o 30GB i dałem w Intel RST aby wykorzystał całe dostępne miejsce na cache dla Voluminu RAID-5. Po kliknięciu tej opcji mało nie dostałem zawału serca, bo przez chwilę myślałem, że straciłem dysk systemowy, zaczęły znikać ikonki z pulpitu i system mi się zrestartował. Na szczęście wszystko wstało jak należy, po "migracji" widać to tak:

 

 

A tutaj benchmarki:

RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [sSD Cache 30GB Extended Mode]

RAID-5 64k stripe 64k cluster 3xHDD (0% Full) - Fully Initialized [sSD Cache 30GB Max Performance Mode]

 

Jak widać, nie ma róży bez kolców. Poza tym wyniki testów z użycie dysku SSD traktował bym raczej ostrożnie. Dla porównania wynik Read Test Suite z Aidy:

 

No i tutaj potwierdza się moja teoria.

 

Na razie wszystko wskazuje na najlepszą konfigurację 64k/64, dokończę sprawdzanie na innych paskach i jeśli okaże się że ta opcja jest rzeczywiście najlepsza, zacznę testy praktyczne, na zapełnionym dysku. Głównym celem będzie ustalenie czy korzystać z SSD Cache, czy nie.

 

Obecnie inicjalizuje się wolumin na pasku 128k.

Edytowane 19 Lipca 2014 przez premiero

[Dijkstra]

 

Przeczytałem chyba gazylion stron na temat konfiguracji i optymalizacji RAID-5, i chociaż wszędzie piszą olać RAID5, dołożyć dysk i zrobić 10, to ja mam tylko 3 dyski i zależy mi aby mieć zabezpieczenie danych.

 

Szczerze mówiąc, dobrze piszą... RAID5 sprawdza się dobrze na dedykowanym kontrolerze z własnym CPU, ewentualne software'owo robiony MD pod linuxem, jeśli to dedykowany NAS...

Albo dołożyłbym jeden dysk do RAID10, albo na dwóch zrobił 0, a na trzeci zrzucał backupy różnicowe najważniejszych danych co kilka godzin, czy jak Ci tam pasuje.

 

Tak czy owak: czy przy ustawieniach write through/write back macierzy masz możliwość sterowania ustawieniami cache pojedynczych dysków? Chodzi mi o to, czy przy write-back na pewno cache dysków jest pomijane (wyłączone),

Opcjonalnie - nie wiem, jaka to wersja systemu, ale jeżeli OS masz i tak na osobnym dysku i jest to pro/enterprise/ultimate, możesz spróbować zrobić RAID5 na windowsie - może się okazać, że Twoje problemy się rozwiążą. IMHO: hardware raid>software raid>fake raid, i fake raid z mobo należy używać tylko, jak nie masz innej opcji. 

[rafa]

Zaletą "raid z płyty" jest możliwość bootowania ale jak system jest i tak gdzie indziej to rzeczywiście spróbowałbym z pod systemu.

 

Ale porada Raid 0 + częsty backup jest zdecydowanie najlepsza!

[premiero]

Dzięki panowie, za porady, jednak nadal nie dają one odpowiedzi na pytanie - dlaczego odczyt jest taki wolny?

Co do write-back, nie ważne czy włączony czy włączony, nie ma możliwości sterowania własnym cachem dyskowym.

Edytowane 16 Lipca 2014 przez premiero

[rafa]

Im większy pasek tym mniejsze obciążenie CPU. Szedłbym w tym kierunku. Ustaw maksymalne możliwe wielkości paska.

[premiero]

CPU raczej nie ma tu nic do rzeczy, nie zauważam żadnego obciążenia podczas pracy, no może 1%. A RAID0+backup to dobry gdy nie wszystko chcesz backupować, u mnie to rozwiązanie odpada.

[Dijkstra]

Czy w sofcie producenta dysków jest opcja wyłączania wewnętrznego cache? Jeżeli tak, spróbuj to zrobić; po mojemu to jest problem, przy write-back indywidualne cache dysków nie powinno być używane, a prawdopodobnie jest. A kontroler ma ustawienia dotyczące read-ahead?

 

PS. Próbuj też kombinować z wielkością klastra NTFS; nie wiem, jakiego rodzaju dane chcesz trzymać, ale jeżeli plików niewiele a duże, spróbuj z rozmiarem clustra 64K i rozmiarem stripa 64K.

 

PS2. Wyłącz testowo wszystkie opcje oszczędzania energii w powermgmt.msc - CPU zawsze 100%, oszczędzanie energii magistrali PCIE off.

[Klaus]

Próbowałeś testować wszystkie dyski osobno? Może któraś sztuka ma problem z pozycjonowaniem głowicy czy inny feler.

[premiero]

@Klaus - Tak, każdy dysk testowałem najpierw osobno i wszystkie praktycznie wzorcowo zachowują się tak samo, więc wykluczam wadę jednego dysku.

 

@Dijkstra - chyba przeoczyłeś drugi post ;) , jak widzisz testuję zależności rozmiar paska / rozmiar clustra NTFS i na razie najkorzystniej wychodzi 64k/64k. Jednak jest to proces długotrwały ze względu na rozmiar i czas potrzeby na inicjalizację woluminu. Co do oszczędzania energii, jest wyłączone aby wykluczyć wpływ, na włączonym zachowuje się identycznie. Sprawdzę z tym cachem co i jak i dam znać.

Edytowane 17 Lipca 2014 przez premiero

[premiero]

Sprawdziłem jak jest z tym cachem, więc tak, jednak jest możliwość wyłączenia cache dla dysków przy włączonym cache'u dla macierzy write-back/write-through/read-only. Akurat mam zainicjalizowany wolumin na pasku 128k więc zrobiłem porównanie:

 

1. Stripe 128k / 64 cluster - ustawienia standardowe, czyli cache dyskowy ON, cache macierzy OFF, opróżnianie bufora zapisu ON

 

2. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-back ON, opróżnianie bufora zapisu OFF

Jedyny pozytywny przypadek, gdzie WB dało wzrost wydajności dla zapisu liniowego i losowego zapisu bloków 4k.

 

3. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-back ON, opróżnianie bufora zapisu OFF

 

4a. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-through ON, opróżnianie bufora zapisu OFF

4b. Stripe 128k / 64 cluster - cache dyskowy ON, cache write-through ON, opróżnianie bufora zapisu ON

 

4c. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-through ON, opróżnianie bufora zapisu OFF

 

4d. Stripe 128k / 64 cluster - cache dyskowy OFF, cache write-through ON, opróżnianie bufora zapisu ON

 

5a. Stripe 128k / 64 cluster - cache dyskowy ON, cache read-only ON, opróżnianie bufora zapisu OFF

 

5b. Stripe 128k / 64 cluster - cache dyskowy ON, cache read-only ON, opróżnianie bufora zapisu ON

 

5c. Stripe 128k / 64 cluster - cache dyskowy OFF, cache read only ON, opróżnianie bufora zapisu OFF

 

5d. Stripe 128k / 64 cluster - cache dyskowy OFF, cache read only ON, opróżnianie bufora zapisu ON

 

Jak widać z załączonych obrazków, zgodnie z moimi przewidywaniami, wyłączenie cache dyskowego powoduje dramatyczny spadek wydajności zapisu. Testy 4c,4d 5c,5d trwały łącznie około 2 godzin. Natomiast włączenie jakiegokolwiek sposobu cache'owania przez kontroler macierzy nie zmienia prędkości odczytu, ma wpływ wyłącznie na zapis.

 

Na chwilę obecną najlepsze warianty wydajnościowe, to 64/64 z Write-Back OFF i 128/64 z Write-Back ON.

Przede mną kolejnych kilkanaście godzin inicjalizacji stripe'a 32k :) i później seria testów. Na zakończenie testów zrobię jeszcze porównanie do 3 dyskowego RAID-0.

[jonathan]

Ale twoj caly problem to "kontroler" na plycie...

To "cos" nadaje sie do RAIDU 1/0

Raid5 to wylacznie na normalnym kontrolerze...

[premiero]

Z tym czy "nadaje się" to się okaże, natomiast nie przeceniałbym aż tak bardzo sprzętowych raidów. Miałem kilka 5-tek w robocie na hardwareowych adaptekach, i powiem szczerze, że do pięt nie dorastały temu Intelowi, nie mówiąc że każdy z nich po około 3-4 latach wyzionął ducha, a koszt jednego był coś koło 600-700 USD. Z resztą problem stanowi wyłącznie odczyt w CrystalDiskMarku, czego akurat nie ma przy pasku 128k. Uważasz że wydajność przy 64/64 dla zapisu jest słaba? Ja nie.

Może problemem u mnie są zastosowane dyski? Niestety nie mam innych 2Tb aby sprawdzić.

[rafa]

A pokaż pomiar z HD Tach

[premiero]

Aida, robi to samo co HD-Tach, zrzuty masz wyżej i tam wygląda to dużo lepiej (przy 64/64 odczyt i zapis liniowy na początku dysku oba 270MB/s). Stąd zastanawiają mnie te rozbieżności między benchmarkami. Jak już zrobię testy na pasku 32k, o ile nie okaże się wydajniejszy w CDM, zakładam z powrotem volumin 64k/64k, i wrzucę testy na ATTO.

[jonathan]

Ale wytlumacz mi jedno...

Mowisz o bezpieczenstwie danych itd, a przejmujesz sie predkosciami.

[premiero]

Optymalizacja to podstawa, a jedno nie wyklucza drugiego. Ty byś się zadowolił taką wydajnością odczytu, wiedząc że może (powinno) być lepiej? Nie oczekuję wydajności 3 dyskowego RAID'a-0, ale 3 dyskowy RAID-5 powinien przy idealnej konfiguracji mieć wydajność na poziomie 2 dyskowego RAID-0.

[jonathan]

Ja nie bawilbym sie w RAID5

Wolalbym 2 dyski puscic w RAID1 a trzeci wykorzystac do backupu

[premiero]

Jak chesz zbackupować 4TB na 2TB dysku? I rozumiem chodziło ci o "0" poziom.

Edytowane 18 Lipca 2014 przez premiero

[jonathan]

Ile tak naprawde jest tych danych?

Na razie sie bawisz jak widze...

 

I owszem chodzilo mi o RAID1 - o mirror

Waznych danych nie trzymalbym na stripie

[premiero]

Dane są na innych dyskach w tej chwili. Po co mi mirror + backup? To nie dane krytyczne, przecież to byłoby zwykłe marnotrawstwo przestrzeni. Mam propozycję, aby niepotrzebnie nie przerzucać się nad wyższością jednego RAIDA na innym, skupmy się nad tą 5-ką. Założenie jest takie, że ma być RAID-5 i umarł w butach. Wątek powstał aby zoptymalizować tego RAID-5, a nie zmieniać na inną wersję :) i tego się trzymajmy.

[Dijkstra]

Jak widać z załączonych obrazków, zgodnie z moimi przewidywaniami, wyłączenie cache dyskowego powoduje dramatyczny spadek wydajności zapisu.

Przy write-back wpływ wyłączenia cache dysków powinien być minimalny/żaden, lub wręcz dodatni...

Sprawdzałeś, czy nie ma aby aktualizacji FW kontrolera? Firmware dysków?

[radiergummi]

 

ASUS / ASRock / MSI / GIGABYTE BIOS's with updated RAID OROM

 

[rafa]

Aida, robi to samo co HD-Tach, zrzuty masz wyżej...1

Nie widze żadnego wykresu z AIDA i o ile pamiętam nie potrafi tego robić. A mnie chodzi o prześledzenie przebiegu wykresu a nie jakieś maksima. Maksima są ok dla SSD.

Wykres będzie albo naturalny dla HDD albo spłaszczony z jakiegoś powodu...

[premiero]

@Dijkstra - niestety, nie znalazłem żadnego upgrade firmware do tych WD-ków (przy okazji znalazłem do mojego dysku SSD). Asus dla Z87-Pro również nie ma nowszej wersji BIOS niż 2005, a tam jest OptionROM 12.7.0.1936.

 

@radiergummi - dzięki za linka, jeśli nic nie wymyślę, będę musiał wyekstrahować z innej płyty nowszą wersję Option-ROMu i spróbować zmodyfikować BIOS.

 

@rafa - HD-Tach przestałem używać kilka lat temu, ponieważ nie jest w mojej opini wiarygodny i często pokazuje głupoty.

W Aidzie wchodzisz Tools->Disk Benchmark->Wybierasz Linear Read i dysk który ma być przetestowany. Dostajesz piękny wykres, niestety czas jego wykonania to około 400-500 minut, więc robiłem go tylko 5 minut, także nie wrzucałem wykresu, jest tylko tabela z Read Suite.

 

Dla świętego spokoju zrobiłem test HD-Tachem - tutaj wyniki dla paska/klastra 32k/64k. Pierwszy wykres to QuickBench 8MB Zones (taaaaa chciałbym takie wyniki) , drugi Long Bench 32 MB Zones.

 

Zrzuty z ATTO dla 32k stripe i 4k cluster/64k cluster

Edytowane 19 Lipca 2014 przez premiero

[rafa]

@rafa - HD-Tach przestałem używać kilka lat temu, ponieważ nie jest w mojej opini wiarygodny i często pokazuje głupoty.

...

 drugi Long Bench 32 MB Zones.

Jest bardzo dobry jako narzędzie diagnostyczne ;)

Tylko Long Bench ma sens w ogóle. Teraz trzeba pomyśleć skąd aż tyle "pików" bo widać że na interface nie ma ograniczenia skoro momentami jest te 260-280

[premiero]

Wykres ze paska/klastra 128k/64k

 

Podejrzewam że dla paska 64k/64k byłby mniej "popikowany" niż dla 32k/64k, ale nie tak równy jak dla 128k.

 

Zrobiłem jeszcze szybki test na woluminie RAID-0:

Stripe 16k: | 4k | 64k |

 

Stripe 128k: | 4k | 4k WriteBack ON | 64k

 

No nic, zmodyfikowałem sobie BIOS, zrobię upgrade OROM'a i zobaczę czy to coś zmienia.

 

Robi się co raz ciekawiej, po aktualizacji OROM wyniki dla RAID-5, 128k/64 (bez tworzenia woluminu od nowa)

- spadek zapisu liniowego o połowę, a także spadki przy odczycie i zapisie 512k

- z włączonym WriteBack trochę lepiej ale i tak gorzej niż na OPTION_ROM_12.7.0.1936

 

Stworzę od nowa na nowy OROM-ie wolumin, może coś to zmieni i znowu zrobię test.

Edytowane 20 Lipca 2014 przez premiero

[rafa]

Tak jak pisałem, trzymaj się jak największych wartości paska. To nie jest sprzętowy kontroler a wszystko działa na sterowniku i CPU.

Próbowałeś 128 stripe i mniejszy cluster 32?

[premiero]

@rafa - wszystkie testy masz w 2 poście dla każdej możliwej kombinacji paska/klastra.

Dla zapisu najlepszy rozmiar wychodził 64k/64k. I zostałbym przy tym, gdyby tylko odczyt był na poziomie 128k/64k.

Edytowane 20 Lipca 2014 przez premiero

[premiero]

Ech, już sam nie wiem o co bigos. Albo padłem ofiarą testu, albo nie wiem o co chodzi:

Na nowym OROM-ie, dla paska 64k i klastra 64k:

- spadek zapisu liniowego w porównaniu do poprzedniej wersji o 200MB/s i o ponad 90MB/s dla bloków 512k

- tutaj ciekawostka, ustawienia Cache WriteBack OFF, Disk Cache ON, Opróżnianie bufora zapisu OFF. I wyszło dokładnie tak samo jak przy starym OROMIE ale dla ustawień WriteBack OFF, Disk Cache ON, Opróżnianie bufora zapisu ON.

- Write Back ON, Disk Cache ON, Opróżnianie bufora zapisu OFF

 

Zrobiłem też pomiar HD-Tachem i wynik mnie zaskoczył:

Żadnych spike'ów, wykres całkiem równy. Skąd w takim razie tak słaby odczyt w CDM?

 

Wkurzyłem się i postanowiłem przeprowadzić test na żywych plikach. Do testów użyłem łącznie 440GB danych. Okazało się że testy syntetyczne można wrzucić do kosza. Nic się nie trzymało kupy. W testach praktycznych pokazała się przewaga tego co powinno być oczywiste - czyli włączonego Write-Back Cache'a. Kopiowanie dużych plików z dysku SSD na macierz praktycznie nie spadało poniżej 200MB/s, jak tylko wyłączałem WBC, od razu prędkości spadały do wartości ~60MB/s. Jeszcze większą różnicę było widać przy kopiowaniu małych plików.

 

Zrzuty dla ATTO (dysk zapełniony 440GB danych):

WBC ON/OFF

 

 

Chyba jednak wrócę do paska 128k z włączonym WBC. Sprawdzę jeszcze jak będzie się to zachowywać przy OROM-ie 13.1.0.2126 i ostatni test zrobię na Windowsowym RAID-5.

Zmęczyły mnie już testy ;/

 

 

EDIT - nie zrobię testów na Windowsowym RAID-5, ponieważ Windows 7 nie obsługuje software'owego RAID-5 :(

Edytowane 21 Lipca 2014 przez premiero