RSS

Test macierzy Dell powervault md1000 13

Posted by depesz Thu, 27 Sep 2007 15:04:00 GMT

Ostatnio dostaliśmy nową zabawkę do testów - nowiutkiego della powervault md1000. Co to takiego, zapytacie? Otóż jest to całkiem miły "das" (direct attached storage, czyli, upraszczając trochę, po prostu macierz) od Dell'a.
Egzemplarz, który testowaliśmy miał 15 dysków sas, każdy o pojemności 72gb i prędkości obrotowej 15000 rpm. Macierz ma być używana jako nośnik dla bazy danych, więc zanim zostanie użyta musieliśmy przeprowadzić testy (by wiedzieć co i jak podzielić na poszczególne dyski logiczne). Podłączyliśmy ją do wolnego serwera (także Dell'a, ale nieużywanego), którego parametry są "całkiem, całkiem" :
  • 4 dwurdzeniowe xeon'y (3.4ghz)
  • 32gb ram
  • 2 wewnętrzne dyski, sas, 72gb, 15000 rpm, 72g zestawione w raid1
Testy przeprowadziliśmy przy pomocy bonnie++, procedura testowa była prosta:
  1. zestawienie nowego raida
  2. mke2fs -j (ext3)
  3. zamontowanie partycji z opcjami noatime i nodiratime
  4. uruchomienie bonnie++ z tymi opcjami:"-u nobody:nobody -f -s 65000,8192 -n 0 -x 3" (8192 gdyż taka jest wielkość strony w postgresie)
  5. rezultaty dla każdego raida (-x 3!) były uśrednione
Wiedzieliśmy, że docelowo zostanie użyty raid10, więc testowaliśmy głównie różne jego kombinacje. Przeprowadziliśmy 2 oddzielne serie testów:
  1. raid 10, czysto sprzętowy, używając 2, 4, 6, 8, 10, 12 i 14 dysków
  2. raid 10, mieszany sprzętowo/software'owy - sprzęt był użyty do zrobienia 7 oddzielnych dysków logicznych, każdy z użyciem 2 dysków fizycznych spiętych w raid1, ale potem były one składane w jeden dysk logiczny przy pomocy software'owego raida (linux, raid0) w urządzenie na 4, 6, 8, 10, 12 i 14 dyskach fizycznych
Testy przeprowadzono z wyłączeniem read-aheada, zapisy były w trybie write-back, gdyż macierz jest wyposażona w pamięć z podtrzymaniem bateryjnym. Rezultaty są trochę dziwne (czerwona linia - raid10 czysto sprzętowy, zielona linia - rozwiązanie mieszane: sprzęt/software):

write.png rewrite.png read.png seeks.png
Jeśli wolisz wyniki w postaci tabelek:

name put_block put_block_cpu rewrite rewrite_cpu get_block get_block_cpu seeks seeks_cpu
2xraid1 34820 12 25105 6 97459 9 436 1
4xraid10 95427 37 65661 19 246490 23 615 1
6xraid10 100367 39 70955 20 288188 27 672 1
8xraid10 165980 66 98887 29 423983 39 737 1
10xraid10 164195 64 96039 28 394442 36 618 1
12xraid10 185671 72 103271 30 414942 38 686 1
14xraid10 195349 76 104087 30 439088 40 821 2
2s0@2h1 86651 32 61836 18 251109 24 618 1
3s0@2h1 110977 42 79381 24 356231 34 708 2
4s0@2h1 120232 45 91988 28 391041 37 748 2
5s0@2h1 131024 50 92403 28 556601 55 788 2
6s0@2h1 123812 47 93563 28 482090 47 778 2
7s0@2h1 137513 53 100083 31 657221 65 839 2
2s0@6h10 160090 61 104375 32 482106 46 716 2
2s1@2h1 44373 16 25972 6 99071 10 651 1
13xraid5 222225 87 113040 32 392238 36 806 2
14xraid5 222690 87 114142 33 398201 36 809 2

Znaczenie kolumny name:
  • (\d+)xraid(\d+) - $1 dysków w czysto sprzętowym raidzie $2. przykładowo - 6xraid10 oznacza 6 dysków w sprzętowym raidzie 10
  • (\d+)s0@2h1 - $1 dysków logicznych (gdzie każdy dysk logiczny, to 2 dyski fizyczne spięte w sprzętowy raid1) połączone w software'owy raid0. przykładowo 5s0@2h1 oznacza 5 dysków logicznych (każdy z 2 napędów, w raid1) połączonych, dając razem raid 10 na 10 dyskach w układzie mieszanym sprzętowo/software'owym
  • 2s0@6h10 - 2 dyski logiczne, każdy składający się z 6 dysków fizycznych połączonych w sprzętowy raid10, połączone w software'owy raid 0
  • 2s1@2h1 - 2 dyski logiczne, każdy będący 2 dyskowym, sprzętowym, raidem 1, połączone w software'owy raid1. daje to 4 dyskowa macierz o pojemności pojedynczego dysku.
Jak widać, przetestowaliśmy kilka układów więcej niz pokazane jest to na wykresach powyżej, ale wszystkie pozostałe były jedynie testowe, bez realnego wpływu na jakiekolwiek decyzje. Dziwna sprawa - czysto sprzętowy raid wykazuje "schodki" w wydajności zapisów (i przepisywania danych). Przyrost wydajności był tylko wtedy, gdy ilość dysków była potęgą 2. W raidach mieszanych (sprzęt/software) nie było takiego efektu. Ponieważ macierz ma 15 dysków, zdecydowaliśmy się na użycie takiego layoutu:
  • 1 dysk jako globalny hot-spare
  • 2 diskowy raid1 (sprzętowy) na logi postgresa
  • 8 dyskowy raid10 (sprzętowy) jako główna przestrzeń (tablespace) bazodanowa
  • 4 dyskowy raid10 (sprzętowy) jako dodatkowa przestrzeń bazodanowa
Teoretycznie układ ten powinien zapewnić najlepszą wydajność, czy tak było? Po stworzeniu macierzy, założeniu systemów plików, przetestowaliśmy wydajność wszystkich 3 dysków logicznych jednocześnie. Wyników nie rozrysowywaliśmy, gdyż i tak nie miałoby to zbyt dużego sensu. Ale wyniki z testu można podać tabelarycznie:

name put_block put_block_cpu rewrite rewrite_cpu get_block get_block_cpu seeks seeks_cpu
2xraid1 30875 12 15438 5 39867 5 224 1
2xraid1 32489 14 24037 7 99700 9 389 1
2xraid1 35096 13 24708 6 96969 9 383 0
4xraid10 41343 18 31910 11 61798 8 109 0
4xraid10 80630 34 35707 12 137488 18 306 1
4xraid10 40136 17 38388 12 147282 16 255 0
8xraid10 42376 18 37513 13 155740 19 302 1
8xraid10 156044 65 34153 11 177690 22 338 1
8xraid10 146096 61 71307 25 29568 3 154 0

(pokazano tu wyniki każdego testu, czyli po 3 wyniki dla każdej z partycji). Jak widać, wyniki są niższe od oczekiwanych. Dodatkowo, analizę utrudnia fakt, iż test macierzy 8xraid10 skończył się jako pierwszy (bo jest najszybsza), 4xraid10 skończył się trochę później, a 2xraid1 trwał i trwał, i trwał:)
Myślę, że wybraliśmy rozwiązanie optymalne przy tej macierzy i kontrolerze, ale tak czy inaczej zastanawiające jest czemu wydajność tak mocno jest powiązana z potęgami dwójki.
Comments

