NVMe czy SSD SATA na VPS? Czy różnica ma znaczenie?

Czy NVMe ma znaczenie na VPS?

NVMe ma znaczenie na VPS, gdy oprogramowanie wykonuje wiele małych operacji odczytu i zapisu oraz czeka na zakończenie każdej z nich. W przypadku witryny, która udostępnia strony z pamięci podręcznej, lub programu, który większość czasu czeka na sieć, różnica jest niewielka. Nośnik jest tylko jednym z czynników. Hypervisor obsługujący dysk oraz inne maszyny wirtualne korzystające z tego samego hosta wyznaczają rzeczywisty limit dostępnej wydajności.

Co zmienia NVMe i czego nie zmienia

NVMe (non-volatile memory express) nie jest rodzajem pamięci flash. Jest protokołem i połączeniem używanym do uzyskiwania dostępu do pamięci flash. Urządzenie NVMe korzysta z linii PCIe (peripheral component interconnect express) i komunikuje się za pomocą NVMe. Dysk SSD SATA (serial ATA) korzysta z połączenia SATA i komunikuje się za pomocą AHCI (advanced host controller interface). Układy pamięci przechowujące dane mogą być w obu przypadkach identyczne.

Różnice dotyczą dwóch elementów. W obu przypadkach chodzi o ścieżkę poleceń, a nie o samą pamięć masową.

Kolejki. AHCI udostępnia jądru jedną kolejkę poleceń mieszczącą 32 polecenia. NVMe pozwala używać tysięcy kolejek, w praktyce po jednej na każdy rdzeń CPU, a każda z nich może być znacznie głębsza niż 32. Jeden proces odczytujący jeden blok naraz nie zauważy tej różnicy. Baza danych wykonująca jednocześnie 64 odczyty już tak: w przypadku SATA 33. żądanie czeka na wolne miejsce w kolejce, zanim urządzenie w ogóle je zobaczy, natomiast urządzenie NVMe przyjmuje wszystkie żądania i przetwarza je równolegle.

Szerokość łącza. Połączenie SATA III działa z szybkością 6 Gbit/s, co po uwzględnieniu narzutu protokołu daje około 550 MB/s rzeczywistych danych. Jest to stały limit, niezależnie od rodzaju pamięci flash podłączonej za tym łączem. Cztery linie PCIe zapewniają przepustowość kilku gigabajtów na sekundę, więc łącze przestaje być ograniczeniem.

Opóźnienia są obszarem, w którym oczekiwania zwykle są błędne. Przy głębokości kolejki 1, czyli przy jednym żądaniu przetwarzanym w danej chwili, dysk SSD SATA odpowiada na odczyt 4k w około 100–150 mikrosekund. NVMe odpowiada w około 80–100 mikrosekund. Oba rozwiązania są szybkie i różnicy przy jednym żądaniu nie zauważy żadne uruchomione obciążenie. Różnica pojawia się przy współbieżności. Głębokość kolejki, czyli liczba żądań przetwarzanych jednocześnie, decyduje o tym, czy oba nośniki działają podobnie, czy bardzo różnie.

Sieciowa pamięć blokowa jest trzecią klasą rozwiązań i podlega innym ograniczeniom fizycznym. Zapis przechodzi przez sieć do klastra pamięci masowej i zostaje potwierdzony dopiero wtedy, gdy klaster przechowa dane, dlatego jego opóźnienie mierzy się w milisekundach, a nie w mikrosekundach. W zamian za takie opóźnienie uzyskuje się trwałość: wolumin pozostaje dostępny po wycofaniu hosta, do którego był podłączony, oraz można wykonywać jego migawki i zmieniać jego rozmiar.

Typowe publikowane wartości: NVMe, SATA SSD i pamięć masowa sieciowa

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Lokalne urządzenie NVMe osiąga zazwyczaj 184,000 losowych operacji odczytu IOPS 4k (operacji wejścia-wyjścia na sekundę) przy głębokości kolejki 32. W tym samym teście dla dysku SATA SSD podaje się około 90,000. Wynik ograniczają pojedyncza kolejka AHCI i łącze 6 Gbit/s. Sieciowa pamięć blokowa jest zwykle ograniczana przez dostawcę, a nie przez sprzęt. 12,500 to często spotykany udokumentowany limit.

