Odpowiedzi:
Zwykle używam hdparm
do 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ść.
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
-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.
Ja również użyłem dd
tego 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 ddfile
po wykonaniu polecenia. UWAGA: ddfile
to plik przejściowy, którego nie musisz przechowywać, to plik, który dd
zapisuje do ( of=ddfile
), gdy ładuje dysk twardy.
Jeśli potrzebujesz bardziej rygorystycznych testów dysków twardych, możesz użyć Bonnie ++ .
hdparm
też szybkie testy. Jedynym minusem jest to, że tylko porównuje przepustowość odczytu, a wydajność wielu rodzajów urządzeń blokowych (np. RAID, iSCSI) może być bardzo asymetryczna. dd
Działa również w przypadku porównywania wydajności „przed” i „po” na tym samym urządzeniu .
hdparm
+ dd
lub tylko bonnie++
lub wszystkich 3.
(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ć:
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:
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 .
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:
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 $.
postgresql-contrib
pakiecie.
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_for
klucza. 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.
hdparm
Narzę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 /lib
i /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ć split
do pobrania próbki plików.)