Leave a response

  1. juhu 4 days later:

    Użytkownicy grona zapewne wszystko doskonale zrozumieli. Zresztą fotka ma cztery takie maszynki.

  2. jaro 5 days later:

    tylko trzeba sobie przypomniec kilka wykladow i wszysto w miare zrozumiale :)

  3. BIGHard 10 days later:

    policzmy:

    8 dyskow w raid10 po 72gb kazdy, daje nam pojemnosc 4*72gb = 288gb na baze

    tylko? phi…

    pozatym – postgres??

  4. depesz@grono.net 12 days later:

    @BIGHard:

    Jak na razie ta pojemność w 100% wystarcza (z wystarczającym marginesem aby dane użytkowników nie były zagrożone). Dodatkowo – nikt nie mówił, że to jedyna macierz podpięta pod bazę, ani, że to jedyna baza.

    Ciekawi mnie natomiast osobiście Twój stosunek do PostgreSQL’a. Jak rozumiem uważasz, że wybór tego silnika bazodanowego nie jest optymalny. Czemu? Jaki inny mógłbyś zasugerować? I czemu właśnie ten.

  5. BIGHard 22 days later:

    bedziesz sie depeszu smial pewnie, ale powiem mysql :)

    dlaczego? replikacja… w mysqlu jest natywna (jak robicie backupy bez repliki?) – zamiast slonia w postgresie, ktory jest tragedia…

    chyba ze naprawde uzywacie trigerow i procedur, i bez nich swiat sie zawali – bo w kwestii wydajnosci bazy mysql radzi sobie calkiem calkiem.

    bo na oracla, to jeszcze nie czas, prawda?

  6. barnaba@gentoo.pl 26 days later:

    BIGHard nie drażnij depesza

  7. BIGHard 27 days later:

    nie draznie, wdaje sie w rzeczowa dyskusje

  8. depesz@grono.net 28 days later:

    @BIGHard:

    śmiać się nie będę.

    odpowiadając – slony działa całkiem fajnie i nie do końca widzę w nim tragedię – oczywiście, sporo rzeczy można zrobić lepiej, ale tak to każdy system można “wypunktować”, dodatkowo jest kilka innych rozwiązań replikacyjnio/klastrujących – polecam spojrzenie na pgpoola (do pewnych zastosowań świetne, ja osobiście nie przepadam), londiste (prostsza replikacja typu async master-slave), bucardo (async multi-master) czy pl/proxy. zwłaszcza ten ostatnio projekt jest bardzo interesujący, mimo (a może własnie dlatego), że nie jest replikacją.

    backupy – normalnie. pg_dump tam gdzie trzeba, backupy wala tam gdzie się nadają. da się. pg_dump (w przeciwieństwie do niektórych innych baz danych) nie lockuje – co oznacza, że dumpa możesz robić w dowolnym momencie. oczywiście lepiej go zapuszczać na slave’ach, ale gdy trzeba to i na masterze pójdzie.

    co do replikacji w mysql – sam nie testowałem. natomiast czytałem opisy i martwi mnie jej model działania – slave’y nie są zabezpieczone przed modyfikacjami (co jest fajnym feature’em bo daje możliwość zestawienia replikacji cyklicznej), multi-master cykliczny opiera się na założeniu (a przynajmniej tak zrozumiałem), że musisz sam (w aplikacji) dbać o kwestie konfliktów rzeczy typu indeksy unikatowe.

    nie twierdzę, że mysql jest zły – po prostu znam lepiej postgresa, jego wady i zalety i jakoś przyjemnie mi się w nim pracuje.

    co do oracle’a – to temat na inną świętą wojnę – ogólnie nie uważam by w zastosowaniach oltp przy tej (i dwóch następnych) skalach wielkości baz oracle miał jakąś istotną przewagę.

  9. BIGHard 29 days later:

    ja wiem ze dumpa da sie zrobic i na masterze – tak jak w mysqlu. chodzi mi raczej o to, ze jesli trwa dluzej niz jedna atomowa operacje, to nie masz backupu z danego momentu tylko nalozone operacje z paru godzin. a co jesli update trwa dluzej niz backup? dostaniesz wtedy np polowe tabeli przed update i polowe po – wlasnie dlatego slave – stop; dump; start – i masz dokladnie z danej chwili snapshot.

  10. depesz@grono.net about 1 month later:

    @BIGHard:

    ekhem. sorry – nie wiem jak jest w mysql’u, ale w postgresie dump daje snapshota. niezależnie od tego ile czasu trwa i ile innych operacji po drodze było.

    z http://www.postgresql.org/docs/current/interactive/app-pgdump.html:

    >

    pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).

  11. klolik about 1 month later:

    z niewielkiego doświadczenia wiem, że przesiadka z postgresa na mysql jest doznaniem wysoce irytującym dla każdego, kto używa czegoś więcej niż standardowe insert/update/select. triggerami i procedurami można dużo łatwiej zapewnić integralność bazy + cacheować pewne rzeczy, np. liczbę fotek każdego użytkownika ;) szczególnie jeśli zmiany wprowadza się przez różne API—lepiej niech dba o to baza, skoro i tak jest ostatnim ogniwem.

  12. tomee 4 months later:

    Troche kopa ta macierz ma, ale wyniki mnie nie porazaja. Por. http://tomee.heroin.pl/bonnie.html, zwl. ostatnie pozycje. Jaki system plikow, spytacie… no, na pewno nie ext3.

  13. matrut 4 months later:

    panowie z allegro przesiaknieci “sukcesem” sadza, ze stworzyli III armie Pattona ktora podbije europe srodkowo-wschodnia -> gratuluje podejscia, prawda BIGHard?

    niestety jesli mowa silnikach bazodanowych niebagatelne znaczenie ma staz. ten w przypadku pgsql’a, oracle, db2 odgrywa czolowa role.

    ciekawe dlaczego owa ‘armia’ zdecydowala sie migracje na oracle skoro mysql tak dobrze sobie radzil…. moze wiecej szczegolow technicznych niz tylko uskutecznianie dzichadu?

Comments