Testy dysków SSD: jak mierzyć IOPS i opóźnienia, a nie tylko MB/s

Dlaczego MB/s to za mało przy ocenie SSD

Przepustowość sekwencyjna a rzeczywiste obciążenia

W specyfikacjach dysków SSD dominuje jeden parametr: przepustowość sekwencyjna, zwykle podawana w MB/s dla odczytu i zapisu. Ten wskaźnik mówi, jak szybko dysk potrafi przesyłać duże, ciągłe porcje danych – na przykład podczas kopiowania filmu czy obrazu ISO. Problem w tym, że większość aplikacji nie pracuje na jednym wielkim pliku, tylko na setkach tysięcy małych operacji wejścia/wyjścia (I/O).

System operacyjny, baza danych, wirtualizacja, logi – w tych scenariuszach dominuje dostęp losowy i małe bloki danych. Tu liczy się nie tyle przepustowość w MB/s, ile liczba obsłużonych operacji na sekundę (IOPS) i opóźnienie</strong) każdej z nich. Dysk, który w testach sekwencyjnych wygląda znakomicie, może w losowym 4K wypaść gorzej niż starszy, ale lepiej zaprojektowany model.

MB/s bywa więc mylące: pokazuje jak dysk radzi sobie w wąskiej, „laboratoryjnej” sytuacji, a nie w tym, co rzeczywiście dzieje się na serwerze produkcyjnym lub stacji roboczej. Dodatkowo producenci podają te wartości dla wysokiej głębokości kolejki (QD) i idealnych warunków, podczas gdy desktop czy pojedyncza aplikacja często pracuje przy QD1–QD4.

Przykład: serwer bazodanowy z „dobrym” SSD i fatalną responsywnością

Typowy scenariusz: ktoś kupuje serwer z SSD opisywanym jako „do 3500 MB/s odczytu”, instaluje bazę danych, a aplikacja biznesowa nadal reaguje ospale. Prosty CrystalDiskMark pokazuje świetne sekwencyjne odczyty i zapisy, więc winę przypisuje się bazie, programistom albo sieci. Po głębszym sprawdzeniu wychodzi na jaw, że losowy odczyt 4K przy QD1 ma olbrzymie opóźnienia i bardzo przeciętne IOPS.

Baza danych nie czyta jednego wielkiego pliku liniowo. Otwiera tysiące małych stron danych, wykonuje mnóstwo krótkich zapisów logów transakcyjnych. Dla takiego obciążenia znaczenie mają:

• latencja pojedynczej operacji (w mikrosekundach lub milisekundach),
• stabilność opóźnień – brak skoków i „czkawki” I/O,
• wydajność przy małych blokach (np. 4K, 8K, 16K) i losowym dostępie.

Jeśli test ograniczy się tylko do sekwencyjnego MB/s, tę słabość da się łatwo przeoczyć. Serwer „dusi się” nie z braku przepustowości, tylko przez zbyt wysokie i niestabilne opóźnienia przy typowym profilu pracy bazy.

Typowe scenariusze pracy SSD a znaczenie IOPS i opóźnień

Przy wyborze i testowaniu SSD dobrze jest przełożyć swój przypadek użycia na profil I/O. Kilka typowych przykładów wygląda tak:

• Dysk systemowy (desktop/laptop) – dominują krótkie losowe odczyty 4K i 8K przy QD1–QD4: start systemu, uruchamianie aplikacji, wczytywanie bibliotek, plików konfiguracyjnych. Tu najbardziej odczuwalne jest niskie opóźnienie przy małym QD, a nie rekordowy sekwencyjny odczyt 1M.
• Serwer wirtualizacji (hypervisor, VM) – wiele maszyn generuje losowe I/O w różnych rozmiarach bloków. Liczy się zdolność SSD do obsługi dużej liczby IOPS przy rosnącej głębokości kolejki (QD32 i więcej) oraz stabilność opóźnień nawet przy obciążeniu.
• Baza danych – losowy odczyt/zapis małych bloków odpowiadających rozmiarowi stron DB (np. 8K, 16K), dodatkowo osobne obciążenie na logi transakcyjne (zapis sekwencyjny małych bloków, często synchroniczny). Tu o wydajności decyduje głównie latency i IOPS losowe, nie sekwencyjne MB/s.
• Serwer plików / multimedia – tu sekwencyjny odczyt i zapis może mieć większe znaczenie, szczególnie przy dużych plikach wideo, backupach, obrazach ISO. Wciąż jednak wiele operacji metadanych (małe pliki, katalogi) to losowe I/O.

Widać wyraźnie, że parametr MB/s opisuje dobrze tylko część tych zastosowań. W większości przypadków kluczowe są IOPS i opóźnienia, zwłaszcza dla małych bloków i niskiej głębokości kolejki.

Kiedy MB/s naprawdę jest ważne, a kiedy wprowadza w błąd

Sekwencyjna przepustowość ma znaczenie w kilku sytuacjach:

• kopiowanie dużych plików (backupy, archiwa, obrazy ISO),
• montaż wideo i praca na strumieniach o wysokim bitrate,
• przesyłanie dużych datasetów między dyskami lub serwerami,
• zapis i odczyt logów analitycznych w dużych porcjach danych.