Opóźnienie przedstawia tę samą zależność w jednostce odczuwalnej przez użytkowników. Opóźnienie odczytu p99, czyli opóźnienie najwolniejszych 1 procent żądań, wynosi około 0.4 ms dla lokalnego NVMe i 1.2 ms dla SATA. Po wprowadzeniu sieci do ścieżki rośnie ono do 6.5 ms, czyli ponad dziesięciokrotnie więcej niż dla NVMe.

Odczyty sekwencyjne dają największą różnicę, ale są najmniej użyteczne: 3,400 MB/s w porównaniu z 550 MB/s. Prawie żaden proces na serwerze nie odczytuje jednego dużego pliku od początku do końca z pełną szybkością. Kolumna losowych operacji i kolumna opóźnienia lepiej opisują rzeczywiste działanie bazy danych, kolejki pocztowej lub menedżera pakietów.

Które obciążenia odczuwają wpływ dysku

Jedna zasada wyjaśnia wszystkie te przypadki: obciążenie odczuwa wpływ dysku tylko wtedy, gdy oczekuje na dysk. Linux przechowuje ostatnio używane dane plików w pamięci RAM, w page cache, dlatego drugi odczyt pliku nigdy nie dociera do pamięci masowej. Jeśli working set, czyli faktycznie używane dane, mieści się w pamięci RAM, po pierwszym przejściu odczyty stają się odczytami z pamięci. Zapisy działają inaczej. Każdy zapis, który aplikacja opróżnia za pomocą fsync(), musi zostać zapisany w trwałej pamięci masowej, zanim aplikacja będzie mogła kontynuować działanie.

Operacje zatwierdzające zmiany. PostgreSQL, MySQL i SQLite wywołują fsync() lub fdatasync() podczas zatwierdzania zmian, a każde zatwierdzenie oczekuje na odpowiedź urządzenia. Szybkość zatwierdzania zmian przez jedno połączenie jest zatem określana przez opóźnienie zapisu, a nie przez przepustowość. Urządzenie, które wykonuje flush w czasie 0.2 ms, pozwala na znacznie większą liczbę zatwierdzeń na sekundę niż urządzenie potrzebujące 5 ms. Żadna przepustowość tego nie zmieni. MySQL informuje o tym w error log, gdy flush nie nadąża:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL zgłasza ten problem w wierszach dotyczących checkpointów. Duża wartość sync= oznacza, że sam flush trwał długo:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Operacje obejmujące wiele małych plików. Każdy plik wymaga operacji na metadanych, których nie wymaga jeden duży odczyt sekwencyjny. npm install, git clone dużego repozytorium, rozpakowywanie obrazów kontenerów, magazyn poczty Maildir oraz kopia zapasowa przechodząca przez duże drzewo katalogów spędzają większość czasu na małych losowych operacjach dostępu. Zadanie backupu restic na VPS odczytuje i oblicza hash każdego pliku, którego wcześniej nie widziało, dlatego czas rzeczywisty backupu obejmującego milion plików jest ściśle zależny od opóźnienia losowych odczytów. To samo dotyczy du -sh, który odczytuje wyłącznie metadane.

Dotyczy to również baz danych, które przestają mieścić się w pamięci RAM. Gdy indeks nie mieści się już w page cache, każde wyszukiwanie staje się losowym odczytem, a dysk ponownie znajduje się na ścieżce krytycznej.

Które obciążenia nie odczuwają różnicy związanej z dyskiem

Blog lub mała witryna firmowa. Strony są niewielkie. Pamięć podręczna stron przechowuje je wszystkie po pierwszym żądaniu. Ograniczeniem jest wtedy procesor podczas renderowania lub przepustowość dla zasobów. Stos LAMP na Ubuntu 24.04 obsługujący witrynę o małym ruchu praktycznie nie wykonuje operacji wejścia-wyjścia na dysku po rozgrzaniu pamięci podręcznej.

