Jak mogę przetestować mój dysk twardy?

Widziałem polecenia do testowania własnego dysku twardego, takie jak ten przy użyciu dd:

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"

Czy są na to lepsze metody?

Zwykle używam hdparmdo testowania dysków twardych. Możesz przeprowadzić testy porównawcze zarówno odczytów bezpośrednich, jak i odczytów z pamięci podręcznej. Będziesz chciał uruchomić polecenia kilka razy, aby ustalić średnią wartość.

Przykłady

Oto bezpośredni odczyt.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

A oto odczyt z pamięci podręcznej.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Detale

-t     Perform  timings  of  device reads for benchmark and comparison 
       purposes.  For meaningful results, this operation should be repeated
       2-3 times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays  
       the  speed of reading through the buffer cache to the disk without 
       any prior caching of data.  This measurement is an indication of how 
       fast the drive can sustain sequential data reads under Linux, without 
       any filesystem overhead.  To ensure accurate  measurements, the 
       buffer cache is flushed during the processing of -t using the 
       BLKFLSBUF ioctl.

-T     Perform timings of cache reads for benchmark and comparison purposes.
       For meaningful results, this operation should be repeated 2-3
       times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays
       the speed of reading directly from the Linux buffer cache without 
       disk access.  This measurement is essentially an indication of the
       throughput of the processor, cache, and memory of the system under 
       test.

Korzystanie z dd

Ja również użyłem ddtego typu testów. Jedna modyfikacja chciałbym zrobić do powyższego polecenia jest dodanie tego bitu na końcu polecenia ; rm ddfile.

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Spowoduje to usunięcie ddfilepo wykonaniu polecenia. UWAGA: ddfile to plik przejściowy, którego nie musisz przechowywać, to plik, który ddzapisuje do ( of=ddfile), gdy ładuje dysk twardy.

Wyjść poza

Jeśli potrzebujesz bardziej rygorystycznych testów dysków twardych, możesz użyć Bonnie ++ .

Bibliografia

• Jak używać „dd” do testowania wydajności dysku lub procesora?
• Benchmark dysku IO z DD i Bonnie ++