W tych zastosowaniach testy MB/s pokazują realną różnicę: szybszy odczyt sekwencyjny skróci czas kopiowania backupu czy eksportu bazy. Jednak w momencie, gdy użytkownik narzeka na „lagujące” aplikacje, wolne otwieranie programów, cofające się transakcje czy zacinające się VM, prawie zawsze problem leży w opóźnieniach i IOPS, a nie w sekwencyjnym MB/s.

Dlatego testy dysków SSD powinny być projektowane tak, aby mierzyć parametry ważne dla realnego obciążenia. Sam wynik „do 7000 MB/s” jest dobry na etykietkę marketingową, ale w izolacji niewiele mówi o tym, jak dysk zachowa się pod Twoim konkretnym profilem pracy.

Podstawowe pojęcia: IOPS, opóźnienia, QD, losowy vs sekwencyjny

IOPS, opóźnienia i czas odpowiedzi – fundament testów SSD

IOPS (Input/Output Operations Per Second) to liczba operacji wejścia/wyjścia, jaką dysk przeprowadza w ciągu sekundy. Może chodzić o odczyt, zapis lub ich mieszankę. Zwykle podaje się IOPS dla konkretnego profilu: np. losowy odczyt 4K, losowy zapis 4K, sekwencyjny odczyt 128K.

Opóźnienie (latency) to czas, jaki mija od wysłania żądania I/O przez system operacyjny do otrzymania odpowiedzi z dysku. Czasem spotyka się też określenie czas odpowiedzi (response time) w tym samym znaczeniu. Opóźnienia raportuje się w mikrosekundach (µs) lub milisekundach (ms).

IOPS i opóźnienia są ze sobą ściśle powiązane. Przy niskiej głębokości kolejki (QD1) można w prosty sposób oszacować teoretyczne IOPS z latencji:

• latencja 1 ms → maksymalnie około 1000 IOPS dla QD1,
• latencja 0,1 ms → maksymalnie około 10 000 IOPS dla QD1,
• latencja 0,01 ms → maksymalnie około 100 000 IOPS dla QD1.

Przy wyższej głębokości kolejki dysk może mieć wiele zapytań w locie, więc całkowita liczba IOPS rośnie, mimo że pojedyncza operacja wciąż ma to samo lub nieco większe opóźnienie. Z tego powodu same IOPS bez kontekstu QD i latencji to tylko połowa obrazu.

Queue Depth (QD) – dlaczego ta liczba zmienia wszystko

Queue Depth (QD) opisuje, ile operacji I/O jednocześnie czeka w kolejce do obsłużenia przez dysk. QD1 oznacza, że zawsze jest tylko jedno żądanie w toku – zanim system wyśle kolejne, czeka na zakończenie poprzedniego. QD32 oznacza, że dysk ma w buforze do 32 żądań, którymi może żonglować i optymalizować ich obsługę.

W praktyce:

• desktop, pojedyncza aplikacja, dysk systemowy – często pracują w okolicach QD1–QD4,
• serwer wirtualizacji, macierz, intensywne systemy DB – potrafią dochodzić do QD32, QD64 i wyżej.

Nowoczesne SSD, zwłaszcza NVMe, pokazują pełnię możliwości dopiero przy wysokiej głębokości kolejki. Stąd biorą się imponujące liczby IOPS w specyfikacjach: np. „do 1 000 000 IOPS losowy odczyt 4K przy QD32”. Jednak to nie znaczy, że przy QD1 ten sam dysk jest równie imponujący. Zdarza się, że model o świetnym wyniku przy QD32 ma bardzo przeciętne opóźnienia przy QD1 i w domowym PC nie daje odczuwalnej poprawy względem tańszego konkurenta.

Losowy vs sekwencyjny odczyt i zapis

Sekwencyjny odczyt/zapis oznacza operacje na danych ułożonych ciągiem – adresy bloków są kolejne: po LBA 1000 przychodzi 1001, 1002, itd. Dysk może wtedy optymalizować dostęp, duże bloki przenoszą się bardzo efektywnie. Stąd wysokie prędkości w MB/s dla plików wideo, obrazów ISO itp.

Losowy odczyt/zapis to operacje na blokach rozrzuconych po różnych adresach, bez przewidywalnego porządku. To najbardziej wymagający scenariusz dla kontrolera i pamięci flash, bo utrudnia optymalizację wewnętrznych translacji adresów i zarządzania komórkami NAND.

W praktyce większość systemów generuje mieszankę obu rodzajów obciążeń. Jednak dla wydajności systemu operacyjnego, baz danych i VM kluczowy jest losowy dostęp do małych bloków. Stąd takie nacisk na testy random 4K, 8K, 16K – to one pokazują, jak dysk będzie się zachowywał w codziennej pracy systemu, a nie tylko podczas kopiowania filmów.

Rozmiar bloku: 4K, 8K, 1M i ich wpływ na wyniki

Każda operacja I/O dotyczy jakiegoś rozmiaru bloku danych. Najczęściej spotykane rozmiary w testach to:

• 4K – często używany jako reprezentant małych, losowych operacji (strony systemu plików, małe pliki, metadane),
• 8K, 16K – typowe rozmiary stron niektórych baz danych, realne obciążenia serwerowe,
• 64K, 128K – większe bloki, kompromis między losowością a wydajnością,
• 512K, 1M – bardzo duże bloki dla testów sekwencyjnych (przepustowość w MB/s).