Strumieniowanie multimediów. Jeden strumień 4K przy 40 Mbit/s odczytuje 5 MB/s. Dziesięć takich strumieni odczytuje 50 MB/s. Tę przepustowość bez problemu zapewnia nawet sieciowa pamięć blokowa. Serwer multimediów Jellyfin na VPS jest ograniczony limitem wychodzącego ruchu sieciowego, a podczas transkodowania także przez procesor, nie przez rodzaj nośnika.

Lokalne wnioskowanie z użyciem modelu. Uruchomienie Ollama na VPS w celu samodzielnego hostowania LLM powoduje jednokrotny odczyt pliku modelu, a następnie model działa w pamięci RAM. NVMe skraca czas ładowania modelu o rozmiarze 20 GB z minut do sekund. Nie zmienia jednak liczby tokenów przetwarzanych na sekundę. Ta wartość zależy od przepustowości pamięci i procesora.

Wszystko, co oczekuje na usługę zewnętrzną. Proces roboczy, który poświęca 800 ms na zadanie na żądanie HTTP, nie będzie działać szybciej na lepszym dysku.

Dlaczego hiperwizor ma znaczenie nie mniejsze niż nośnik

Nie komunikuje się bezpośrednio z urządzeniem. Komunikacja odbywa się z dyskiem wirtualnym udostępnianym przez hiperwizor, zwykle za pośrednictwem virtio. Kilka decyzji na tej warstwie ma większe znaczenie niż wybór między NVMe a SATA.

Z poziomu gościa nie można zobaczyć nośnika. lsblk -d -o NAME,ROTA,SIZE,MODEL pokazuje vda z pustym modelem, ponieważ virtio nie przekazuje identyfikatora dysku. cat /sys/block/vda/queue/rotational raportuje informacje reklamowane przez hiperwizor, dlatego wartość 0 nie potwierdza użycia pamięci flash. nvme list z pakietu nvme-cli nie wyświetla niczego na większości VPS, nawet gdy host jest wyposażony w dyski NVMe, ponieważ używany dysk jest urządzeniem virtio, a nie urządzeniem NVMe. Informacja NVMe w ofercie zwykle opisuje wyposażenie hosta. Wolumen może nadal być podłączony przez sieć.

Tryb pamięci podręcznej hosta wpływa na wyniki bardziej niż nośnik. Przy włączonym buforowaniu writeback na hoście operacja fsync() w gościu może zakończyć się natychmiast po zapisaniu danych przez hosta w jego własnej pamięci RAM. Taki wynik testu wydajności może być nieosiągalny dla żadnego fizycznego urządzenia. Oznacza to również, że awaria hosta może spowodować utratę zapisów, które baza danych uznaje za bezpieczne. Przy trybie pamięci podręcznej none wyniki są niższe i wiarygodne.

Limity i kredyty burst. Wielu dostawców ogranicza liczbę IOPS na wolumen lub w ramach planu. Wiele wolumenów sieciowych korzysta także z limitu burst. Limit burst to pula kredytów. Wolumen działa z dużą szybkością do wyczerpania kredytów, a następnie przechodzi na znacznie niższy poziom bazowy. Objaw jest łatwy do rozpoznania. Import lub przywracanie działa szybko przez kilka minut, a następnie wyraźnie zwalnia i pozostaje wolne, mimo że w konfiguracji niczego nie zmieniono. Kredyty zostały wykorzystane.

Inne maszyny wirtualne. Na współdzielonym hoście opóźnienie dysku zmienia się zależnie od operacji wykonywanych przez inne maszyny gościa. Z tego powodu należy wykonywać pomiary więcej niż jeden raz. Ten sam test należy uruchomić rano, a następnie ponownie wieczorem i porównać rozrzut wyników. Na obciążonym hoście różnica między dwoma uruchomieniami na tym samym wolumenie często jest większa niż opublikowana różnica między dwoma nośnikami.

Jak zmierzyć rzeczywistą pojemność dysku VPS

