Dwa dyski twarde: te same specyfikacje, różne prędkości. Musisz znaleźć problem z konfiguracją

Mam dwa węzły (każdy z 3 dedykowanymi napędami danych), które wykazują drastycznie różne prędkości zapisu. Ich wyjście „hdparm” wygląda identycznie, a ich wyjście „hdparm -t -T” jest porównywalne, ale uruchomienie polecenia „dd” w zamontowanym systemie plików daje drastycznie różne prędkości zapisu. Użycie „dd” do testowania prędkości odczytu ponownie daje podobne wyniki.

Serwery i dyski twarde są dokładnie tymi samymi modelami, oba korzystają z tych samych pakietów oprogramowania (używamy szefa kuchni do wypychania pakietów na nasz klaster).

Szukam pomysłów na parametry do sprawdzenia lub innych testów do uruchomienia, które pomogą mi uporządkować rozbieżności wydajności. Wygląda na to, że jest na poziomie OS / FS, ale nie jestem pewien, na co jeszcze patrzeć. Oba zamontowane systemy plików to EXT4 z włączoną opcją noatime i user_xattr.

Szybki serwer:

hdparm -t -T wydajność:

/dev/sdb1:
 Timing cached reads:   2138 MB in  2.00 seconds = 1070.08 MB/sec
 Timing buffered disk reads:  232 MB in  3.02 seconds =  76.84 MB/sec

wypisując plik testowy 4 GB

$ dd bs=4K if=/dev/zero of=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 40.1102 s, 107 MB/s
0.20user 10.91system 0:40.14elapsed 27%CPU (0avgtext+0avgdata 3472maxresident)k
16inputs+8388608outputs (1major+263minor)pagefaults 0swaps

Odczyt tego pliku z dysku (i do / dev / null)

$ dd bs=4K of=/dev/null if=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 53.3914 s, 80.4 MB/s
0.19user 5.80system 0:53.53elapsed 11%CPU (0avgtext+0avgdata 3488maxresident)k
8389872inputs+0outputs (2major+264minor)pagefaults 0swaps

Powolny węzeł:

hdparm -t -T wydajność

/dev/sdc1:
 Timing cached reads:   1982 MB in  2.00 seconds = 991.27 MB/sec
 Timing buffered disk reads:  224 MB in  3.02 seconds =  74.16 MB/sec

$ dd bs=4K if=/dev/zero of=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 98.1583 s, 43.8 MB/s
0.35user 17.58system 1:38.17elapsed 18%CPU (0avgtext+0avgdata 3456maxresident)k
8inputs+8388608outputs (0major+263minor)pagefaults 0swaps


$ dd bs=4k of=/dev/null if=/mnt/vol1/test.file count=1M
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 54.7789 s, 78.4 MB/s
0.25user 10.84system 0:54.92elapsed 20%CPU (0avgtext+0avgdata 3488maxresident)k
8389864inputs+0outputs (2major+263minor)pagefaults 0swaps

— Buck
źródło

Uruchom ponownie dd komendy używające time, więc możemy zobaczyć użycie procesora. Czy dwa węzły wykazują różne prędkości zapisu w realistycznych warunkach lub tylko w sztucznych warunkach testowych? (Te dwa pliki mogą znajdować się w różnych fizycznych miejscach na dysku.) Co to jest marka / model napędu?

— David Schwartz

Oba dyski są prawie puste, więc powinny korzystać z podobnych części talerza. Napisy są w sztucznych warunkach, ale podobne zachowania są widoczne w warunkach rzeczywistych (robimy testy porównawcze rozproszonego systemu plików na tych węzłach).

— Buck

Dodano time wyjście, zgodnie z żądaniem

— Buck

Ponadto, jeśli zrobię dd komenda z zapisami 512 bajtów, a nie zapisami 4K, prędkości są identyczne.

— Buck

Odpowiedzi:

Próbować

hdparm -i -I /dev/sda

W przypadku obu napędów i różnicowania danych wyjściowych powinno to wskazywać, czy jest to ustawienie dma lub lookahead, które jest różne dla obu.

W zależności od dystrybucji, powinno być miejsce na ustawienie hdparm, aby upewnić się, że są takie same.

Sprawdziłbym też podwójnie kable. To może być po prostu jeden dysk jest po prostu zły, możesz sprawdzić inteligentne stawki ECC i takie.

/usr/sbin/smartctl -A -H /dev/sda
/usr/sbin/smartctl -a /dev/sda