Im większy blok, tym niższe IOPS, ale wyższa przepustowość MB/s, bo jedna operacja I/O „przenosi” więcej danych. Dla małych bloków 4K IOPS potrafi być bardzo wysokie, ale całkowita przepustowość w MB/s będzie wyglądała skromnie. To normalne i wynika bezpośrednio z prostego przeliczenia:

MB/s = (IOPS × rozmiar bloku w bajtach) / (1024 × 1024)

Przykładowo, 50 000 IOPS przy 4K to około 195 MB/s, natomiast 10 000 IOPS przy 1M to już około 10 000 MB/s. Patrzenie tylko na MB/s bez kontekstu rozmiaru bloku może prowadzić do błędnych wniosków o „szybkości” dysku.

Jak czytać liczby z kart katalogowych producenta

W specyfikacjach SSD najczęściej pojawiają się następujące dane:

• sekwencyjny odczyt/zapis (MB/s) – zwykle dla dużych bloków 128K–1M i wysokiego QD,
• losowy odczyt/zapis 4K (IOPS) – często przy QD32, QD64,
• czasem informacja o latencji (rzadziej, ale się zdarza),
• warunki testu: konkretny benchmark, system operacyjny, pojemność.

Te wartości nie są kłamstwem, ale przedstawiają idealny scenariusz laboratoryjny. Aby przenieść je na swój przypadek użycia, trzeba zadać kilka pytań:

• przy jakim QD wykonywano test IOPS? Czy mój system kiedykolwiek osiągnie taką kolejkę?
• jak wygląda wydajność dla QD1–QD4, małych bloków i mieszanki read/write?
• czy podane IOPS dotyczą tylko odczytu, czy także zapisu, który jest zwykle trudniejszy dla flash?
• czy test obejmował długotrwałe obciążenie, gdy zapełni się SLC cache i wejdzie w grę „prawdziwe” TLC/QLC?

Bez odpowiedzi na te kwestie liczby z broszury są jedynie orientacyjnym punktem wyjścia. Rzetelne testy SSD muszą symulować rzeczywiste obciążenia, a nie tylko odtwarzać marketingowy profil producenta.

Jak dobrać scenariusz testu do zastosowania SSD

Mapowanie typu aplikacji na profil I/O

Największym błędem przy testowaniu SSD jest uruchomienie losowego „benchmarka” bez zastanowienia, co ten dysk robi w praktyce. Dużo lepszy efekt daje proste ćwiczenie: przełożyć typ aplikacji na profil I/O, który da się odwzorować w narzędziu takim jak fio.

Przykładowe mapowanie może wyglądać tak:

• Desktop / laptop (system + aplikacje):
  • 70–90% odczyt, 10–30% zapis,
  • losowe 4K–32K,
  • QD1–QD4, czasem krótkie piki wyżej.