Należy zainstalować fio, standardowe narzędzie do testowania operacji wejścia-wyjścia, a następnie wykonać pomiary. Najpierw należy uwzględnić trzy kwestie. Test tworzy plik, więc zużywa miejsce na dysku i jest uwzględniany w każdym limicie IOPS, za który pobierana jest opłata. Uruchomienia powinny być krótkie. Nie należy uruchamiać testu z pełną głębokością kolejki na woluminie obsługującym ruch produkcyjny, ponieważ aplikacja będzie konkurować z testem o zasoby.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Losowy odczyt z głębokością kolejki 32, czyli wartością podawaną przez dostawców:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

Istotny wiersz zaczyna się od read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 pomija pamięć podręczną stron systemu gościa, dlatego wynik opisuje urządzenie, a nie pamięć RAM. Po pominięciu tego parametru mierzona jest pamięć, która zwraca wartość niemożliwą do osiągnięcia przez dysk. Należy użyć wartości --size=4G lub większej, jeśli dostępne jest wystarczająco dużo miejsca, ponieważ plik o rozmiarze 1G może w całości zmieścić się w pamięci podręcznej hosta i zawyżyć wynik.

Głębokość kolejki 1 pokazuje rzeczywiste opóźnienie, odczuwane przez proces jednowątkowy:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

Test zatwierdzania pozwala przewidzieć zachowanie bazy danych. Zapisuje dane o rozmiarze 4k i po każdym zapisie wywołuje fdatasync(), dlatego raportowana szybkość obejmuje opróżnianie bufora:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

Wartość IOPS z tego uruchomienia jest zbliżona do maksymalnej liczby małych transakcji na sekundę, które może zatwierdzić jedno połączenie z bazą danych, ponieważ zatwierdzenie oczekuje na to samo opróżnienie bufora.

Szybki pomiar bez użycia fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

Wartość mdev, czyli odchylenie średnie, jest równie istotna jak średnia. Duże odchylenie na bezczynnym serwerze oznacza, że zaplecze pamięci masowej jest współdzielone i obciążone.

Jak odczytywać wynik

Stan na lipiec 2026: poniższe wartości są typowe dla małego VPS. Kilkadziesiąt tysięcy IOPS dla losowych odczytów 4k przy głębokości kolejki 32, z opóźnieniem przy głębokości kolejki 1 poniżej około 0.3 ms, wskazuje na lokalną pamięć flash. Opóźnienie przy głębokości kolejki 1 wynoszące kilka milisekund oznacza ścieżkę sieciową, niezależnie od nazwy planu. Odczyty sekwencyjne zatrzymujące się w pobliżu 550 MB/s wskazują na połączenie SATA. Wartość znacznie wyższa niż możliwości dowolnego pojedynczego urządzenia oznacza, że po drodze działa buforowanie, prawie zawsze na hoście.

Aby sprawdzić, jak bieżące obciążenie wpływa na dysk:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

W danych wyjściowych iostat -x należy odczytać r_await i w_await, czyli średni czas oczekiwania żądania wyrażony w milisekundach, oraz aqu-sz, czyli średnią długość kolejki. Na dysku wirtualnym należy pominąć %util. Wartość ta określa udział czasu, w którym oczekuje co najmniej jedno żądanie. Nie informuje ona o nasyceniu urządzenia obsługującego wiele żądań jednocześnie. Dlatego wartość %util wynosząca 100 wraz z r_await równym 0.2 ms oznacza prawidłowo obciążony dysk. W vmstat kolumna wa określa procent czasu CPU spędzanego na oczekiwaniu na IO. Jeśli w jądrze dostępna jest wartość /proc/pressure/io, jej wartość some avg10= oznacza udział ostatnich 10 sekund, w których co najmniej jedno zadanie było zablokowane podczas operacji IO. Jest to najbardziej bezpośrednia odpowiedź na pytanie, czy pamięć masowa stanowi wąskie gardło.

Jak wygląda VPS ograniczony przez dysk

Wysoka średnia obciążenia przy bezczynności procesora i duża wartość wa w vmstat oznaczają, że procesy oczekują za dyskiem. Najwyraźniejszym sygnałem z jądra jest ten komunikat w dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