Czy używam tego do sprawdzania inteligentnych dysków?

— RLZaleski
źródło

Może dysk jest zły. Sprawdź błędy. (sprawdź także dane wyjściowe, aby sprawdzić, czy są naprawdę takie same: model, oprogramowanie układowe, rozmiar i rozmiar sektora)

smartctl -a / dev / sdb smartctl -a / dev / sdc

Jeśli masz błędy, przeprowadź krótki test (trwa 2 minuty):

smartctl -t short / dev / sdb

Jeśli test przebiegnie bez błędów, uruchom ponownie z „długim” zamiast „krótkim” (zajmuje godziny).

A kiedy to się skończy, ponownie sprawdź za pomocą „-a” i zapisz zera na dysku w tym sektorze, aby je przenieść (niszczy to dane! Bądź bardzo ostrożny z tym, co wstawiłeś = ponieważ to jest nadpisywane surowy poziom z zerami).

na przykład. jeśli rozmiar sektora wynosi 512, a LBA 555 jest zły, wpisz to polecenie (niszczy dane!)

dd if = / dev / zero of = / dev / sdb bs = 512 count = 1 seek = 555

Zrobiłbym większą liczbę, więc nie musisz powtarzać testów i zapisywać zer tak często, ponieważ złe sektory są zwykle obok siebie. (niszczy znacznie więcej danych!)

dd if = / dev / zero of = / dev / sdb bs = 512 count = 500 seek = 555
Może twoje wyrównanie jest złe. Upewnij się, że wszystkie partycje zaczynają się od lub po 63, a jeśli Twój rozmiar sektora logicznego jest mniejszy niż rozmiar sektora fizycznego, upewnij się, że wyrównanie jest podzielne przez rozmiar fizyczny / rozmiar logiczny. Powinno to znacznie wpłynąć na szybkość zapisu, ale nie zmieniać bardzo szybko prędkości odczytu / wcale.

na przykład. jeśli wartość fizyczna wynosi 4096, a wartość logiczna 512, to sektor początkowy musi być podzielny przez 8 (4096/512). Na niektórych dyskach początek musi być znacznie większy niż 63. Na tych dyskach używam 252 jako pierwszej partycji.

A jeśli używasz dysku SSD, musisz także wyrównać do bloku kasowania. Bezpieczny numer do wyrównania to wielokrotności 129024 (który spełnia 63 wymagania dla starych dysków, sektorów 4096 bajtów [dyski formatu zaawansowanego, takich jak większość dysków Seagate i WD Green], 1024 MB dla większości dysków SSD i 2048 MB dla rzadkich dysków SSD )

Również w przypadku dysków SSD, jeśli wydają się powolne, przed użyciem ich należy usunąć je za pomocą narzędzi dostarczonych przez dostawcę lub użyć TRIM.
Użyj właściwego testu porównawczego.

Nie możesz wykonywać testów zapisu z dd, chyba że użyjesz conv = fdatasync lub innej metody. David Schwartz zasugerował użycie „time dd ...”, ale jeśli użyjesz conv = fdatasync, powie ci poprawny czas i prędkość w dd bez konieczności ponownego obliczania go samodzielnie. Jeśli masz dużo pamięci RAM lub pamięci podręcznej do zapisu, mierzysz pamięć RAM i dysk, jeśli nie używasz opcji takiej jak conv = fdatasync. http://romanrm.ru/en/dd-benchmark

na przykład.

dd bs = 4K if = / dev / zero z = / mnt / vol1 / test.file count = 1M conv = fdatasync
Użyj właściwego testu porównawczego. (część 2)

Wiele systemów plików lub dysków wykona BARDZO inaczej podczas zapisywania zer. Aby uzyskać najlepsze wyniki, musisz używać losowych plików.

na przykład.

pierwsza kopia do pamięci RAM

cp /somewhere/with/big/files/bigfile.iso / dev / shm

uruchomić test

dd bs = 4K if = / dev / shm / bigfile.iso z = / mnt / vol1 / test.file count = 1M conv = fdatasync

lub

przygotuj losowy plik

dd if = / dev / random of = / dev / shm / randfile bs = 1M liczba = 500

uruchomić test

dd bs = 4K if = / dev / shm / randfile = / mnt / vol1 / test.file count = 1M conv = fdatasync
Ponadto, jeśli twoje dyski nie są naprawdę takie same lub mają różne systemy plików, będą działać bardzo różnie przy rozmiarze bloku 4k. Sprawdź także 128k i 1M.

— Peter
źródło