• Serwer plików:
  • mieszanka odczytu i zapisu, często z przewagą odczytu,

  Przykładowe profile I/O dla różnych zastosowań

  Dla kilku typowych ról dysku można jasno zdefiniować profil, który później odwzorujesz w benchmarku.

  • Serwer plików:
    • mieszanka odczytu i zapisu (np. 60–80% read, reszta write),
    • rozmiary bloków 4K–1M, zależnie od typu plików (małe dokumenty vs duże multimedia),
    • QD od 1–2 (niewielu użytkowników) do 16–32 (serwer dla wielu klientów / CIFS / NFS).
  • Serwer baz danych OLTP:
    • najczęściej przewaga zapisu logów + mieszany read/write danych,
    • bloki 8K–16K, czasem 4K (w zależności od silnika DB),
    • QD średnio 4–32, ale z krótkimi pikami wyżej,
    • duża wrażliwość na latencje pojedynczych operacji, nie tylko na średnią.
  • Serwer wirtualizacji (VMware, Proxmox, Hyper-V):
    • mocno losowy read/write, bo wiele VM „miesza” I/O na jednym LUN,
    • bloki 4K–64K, różne profile w zależności od gości (Windows, Linux, DB, aplikacje),
    • QD sumarycznie wysokie (kilkadziesiąt lub więcej),
    • ważne: stabilne IOPS i opóźnienia przy długotrwałym obciążeniu, nie krótkie piki.
  • Rendering / montaż wideo / obróbka grafiki:
    • dominują duże, sekwencyjne odczyty/zapisy (64K–1M),
    • QD1–QD8, zależnie od liczby strumieni i aplikacji,
    • istotne jest utrzymanie stałej przepustowości bez gwałtownych spadków.
  • Logi, monitoring, systemy analityczne:
    • wysoki udział małych zapisów (4K–16K), często quasi-sekwencyjnych,
    • read/write zależny od typu narzędzia (np. Elastic mocno miesza),
    • QD średnie do wysokich (wiele źródeł logów),
    • ważna jest nie tylko średnia latencja, ale i ogon (99., 99,9. percentyl).

  Jeśli nie jesteś pewien, jaki profil generuje aplikacja, użyj krótkiej obserwacji przy pomocy narzędzi systemowych: na Linuxie iostat, pidstat, blktrace, na Windows Resource Monitor i perfmon. Kilkanaście minut realnej pracy aplikacji pozwoli złapać rozkład rozmiarów bloków, stosunek read/write i typowe QD.

  Projektowanie scenariuszy testowych krok po kroku

  Żeby testy miały sens, ułóż je w kilku prostych krokach.

  1. Zdefiniuj profil obciążenia:
     • określ udział odczytu i zapisu (np. 80% read / 20% write),
     • zidentyfikuj kilka typowych rozmiarów bloków (np. 4K i 32K),
     • ustal realistyczny zakres QD (np. QD1–QD4 dla desktopu, QD1–QD32 dla serwera).
  2. Podziel testy na krótkie i długie:
     • krótkie (30–60 s) do szybkiego rozeznania i wychwycenia podstawowych różnic,
     • długie (5–30 min) do obserwacji zachowania po zapchaniu cache i nagrzaniu dysku.
  3. Uwzględnij różne typy pracy:
     • czysty odczyt (read-only),
     • czysty zapis (write-only) – żeby zobaczyć najgorszy scenariusz,
     • mieszane read/write (np. rw=randrw, rwmixread=70).
  4. Zapewnij rozgrzanie dysku:
     • zanim zapiszesz wyniki, uruchom krótki preconditioning (np. 1–2 min losowego zapisu),
     • przy dyskach TLC/QLC ważne, żeby wyjść poza „świeży” SLC cache.
  5. Powtórz testy co najmniej 2–3 razy:
     • wyłapiesz rozrzut wyników i ewentualne anomalie,
     • sprawdzisz, czy dysk nie degraduje po pierwszym „ładnym” przebiegu.

  Narzędzia do testowania SSD: fio, ioping, CrystalDiskMark i inne

  fio – szwajcarski scyzoryk do I/O

  fio to najbardziej elastyczne narzędzie do testowania I/O, szczególnie w środowiskach serwerowych i Linux. Pozwala precyzyjnie opisać profil obciążenia, generuje szczegółowe raporty i CSV/JSON do dalszej analizy.

  Najważniejsze cechy w kontekście SSD:

  • obsługa różnych typów obciążeń: randread, randwrite, randrw, read, write, rw,
  • kontrola rozmiaru bloku (bs), głębokości kolejki (iodepth), liczby wątków (numjobs),
  • raportowanie pełnej statystyki opóźnień, percentyli, IOPS, MB/s,
  • możliwość preconditioning (długotrwały zapis całego dysku przed właściwym testem),
  • profile w plikach .fio – łatwo odtworzyć i porównać testy na różnych maszynach.

  Na Linuxie najczęściej instalacja sprowadza się do:

  sudo apt install fio        # Debian/Ubuntu
  sudo dnf install fio        # Fedora/RHEL
  sudo pacman -S fio          # Arch

  ioping – „ping” dla dysków

  ioping działa podobnie jak ping dla sieci: wysyła małe operacje I/O i mierzy czas odpowiedzi. Idealny do szybkiej oceny latencji i sprawdzenia, czy coś „przytyka” dysk.

  • łatwe testy opóźnień dla pojedynczych bloków,
  • możliwość testowania bufora cache vs realnego urządzenia (opcje -A, -D),
  • dobry do wykrywania chwilowych „lagów” – nagłych skoków latencji.

  Przykładowe użycie:

  # prosty test opóźnień w danym katalogu (filesystem-level)
  ioping .
  
  # test bez użycia cache systemowego (direct I/O)
  ioping -D /mnt/ssd

  CrystalDiskMark – klasyka pod Windows

  CrystalDiskMark to najczęściej używany tester dysków pod Windows, szczególnie wśród użytkowników desktop. Daje szybki podgląd sekwencyjnych MB/s i podstawowych IOPS dla losowych obciążeń.

  Kluczowe profile:

  • SEQ1M Q8T1 – duże, sekwencyjne bloki 1M przy QD8 i 1 wątku, dobrze pokazuje maksymalne MB/s,
  • RND4K Q32T16 – losowe bloki 4K przy wysokiej QD i wielu wątkach, raczej scenariusz „laboratoryjny”,
  • RND4K Q1T1 – losowe 4K przy QD1, właśnie ten test jest najbardziej zbliżony do odczuć użytkownika.

  CrystalDiskMark nie daje takiej kontroli jak fio, ale do szybkiego porównania dysków systemowych na Windows jest wystarczający. Do głębszej analizy IOPS/latency na Windows warto sięgnąć po fio skompilowane dla tego systemu.

  Inne przydatne narzędzia i wbudowane benchmarki

  Poza powyższymi narzędziami przydają się też:

  • hdparm (Linux) – prosty test sekwencyjnego odczytu, raczej do szybkiego sanity check:

  sudo hdparm -tT /dev/nvme0n1

  • diskspd (Windows) – narzędzie Microsoftu, zbliżone do fio pod względem elastyczności,
  • wbudowane benchmarki w narzędziach producentów (Samsung Magician, WD Dashboard) – zwykle marketingowe profile, ale mogą pokazać, czy dysk działa zgodnie z deklaracjami.

  

  Przygotowanie środowiska do testów SSD

  Oddzielenie dysku testowego od systemu

  Najczęstszy błąd: testowanie dysku systemowego w czasie normalnej pracy. System, logi, antywirus i inne procesy wtrącają własne I/O, zakłócając wyniki.

  Bezpieczniejsze podejścia:

  • testowanie dysku, który nie zawiera systemu (dodatkowy SSD w desktopie/serwerze),
  • boot z innego nośnika (np. LiveCD, drugi SSD) i test wyłącznie badanego urządzenia,
  • przy systemie produkcyjnym – testowanie na osobnym LUN / wolumenie, w oknie serwisowym.

  Wyłączenie zbędnych procesów i usług

  Podczas testów lokalnych dobrze jest ograniczyć „szum” w tle:

  • zatrzymaj zadania indeksowania (Windows Search, tracker itp.),
  • wstrzymaj skanowanie antywirusa na czas testów,
  • wyłącz automatyczne backupy, synchronizacje (OneDrive, Dropbox, Google Drive).

  W środowisku serwerowym zrób testy w oknie, gdy obciążenie od użytkowników jest minimalne, albo najlepiej na maszynie wydzielonej tylko do benchmarków.

  Ustawienia systemu plików i tryb dostępu

  Testy można prowadzić na dwa sposoby:

  • na urządzeniu blokowym (np. /dev/nvme0n1) – pomijasz system plików, mierzysz „gołe” urządzenie,
  • na systemie plików (np. /mnt/ssd/testfile) – bliżej realnego użycia, ale wyniki obejmują też narzut FS.

  Dla powtarzalnych testów IOPS/latency dysku warto używać bezpośredniego dostępu blokowego z direct=1 w fio, żeby ominąć cache systemowy.

  Spójność konfiguracji sprzętu

  Przy porównywaniu dysków trzeba zadbać, by reszta konfiguracji nie wprowadzała ograniczeń:

  • ten sam slot / interfejs (np. oba dyski NVMe w PCIe 4.0 x4, a nie jeden w x2),
  • wyłączone / ustawione identycznie tryby oszczędzania energii (link power management, ASPM),
  • aktualne firmware dysków, stabilna wersja BIOS/UEFI,
  • w miarę możliwości podobna temperatura otoczenia i identyczne chłodzenie (radiatory).

  Wstępne „przygotowanie” SSD przed pomiarem

  Świeżo po wyjęciu z pudełka SSD często pokazuje wyniki dalekie od codzienności. Kontroler ma puste tablice translacji, SLC cache jest w pełni dostępne, garbage collector praktycznie nic nie robi.

  Dobrą praktyką jest:

  • wypełnienie dysku danymi do 80–90% pojemności (jeden duży plik lub preconditioning fio),
  • uruchomienie kilkunastu minut losowego zapisu przed właściwymi testami,
  • jeśli testujesz długofalową stabilność – powtórzenie takich cykli kilka razy.

  Konfiguracja i uruchamianie testów IOPS i opóźnień w fio

  Podstawowa składnia fio dla SSD

  Najprostszy test losowego odczytu 4K na całym urządzeniu NVMe (Linux):

  sudo fio --name=randread_4k_qd1 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=randread 
    --bs=4k 
    --iodepth=1 
    --numjobs=1 
    --time_based 
    --runtime=60 
    --group_reporting

  Co tu jest kluczowe:

  • --direct=1 – omija cache systemowy, mierzy urządzenie,
  • --rw=randread – losowy odczyt,
  • --bs=4k – rozmiar bloku 4K,
  • --iodepth=1 – QD1 (głębokość kolejki dla jednego wątku),
  • --numjobs=1 – pojedynczy wątek,
  • --time_based --runtime=60 – test 60 sekund zamiast określonej ilości danych.

  Symulowanie wyższej kolejki i wielu wątków

  Jeśli chcesz odwzorować serwer wirtualizacji lub intensywną bazę danych, zwiększ iodepth i liczbę zadań:

  Przykłady profili fio dla typowych zastosowań

  Po pojedynczym teście QD1 przychodzi czas na scenariusze zbliżone do realnych obciążeń. Kilka gotowych profili dobrze sprawdza się jako punkt startowy.

  Profil „desktop / system operacyjny” – losowe 4K, niska kolejka

  System operacyjny, przeglądarka, komunikatory – dominują losowe I/O przy małej kolejce. Profil:

  sudo fio --name=desktop_4k_mix 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=randrw 
    --rwmixread=70 
    --bs=4k 
    --iodepth=2 
    --numjobs=2 
    --time_based 
    --runtime=120 
    --group_reporting

  • --rw=randrw + --rwmixread=70 – 70% odczytu, 30% zapisu,
  • iodepth=2, numjobs=2 – lekkie zwiększenie równoległości, nadal blisko typowego desktopu,
  • czas 120 s – więcej próbek opóźnień, łatwiej zauważyć „lagi”.

  Profil „baza danych / OLTP” – małe bloki, wyższa kolejka

  Dla baz danych liczą się małe bloki, powtarzalne opóźnienia i dobra obsługa średnich QD.

  sudo fio --name=db_8k_randrw 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=randrw 
    --rwmixread=60 
    --bs=8k 
    --iodepth=16 
    --numjobs=4 
    --time_based 
    --runtime=300 
    --group_reporting

  • bs=8k – zbliżone do typowych rozmiarów stron w DB,
  • iodepth=16, numjobs=4 – łącznie do 64 outstanding I/O,
  • dłuższy czas (300 s) – szansa, że SLC cache przestanie „upiększać” wynik.

  Profil „maszyny wirtualne” – większa mieszanka rozmiarów

  Środowiska wirtualizacji łączą różne typy operacji – od małych bloków po sekwencyjne kopiowanie plików.

  sudo fio --name=vm_mixed 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=randrw 
    --rwmixread=50 
    --bs=4k 
    --bssplit=4k/60:8k/20:64k/20 
    --iodepth=32 
    --numjobs=8 
    --time_based 
    --runtime=300 
    --group_reporting

  Tu kluczowe jest --bssplit – mieszanka bloków 4K, 8K, 64K, która lepiej przypomina realne I/O niż pojedynczy rozmiar sektora.

  Użycie plików jobfile w fio

  Zamiast przeklejać długie komendy, wygodniej trzymać profile w plikach. Przykładowy jobfile:

  [global]
  ioengine=libaio
  direct=1
  time_based=1
  runtime=180
  group_reporting=1
  filename=/dev/nvme0n1
  
  [randread_qd1]
  rw=randread
  bs=4k
  iodepth=1
  numjobs=1
  
  [randread_qd32]
  rw=randread
  bs=4k
  iodepth=32
  numjobs=4

  Uruchomienie:

  sudo fio ssd_profile.fio

  Dzięki sekcji [global] wspólne parametry definiujesz raz, a poszczególne joby różnią się tylko kluczowymi detalami.

  Rejestrowanie wyników do CSV/JSON

  Do porównań między dyskami przydają się surowe dane, nie tylko podsumowanie w konsoli.

  sudo fio --name=randread_4k_qd1 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=randread 
    --bs=4k 
    --iodepth=1 
    --numjobs=1 
    --time_based 
    --runtime=60 
    --group_reporting 
    --output=randread_4k_qd1.json 
    --output-format=json

  Plik JSON można potem wrzucić do własnego skryptu w Pythonie, R czy choćby Excela i porównać percentyle, jitter czy spadki wydajności w czasie.

  Interpretacja rezultatów: IOPS, opóźnienia, percentyle, jitter

  IOPS i MB/s w kontekście rozmiaru bloku

  Najpierw trzeba spojrzeć, co było testowane. 100k IOPS przy 4K to coś innego niż 100k IOPS przy 64K.

  • IOPS × rozmiar bloku ≈ MB/s – wysokie IOPS przy małych blokach niekoniecznie oznacza szczytowe MB/s,
  • porównuj IOPS tylko dla tego samego bs, iodepth, numjobs i typu rw,
  • dla desktopu patrz głównie na losowe 4K QD1–QD4, dla serwera – także na średnie/wysokie QD.

  Średnie opóźnienie vs percentyle

  Średnia latencja bywa myląca. Dysk może mieć ładną średnią, ale co kilka sekund pojedyncze operacje trwają wielokrotnie dłużej i to właśnie je czujesz jako „zacięcia”.

  W typowym raporcie fio widać:

  • lat (usec/msec) min/avg/max – min, średnia i maksymalne opóźnienie,
  • clat percentiles – tabela percentyli, kluczowe są 95., 99., 99.9.

  Praktyczne podejście:

  • do codziennej pracy najważniejszy jest przedział do p95 – im niżej, tym system „bardziej responsywny”,
  • p99 i p99.9 mówią, jak bolesne są rzadkie piki; tu widać różnicę między dobrym NVMe a tanim QLC,
  • max latency zwykle jest ekstremum – przydatne głównie do polowania na poważne problemy (np. sekundy pauzy).

  Histogramy i rozrzut (jitter)

  Fio potrafi zapisać histogram opóźnień, co ułatwia zauważenie, czy latencja trzyma się jednego zakresu, czy „rozjeżdża się” w dwie grupy.

  sudo fio job.fio --write_hist_log=latency_log

  Seria plików latency_log_*.log pokaże rozkład w czasie. Jeśli linia z czasem odpowiedzi jest w miarę płaska, dysk zachowuje się przewidywalnie. Schodki, ząbki i regularne piki często oznaczają:

  • włączone oszczędzanie energii (dysk wybudza się z głębokich stanów),
  • GC/trim, który rusza co pewien czas z większą intensywnością,
  • inne procesy w systemie, które robią I/O „obok” testu.

  Porównywanie wyników między dyskami

  Żeby porównanie miało sens, trzeba mieć identyczny profil i podobny stan dysków (zapełnienie, temperatura, firmware).

  Prosty schemat:

  1. Uruchom ten sam jobfile na dwóch dyskach, zapisując wyniki do JSON.
  2. Wyciągnij z każdego:
     • IOPS read/write,
     • avg latency,
     • p95 i p99 (read i write osobno).
  3. Porównaj proporcje, nie tylko „kto ma więcej”.

  Często wychodzi sytuacja: Dysk A ma o 10–20% wyższe IOPS, ale p99 latencji jest dwukrotnie lepsze. W praktyce wolę ten drugi, bo system jest wyraźnie płynniejszy.

  SLC cache, throttling termiczny i inne pułapki testów SSD

  Jak działa SLC cache i kiedy zniekształca wyniki

  Większość współczesnych SSD TLC/QLC używa SLC cache – część pamięci zachowuje się jak szybkie SLC, potem dane są „przepisywane” do docelowych komórek.

  Podczas krótkich testów zapisu:

  • operacje trafiają do szybkiego bufora,
  • kontroler raportuje wysokie MB/s i IOPS,
  • realna wydajność „głębokiej” pamięci TLC/QLC pozostaje niewidoczna.

  Żeby zobaczyć zachowanie poza cache:

  • wykonaj długi, ciągły zapis (kilka–kilkanaście minut) lub zapis dużej ilości danych,
  • obserwuj wykres MB/s w czasie – charakterystyczny spadek to moment wyczerpania SLC cache,
  • powtórz test po krótkiej przerwie – cache może się częściowo „odbudować”.

  Przykładowy test „przebicia” SLC cache

  Prosty test sekwencyjnego zapisu, który zwykle wyjeżdża poza cache:

  sudo fio --name=slc_bust 
    --filename=/dev/nvme0n1 
    --direct=1 
    --rw=write 
    --bs=1M 
    --iodepth=32 
    --numjobs=1 
    --time_based 
    --runtime=900 
    --group_reporting 
    --log_avg_msec=1000 
    --write_bw_log=slc_bust

  Plik slc_bust_bw.1.log można potem wrzucić do gnuplota albo Excela. Na osi X czas, na Y MB/s. Szukaj momentu, w którym transfer nagle spada i stabilizuje się na niższym poziomie.

  Thermal throttling – kiedy temperatura psuje wyniki

  NVMe bez radiatora w ciasnej obudowie potrafi szybko przekroczyć temperaturę, przy której kontroler obcina wydajność.

  Sygnalizacje typowego throttlingu w testach:

  • w pierwszych minutach bardzo dobre MB/s i IOPS, potem liniowy spadek,
  • latencja rośnie „schodkowo”, zwykle w tym samym czasie co temperatura,
  • w logach SMART/NVMe pojawiają się liczniki throttlingu.

  Jak to wychwycić:

  • monitoruj temperaturę równolegle z fio – np. watch -n 1 "sudo nvme smart-log /dev/nvme0n1 | grep -i temp",
  • przy dyskach SATA – smartctl -A /dev/sdX | grep -i temp,
  • zapisz parametry z kilku punktów w trakcie dłuższego testu.

  Przy poważniejszych testach dobrze mieć radiator i sensowny przepływ powietrza. W serwerach często pomagają dodatkowe wentylatory kierujące strumień powietrza wprost na moduły NVMe.

  Wpływ zapełnienia dysku na IOPS i opóźnienia

  Im bardziej zapełniony SSD, tym więcej pracy ma kontroler FTL i garbage collector. To przekłada się na wyższe opóźnienia i spadek IOPS, szczególnie dla zapisu.

  Schemat prostego eksperymentu:

  1. Przetestuj dysk „pusty” – po secure erase lub TRIM całego urządzenia.
  2. Wypełnij go do ~80–90% losowymi danymi.
  3. Uruchom ten sam profil fio (np. losowe 4K QD1 i QD32).

  Różnica w p95/p99 dla zapisu potrafi być duża. Przy QLC przy wysokim zapełnieniu średnia też potrafi solidnie wzrosnąć.

  Over-provisioning i jego wpływ na stabilność

  Niektórzy producenci zostawiają spory zapas niewidocznej przestrzeni (OP), inni tną go do minimum. Można też ręcznie powiększyć OP, np. tworząc mniejszą partycję niż pełna pojemność dysku.

  Efekty zwiększonego OP:

  • stabilniejsza wydajność zapisu pod stałym obciążeniem,
  • mniejsza wrażliwość na zapełnienie (mniej dramatyczny spadek po 80–90%),
  • często lepsze p95/p99 dla losowego zapisu.

  Jeśli porównujesz dwa dyski, zadbaj o podobny poziom „wolnej” przestrzeni. Inaczej jeden będzie w praktyce działał z większym OP i wynik okaże się nieuczciwy.

  TRIM, garbage collection i „ładne” testy po odpoczynku

  SSD w spoczynku wykonuje dużo wewnętrznej pracy: zbiera śmieci, porządkuje mapy bloków, przygotowuje wolne strony. Po dłuższej przerwie wyniki pierwszego testu potrafią być lepsze niż kolejnych uruchamianych bez pauzy.

  Żeby zobaczyć zachowanie bliższe rzeczywistości:

  • wykonaj serię kilku testów bez długich przerw,
  • nie uruchamiaj ręcznie pełnego TRIM pomiędzy krótkimi scenariuszami, jeśli w produkcji tak nie robisz,
  • jeśli testujesz „najlepszy możliwy scenariusz” – jasno to zaznacz; to inny profil niż „steady-state”.

  Kontroler, firmware i wersje sterowników

  Dwa dyski tej samej serii, ale z różnym firmware, potrafią zachowywać się inaczej. Podobnie różne sterowniki NVMe (zwłaszcza pod Windows) zmieniają latencje i obsługę kolejek.

  Prosta checklista przed porównaniem:

  • sprawdź i ujednolić firmware SSD,
  • zanotuj wersję kernela (Linux) lub sterownika NVMe (Windows),

  Najczęściej zadawane pytania (FAQ)

  Co to jest IOPS w dysku SSD i dlaczego jest ważniejsze niż MB/s?

  IOPS (Input/Output Operations Per Second) to liczba operacji odczytu lub zapisu, które dysk jest w stanie obsłużyć w ciągu sekundy. Chodzi o pojedyncze „strzały” I/O, często na małych blokach danych, a nie o ciągłe przesyłanie dużych plików.

  W codziennej pracy systemu (start systemu, otwieranie aplikacji, praca przeglądarki, bazy danych) dominuje dostęp losowy i małe operacje. W takich scenariuszach IOPS i opóźnienia mają większy wpływ na odczuwalną szybkość niż maksymalne MB/s deklarowane przez producenta.

  Co jest ważniejsze przy wyborze SSD: IOPS, opóźnienia czy MB/s?

  Do zwykłego kopiowania dużych plików (filmy, ISO, backupy) ważne są MB/s, bo liczy się przepustowość sekwencyjna. Gdy jednak SSD ma obsługiwać system operacyjny, gry, maszyny wirtualne czy bazę danych, priorytetem stają się IOPS i opóźnienia przy małych, losowych operacjach.

  Praktyczna zasada:

  • SSD na system i aplikacje – patrz na IOPS (4K losowy odczyt/zapis) oraz średnie opóźnienie.
  • SSD na magazyn dużych plików – patrz głównie na sekwencyjne MB/s.

  Jak samodzielnie zmierzyć IOPS i opóźnienia SSD w Windows lub Linux?

  W systemie Windows najczęściej używa się narzędzi takich jak CrystalDiskMark, ATTO, Anvil czy Iometer. Ustawiasz małe bloki (np. 4K), dostęp losowy (random), różne poziomy kolejkowania (QD1, QD4, QD32) i odczytujesz wyniki IOPS oraz latency.

  W Linuksie do testów I/O sprawdzają się fio lub ioping. W przypadku fio definiujesz:

  • rodzaj obciążenia (read/write/randread/randwrite/mixed),
  • wielkość bloku (np. 4k),
  • głębokość kolejki i czas trwania testu.

  Na tej podstawie fio raportuje IOPS, opóźnienia (min/avg/max) i przepustowość.

  Dlaczego dysk z wysokimi MB/s nadal „muli” przy starcie systemu lub odpalaniu programów?

  Start systemu, logowanie użytkownika, uruchamianie przeglądarki czy IDE to tysiące małych, losowych odczytów. W takiej sytuacji nie korzystasz z maksymalnej przepustowości sekwencyjnej, tylko z tego, jak szybko dysk obsługuje małe operacje (IOPS) i z jakim opóźnieniem.

  Jeśli SSD ma słabe IOPS przy małych blokach i wysokie opóźnienia pod obciążeniem, system może „czekać” na dane, mimo że w benchmarku sekwencyjnym osiąga bardzo wysokie MB/s.

  Jak interpretować wyniki IOPS w testach SSD (np. 4K random)?

  Przy testach 4K random zwróć uwagę na trzy rzeczy:

  • liczbę IOPS – im wyższa, tym lepiej w obciążeniach losowych,
  • średnie opóźnienie (latency) – niższe wartości przekładają się na bardziej responsywny system,
  • poziom kolejki (QD) – wysokie IOPS przy QD32 nie zawsze oznaczają dobre wyniki przy QD1–QD4, które częściej odpowiadają pracy desktopa.

  Dla typowego komputera biurowego/gamingowego bardziej miarodajne są wyniki dla małych QD (1–4). Świetne liczby przy QD32–64 są ważniejsze w serwerach i intensywnych systemach bazodanowych.

  Czym różni się test sekwencyjny SSD od testu losowego i kiedy który ma znaczenie?

  Test sekwencyjny mierzy prędkość przy odczycie/zapisie dużych, ciągłych bloków danych (np. 1 MB, 4 MB), od początku do końca. To odzwierciedla kopiowanie filmów, obrazów ISO, dużych backupów.

  Test losowy bada wydajność przy małych blokach rozrzuconych po całym nośniku (np. 4K random). Taki wzorzec pasuje do pracy systemu operacyjnego, baz danych, VM-ek i logów. W typowym użyciu systemu Windows czy Linuksa to testy losowe lepiej pokazują realne odczucia z pracy.

  Jak dobrać SSD do bazy danych lub wirtualizacji pod kątem IOPS i opóźnień?

  W środowiskach bazodanowych i wirtualizacyjnych kluczowe są:

  • wysokie IOPS przy małych blokach (4K, 8K) dla odczytu i zapisu,
  • niskie i stabilne opóźnienia pod obciążeniem (nie tylko „średnie”, ale też 99. percentyl),
  • dobra wydajność przy mieszanych obciążeniach (read/write mix, np. 70/30).

  W praktyce sprawdź:

  • benchmarki dla scenariuszy „random 4K read/write” przy różnych QD,
  • jak dysk zachowuje się po dłuższym obciążeniu (spadek IOPS, skoki opóźnień),
  • czy kontroler i firmware są znane z dobrej pracy pod ciągłym, losowym I/O (opinie adminów, testy serwerowe).

  To bardziej miarodajne niż same deklarowane MB/s.

  Najważniejsze punkty

  • Sam parametr MB/s opisuje głównie kopiowanie dużych, ciągłych plików (np. filmów, obrazów ISO), więc pokazuje tylko część możliwości SSD.
  • Typowe obciążenia w systemach operacyjnych, bazach danych czy maszynach wirtualnych to dostęp losowy i małe bloki danych, a nie długie sekwencyjne transfery.
  • W takich realnych scenariuszach kluczowe są IOPS (liczba operacji I/O na sekundę) oraz opóźnienie pojedynczej operacji, a nie maksymalna przepustowość w MB/s.
  • Dwa dyski o podobnych MB/s mogą działać zupełnie inaczej pod obciążeniem losowym – jeden „dusi się” przy wielu małych plikach, drugi wciąż pracuje płynnie.
  • Przy wyborze SSD do pracy z systemem, bazami czy logami trzeba patrzeć na wydajność losową i parametry opóźnień, bo to one decydują o szybkości działania aplikacji.
  • Testowanie SSD tylko przez kopiowanie dużych plików daje złudny obraz – nie pokaże, jak dysk zachowa się przy tysiącach małych zapisów i odczytów równocześnie.