(To bardzo popularne pytanie - możesz zobaczyć jego odmiany na https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 i https://askubuntu.com/q / 87035/740413 )

Czy istnieją lepsze metody [niż dd] do [dysków testowych]?

Tak, ale ich uruchomienie potrwa dłużej i będzie wymagało wiedzy na temat interpretacji wyników - nie ma jednej liczby, która powie Ci wszystko za jednym razem, ponieważ następujące czynniki wpływają na rodzaj testu, który powinieneś uruchomić:

• Czy jesteś zainteresowany wydajnością I / O, która jest losowa, sekwencyjna lub jakaś kombinacja tych dwóch?
• Czy czytasz z dysku lub piszesz na dysk (lub ich mieszankę)?
• Czy obawiasz się opóźnień, przepustowości lub obu tych czynników?
• Czy próbujesz zrozumieć, jak działają różne części tego samego dysku twardego (zwykle przyspiesza szybciej bliżej środka wirujących dysków)?
• Czy jesteś zainteresowany wydajnością danego systemu plików podczas korzystania z dysku, czy chcesz wyniki bliższe pierwotnej wydajności dysku, wykonując operacje we / wy bezpośrednio na urządzeniu blokowym?
• Czy jesteś zainteresowany tym, jak działa określony rozmiar I / O?
• Czy przesyłasz I / O synchronicznie czy asynchronicznie?
• Ile przesyłasz I / O (przesyłasz za mało w niewłaściwy sposób, a wszystkie I / O mogą zostać zapisane w pamięci podręcznej, abyś mógł skończyć testowanie prędkości pamięci RAM zamiast prędkości dysku)?
• Jak ściśliwa jest zawartość zapisywanych danych (np. Dane tylko zerowe są wysoce ściśliwe, a niektóre systemy plików / dyski mają nawet specjalną szybką ścieżkę dla danych tylko zerowych, co prowadzi do liczb, których nie można uzyskać przy innej zawartości)?

I tak dalej.

Oto krótka lista narzędzi z najłatwiejszym do uruchomienia na górze i trudnym / dokładniejszym / lepszym bliżej dołu:

1. dd (sekwencyjne odczyty lub zapisy, pokazuje tylko przepustowość, można skonfigurować do korzystania z systemu plików lub urządzenia blokowego, można skonfigurować tak, aby omijał pamięć podręczną bloków / czekał na zakończenie operacji we / wy)
2. hdparm (tylko sekwencyjne odczyty, pokazuje tylko przepustowość, nigdy nie używa systemu plików, może być skonfigurowany do omijania pamięci podręcznej bloków, test pamięci podręcznej ponownie odczytuje początkowe 2 MB)
3. Test porównawczy GNOME Disk Utility (łatwy do uruchomienia, nigdy nie używa systemu plików, graficzny, ale wymaga pełnej instalacji GNOME, podaje liczby opóźnień i przepustowości dla różnych typów operacji we / wy, ale obciążenie zapisu faktycznie wykonuje odczyt / zapis / fsync na wielkość próbki).
4. fio (może zrobić prawie wszystko i daje szczegółowe wyniki, ale wymaga konfiguracji i zrozumienia, jak interpretować te wyniki). Oto, co mówi o tym Linus:

   Greg - zdobądź kod FIO Jensa. Robi to dobrze, w tym zapisuje rzeczywistą zawartość pseudolosową, co pokazuje, czy dysk wykonuje „de-duplikację” (czyli „optymalizację pod kątem testów porównawczych”):

   [ https://github.com/axboe/fio/ ]

   Wszystko inne jest podejrzane - zapomnij o Bonnie lub innych tradycyjnych narzędziach.

Źródło: komentarz pozostawiony w Google Plus Gregowi Kroah-Hartmanowi przez Linusa Torvaldsa .

za pomocą narzędzia IOPS

Jeśli nie możesz się tym martwić, polecam narzędzie IOPS . Powie ci rzeczywistą prędkość w zależności od wielkości bloku.

W przeciwnym razie - wykonując test porównawczy IO, spojrzałbym na następujące rzeczy:

• blockize / cache / IOPS / direct vs buffered / async vs sync
• odczyt / zapis
• wątki
• czas oczekiwania

• Zużycie procesora

• Jakiego rozmiaru bloku użyjesz : Jeśli chcesz odczytać / zapisać 1 GB z / na dysk, będzie to szybkie, jeśli wykonasz jedną operację We / Wy. Ale jeśli twoja aplikacja musi pisać po 512 bajtach na całym dysku twardym w niesekwencyjnych częściach (zwanych losowymi I / O, chociaż nie jest losowa), będzie to wyglądało inaczej. Teraz bazy danych będą wykonywać losowe operacje we / wy dla woluminu danych i sekwencyjne operacje we / wy dla woluminu dziennika ze względu na ich naturę . Najpierw musisz wyjaśnić, co chcesz zmierzyć. Jeśli chcesz skopiować duże pliki wideo, które różnią się od tych, które chcesz zainstalować Linux.

  Ten rozmiar bloku wpływa na liczbę operacji we / wy, które wykonujesz. Jeśli wykonasz np. 8 sekwencyjnych operacji odczytu (lub zapisu, po prostu nie mieszanych), program planujący operacje we / wy systemu operacyjnego je połączy. Jeśli nie, pamięć podręczna kontrolera wykona scalenie. Praktycznie nie ma różnicy, jeśli odczytujesz 8 kolejnych bloków po 512 bajtów lub jeden fragment 4096 bajtów. Jeden wyjątek - jeśli uda ci się wykonać bezpośrednią synchronizację we / wy i poczekasz na 512 bajtów, zanim zażądasz kolejnych 512 bajtów. W takim przypadku zwiększenie rozmiaru bloku przypomina dodawanie pamięci podręcznej.

  Powinieneś również pamiętać, że istnieje synchronizacja i asynchronizacja We / Wy: dzięki synchronizacji We / Wy nie wydasz następnego żądania We / Wy, zanim bieżące powróci. Dzięki asynchronicznej operacji we / wy możesz zażądać np. 10 porcji danych, a następnie poczekać, aż nadejdą. Różne wątki bazy danych zwykle używają synchronizacji We / Wy dla dziennika i asynchronizacji We / Wy dla danych. Narzędzie IOPS zajmuje się tym, mierząc wszystkie odpowiednie rozmiary bloków, zaczynając od 512 bajtów.

• Czy czytasz lub piszesz? Zazwyczaj czytanie jest szybsze niż pisanie. Należy jednak pamiętać, że buforowanie działa w zupełnie inny sposób w przypadku odczytu i zapisu:

  • W przypadku zapisów dane zostaną przekazane do kontrolera, a jeśli buforuje, potwierdzi, zanim dane znajdą się na dysku, chyba że pamięć podręczna jest pełna. Za pomocą narzędzia iozone możesz narysować piękne wykresy płaskości efektów pamięci podręcznej (efekt pamięci podręcznej procesora i efekt pamięci podręcznej bufora). Bufory stają się mniej wydajne, im więcej zostało napisanych.

  • W przypadku odczytów odczytane dane są przechowywane w pamięci podręcznej po pierwszym odczycie. Pierwsze odczyty trwają najdłużej, a buforowanie staje się coraz bardziej skuteczne podczas przestojów. Zauważalne pamięci podręczne to pamięć podręczna procesora, pamięć podręczna systemu plików systemu operacyjnego, pamięć podręczna kontrolera IO i pamięć podręczna pamięci. Narzędzie IOPS mierzy tylko odczyty. To pozwala mu „czytać w każdym miejscu” i nie chcesz, żeby pisał zamiast czytać.

• Ile wątków użyjesz : Jeśli użyjesz jednego wątku ( używając dd do testów porównawczych dysków ), prawdopodobnie uzyskasz znacznie gorszą wydajność niż w przypadku kilku wątków. Narzędzie IOPS bierze to pod uwagę i odczytuje kilka wątków.

• Jak ważne jest dla Ciebie opóźnienie : patrząc na bazy danych, opóźnienie we / wy staje się niezwykle ważne. Każde polecenie wstawiania / aktualizacji / usuwania SQL zostanie zapisane w dzienniku bazy danych („log” w języku lingo w bazie danych) podczas zatwierdzania, zanim zostanie potwierdzone. Oznacza to, że pełna baza danych może oczekiwać na zakończenie tej operacji we / wy. Pokazuję tutaj, jak zmierzyć średni czas oczekiwania (oczekiwania) za pomocą narzędzia iostat .

• Jak ważne jest dla Ciebie wykorzystanie procesora : Procesor może łatwo stać się wąskim gardłem w wydajności aplikacji. W takim przypadku musisz wiedzieć, ile cykli procesora zostaje spalonych na bajt odczyt / zapis i zoptymalizować w tym kierunku. Może to oznaczać decyzję za / przeciw pamięci flash PCIe w zależności od wyników pomiaru. Ponownie narzędzie iostat może z grubsza oszacować wykorzystanie procesora przez operacje IO.

Jeśli zainstalowałeś PostgreSQL, możesz użyć ich doskonałego testu porównawczego pg_test_fsync . Zasadniczo testuje wydajność synchronizacji zapisu.

W Ubuntu znajdziesz go tutaj: /usr/lib/postgresql/9.5/bin/pg_test_fsync

Wspaniałą rzeczą jest to, że to narzędzie pokazuje, dlaczego dyski SSD dla przedsiębiorstw są warte dodatkowych $.

Możesz użyć fio- wielowątkowego narzędzia do generowania IO . Jest pakowany przez kilka dystrybucji, np. Fedora 25, Debian i OpenCSW.

Narzędzie fio jest bardzo elastyczne, można je łatwo wykorzystać do analizy porównawczej różnych scenariuszy we / wy - w tym scenariuszy równoległych. Pakiet zawiera niektóre przykładowe pliki konfiguracyjne (por. Np /usr/share/doc/fio/examples.). Właściwie mierzy rzeczy, tj. Drukuje również odchylenie standardowe i statystyki ilościowe dla niektórych liczb. Rzeczy, których nie obchodzą niektóre popularne narzędzia do porównywania.

Prosty przykład (sekwencja prostych scenariuszy: sekwencyjny / losowy odczyt / zapis X):

$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz

[randwrite]
rw=randwrite

[randread]
wait_for=randwrite
rw=randread
size=256m

[seqread]
wait_for=randread
rw=read

[seqwrite]
wait_for=seqread
rw=write

Telefon:

# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr  2 21:23:30 2017
  write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
 lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
 |  1.00th=[    2],  5.00th=[    2], 10.00th=[    2], 20.00th=[    7],
 | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   12],
 | 70.00th=[   14], 80.00th=[   16], 90.00th=[   19], 95.00th=[   25],
 | 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
 | 99.99th=[92672]
bw (KB  /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
  cpu          : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued    : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr  2 21:23:30 2017
  read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB  /s): min=  312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]