Ten wiersz pojawia się, ponieważ wątek jądra czekał ponad dwie minuty na odpowiedź urządzenia pamięci masowej, dlatego monitor zawieszonych zadań zarejestrował ten komunikat. jbd2 to wątek dziennika ext4, co oznacza, że oczekiwał cały system plików, a nie jeden nieprawidłowo działający program. W przypadku VPS zwykle wskazuje to na backend pamięci masowej albo na wyczerpanie przydziału IOPS.

Objawy po stronie aplikacji mają taki sam charakter. Mediana czasu odpowiedzi pozostaje akceptowalna, ale najwolniejsze żądania tworzą długi ogon, ponieważ koszt oczekiwania na dysk ponoszą tylko żądania, które uzyskują do niego dostęp. apt upgrade pozostaje przez kilka minut na etapie Unpacking, ponieważ dpkg opróżnia bufory podczas zapisu. Wyszukiwanie git status w dużym repozytorium trwa kilka sekund. Są to koszty operacji na metadanych i opróżniania buforów, dlatego większa przepustowość nie pomoże.

Co zrobić, gdy ograniczeniem jest dysk

Najpierw zwiększ ilość pamięci RAM, a dopiero potem kupuj więcej IOPS. Jeśli zbiór roboczy mieści się w pamięci podręcznej stron, odczyty w ogóle nie docierają do dysku. Podwojenie pamięci często daje większą korzyść niż przejście na szybszą klasę pamięci masowej i zwykle kosztuje mniej.

Ogranicz liczbę operacji opróżniania buforów, jeśli pozwalają na to wymagania dotyczące danych. W PostgreSQL synchronous_commit = off pozwala zwrócić wynik zatwierdzenia, zanim zapis zostanie wykonany na dysku. W razie awarii serwera można utracić transakcje z ostatniego ułamka sekundy. Baza danych nie zostanie uszkodzona, ponieważ dziennik wyprzedzającego zapisu nadal jest zapisywany w odpowiedniej kolejności. To rozwiązanie jest właściwe dla kopii analitycznej, ale niewłaściwe dla płatności. innodb_flush_log_at_trx_commit = 2 w MySQL zapewnia ten sam kompromis.

Grupuj małe pliki w archiwa. Transfer lub kopia zapasowa miliona małych plików jest zdominowana przez koszt obsługi poszczególnych plików. Dlatego na pamięci masowej o dużych opóźnieniach szybsze jest wcześniejsze zarchiwizowanie plików i przeniesienie jednego strumienia niż kopiowanie drzewa plik po pliku.

Zapewnij działanie discard na woluminach thin provisioning. W przypadku pamięci masowej z thin provisioning zaplecze nie wie, że blok jest wolny, dopóki system plików tego nie zgłosi. Wolumin, na którym nigdy nie wykonuje się operacji trim, stopniowo traci wydajność zapisu. Ubuntu udostępnia w tym celu cotygodniowy timer:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av wyświetla liczbę bajtów zwolnionych przez trim dla każdego punktu montowania. Komunikat informujący, że operacja discard nie jest obsługiwana, oznacza, że dysk wirtualny nie przekazuje discard do hosta. Nie ma wtedy niczego, co można naprawić po stronie systemu.

Pomiń dostrajanie planisty IO. Na dysku virtio polecenie cat /sys/block/vda/queue/scheduler zwykle pokazuje, że none jest już ustawione, a właściwe planowanie odbywa się na hoście, do którego nie masz dostępu. Pomiń również noatime. Ubuntu domyślnie montuje systemy plików z opcją relatime, która już eliminuje prawie wszystkie zapisy atime.

Wybór planu

Warto zapłacić za NVMe, gdy na serwerze działa baza danych, serwer pocztowy, CI runner lub kompilacja wymagająca wielu pakietów. Nie należy płacić dodatkowej ceny za buforowaną witrynę ani za aplikację, której czas działania jest zdominowany przez wywołania zewnętrzne. W razie wątpliwości dysk prawdopodobnie nie stanowi ograniczenia, ponieważ większości małych obciążeń VPS najpierw brakuje pamięci RAM lub przepustowości.

Pomiary należy wykonać pierwszego dnia, podczas pracy z pierwszymi dziesięcioma minutami na nowym VPS, a wyniki zapisać w pliku. Punkt odniesienia pozwala później wykazać, że host działa wolniej, a nie że problem wynika z kodu. Należy preferować dostawców, którzy podają na piśmie klasę pamięci masowej oraz ewentualny limit IOPS. Jeżeli plan określa pamięć jako NVMe, a odczyt przy queue depth 1 trwa 4 ms, oznacza to pamięć sieciową na hoście wyposażonym w NVMe. Jest to uzasadniona oferta sprzedaży, ale inny produkt do zakupu.

FAQ

Czy NVMe jest zawsze szybsze niż dysk SSD SATA na VPS?

Nie. Przy głębokości kolejki 1 oba rozwiązania są zbliżone i zapewniają około 80 do 150 mikrosekund dla odczytu 4k, dlatego program jednowątkowy nie pozwala ich rozróżnić. NVMe uzyskuje przewagę, gdy wiele żądań jest przetwarzanych równocześnie, ponieważ AHCI udostępnia jedną kolejkę o głębokości 32 poleceń, a NVMe udostępnia tysiące głębszych kolejek. Na współdzielonym hoście obciążenie generowane przez inne instancje może zmienić opóźnienia bardziej niż sam nośnik, dlatego należy zmierzyć własny wolumin za pomocą fio, zamiast kierować się nazwą planu.

Jak sprawdzić, czy mój VPS rzeczywiście korzysta z NVMe?

Nie można sprawdzić tego bezpośrednio, ponieważ virtio ukrywa urządzenie fizyczne. lsblk wyświetla vda bez ciągu modelu, nvme list niczego nie zwraca, a /sys/block/vda/queue/rotational zgłasza tylko informacje udostępniane przez hypervisor. Należy zamiast tego zmierzyć działanie systemu. Losowy odczyt 4k przy głębokości kolejki 1 i opóźnieniu poniżej około 0.3 ms oznacza lokalną pamięć flash. Kilka milisekund oznacza, że na ścieżce znajduje się połączenie sieciowe. Odczyty sekwencyjne zatrzymujące się w pobliżu 550 MB/s wskazują na połączenie SATA.

Czy NVMe przyspiesza ładowanie mojej witryny?

Zwykle nie. Po pierwszym żądaniu Linux obsługuje pliki z page cache w pamięci RAM, więc dysk przestaje być aktywnie używany. Szybkość ładowania strony na małym VPS jest zazwyczaj ograniczana przez czas procesora aplikacji i przepustowość. Dysk ponownie trafia na ścieżkę krytyczną, jeśli witryna zapisuje dane przy każdym żądaniu, na przykład gdy koszyk oparty na bazie danych często zatwierdza transakcje, ponieważ każde zatwierdzenie oczekuje na zakończenie operacji flush.

Jaki wynik fio jest dobry dla VPS?

W lipcu 2026 mały VPS korzystający z lokalnej pamięci flash zazwyczaj osiąga dziesiątki tysięcy IOPS losowego odczytu 4k przy głębokości kolejki 32 oraz opóźnienie poniżej 0.3 ms przy głębokości kolejki 1. Sieciowa pamięć blokowa zazwyczaj osiąga kilka tysięcy IOPS przy opóźnieniu rzędu kilku milisekund. Test należy wykonać trzy razy o różnych porach. Duża różnica między wynikami poszczególnych uruchomień mówi więcej niż średnia, ponieważ pokazuje, w jakim stopniu inne instancje na hoście wpływają na system.

Czy należy umieścić bazę danych w sieciowej pamięci blokowej?

Można to zrobić i wiele usług zarządzanych tak postępuje, ale ścieżka zatwierdzania ponosi związane z tym koszty. Każda operacja flush przechodzi przez sieć, dlatego pojedyncze połączenie zatwierdza mniej małych transakcji na sekundę niż w przypadku lokalnej pamięci flash. W zamian uzyskuje się trwałość danych, która przetrwa awarię hosta. W przypadku wyboru pamięci sieciowej dla bazy danych intensywnie zapisującej dane należy grupować operacje w większe transakcje, aby mniejsza liczba operacji flush obejmowała więcej wierszy.