Pamiętaj, że [global]sekcja ma globalne ustawienia domyślne, które mogą zostać zastąpione przez inne sekcje. Każda sekcja opisuje pracę, nazwa sekcji to nazwa pracy, którą można dowolnie wybierać. Domyślnie różne zadania są uruchamiane równolegle, dlatego powyższy przykład wyraźnie serializuje wykonanie zadania za pomocą wait_forklucza. Ponadto fio używa bloku o wielkości 4 KiB - który również można zmienić. W tym przykładzie bezpośrednio używane jest surowe urządzenie do zadań odczytu i zapisu, dlatego upewnij się, że używasz właściwego urządzenia. Narzędzie obsługuje również używanie pliku / katalogu w istniejących systemach plików.

Inne narzędzia

hdparmNarzędzie zapewnia bardzo prostą odniesienia odczytu, np:

# hdparm -t -T /dev/sdz

Nie zastępuje najnowocześniejszego narzędzia do analizy porównawczej, takiego jak fio, należy go po prostu użyć do pierwszego sprawdzenia wiarygodności. Na przykład, aby sprawdzić, czy zewnętrzny napęd USB 3 nie jest prawidłowo rozpoznawany jako urządzenie USB 2 (wtedy zobaczysz ~ 100 MiB / s vs. ~ 30 MiB / s).

Jak wskazano tutaj , możesz użyć gnome-disks(jeśli używasz Gnome).

Kliknij dysk, który chcesz przetestować, i kliknij „Dodatkowe opcje partycji” (koła). Potem Benchmark Partition. Otrzymasz średni odczyt / zapis w MB / si średni czas dostępu w milisekundach. Uważam to za bardzo wygodne.

To trochę prymitywne, ale działa to w skrócie:

find <path> -type f -print0 | cpio -0o >/dev/null

Za pomocą tej techniki możesz robić ciekawe rzeczy, w tym buforować wszystkie pliki /libi /usr/bin. Możesz również użyć tego w ramach analizy porównawczej:

find / -xdev -type f -print0 | 
sort -R --from0-file=- | 
timeout "5m" cpio -0o >/dev/null

Wszystkie nazwy plików w katalogu głównym są wyszukiwane, sortowane losowo i kopiowane do pamięci podręcznej na maksymalnie 1 minutę. Dane wyjściowe z cpio informują, ile bloków zostało skopiowanych. Powtórz 3 razy, aby uzyskać średnią liczbę bloków na minutę. (Uwaga: operacja znajdowania / sortowania może zająć dużo czasu - znacznie dłużej niż kopiowanie. Lepiej byłoby buforować szukanie / sortowanie i użyć splitdo pobrania próbki plików.)