NVMe czy SSD na VPS: czy warto dopłacać?

Czy NVMe ma znaczenie na VPS?

NVMe ma znaczenie na VPS, gdy oprogramowanie wykonuje wiele małych operacji odczytu i zapisu, czekając na zakończenie każdej z nich. Zmiana jest nieznaczna w przypadku serwisu serwującego strony z pamięci podręcznej lub programu, który większość czasu oczekuje na odpowiedź sieci. Nośnik jest tylko jednym z czynników. Hypervisor zarządzający dyskiem oraz inni goście współdzielący ten sam host wyznaczają rzeczywisty limit wydajności.

Co zmienia NVMe, a czego nie zmienia

NVMe (non-volatile memory express) nie jest rodzajem pamięci flash. Jest to protokół i połączenie służące do komunikacji z pamięcią flash. Urządzenie NVMe korzysta z linii PCIe (peripheral component interconnect express) i obsługuje protokół NVMe. Dysk SSD typu SATA (serial ATA) wykorzystuje łącze SATA i obsługuje protokół AHCI (advanced host controller interface). Układy pamięci przechowujące dane mogą być identyczne w obu przypadkach.

Różnice dotyczą dwóch kwestii i obie odnoszą się do ścieżki przesyłania poleceń, a nie do samego nośnika danych.

Kolejki. AHCI udostępnia jądru systemu jedną kolejkę poleceń, która mieści 32 polecenia. NVMe pozwala na tworzenie tysięcy kolejek, w praktyce jednej na każdy rdzeń procesora, z których każda jest znacznie głębsza niż 32. Proces odczytujący jeden blok danych na raz nie odczuje tej różnicy. Baza danych z 64 oczekującymi operacjami odczytu już tak: w przypadku SATA 33. żądanie czeka na wolne miejsce w kolejce, zanim urządzenie w ogóle je otrzyma, podczas gdy urządzenie NVMe przyjmuje je wszystkie i przetwarza równolegle.

Przepustowość łącza. Łącze SATA III działa z prędkością 6 Gbit/s, co po uwzględnieniu narzutu protokołu daje około 550 MB/s rzeczywistych danych. Jest to sztywny limit, niezależnie od tego, jakie pamięci flash znajdują się za nim. Cztery linie PCIe przenoszą kilka gigabajtów na sekundę, więc łącze przestaje być wąskim gardłem.

Opóźnienia to obszar, w którym oczekiwania są zazwyczaj błędne. Przy głębokości kolejki 1, co oznacza jedno żądanie w trakcie przetwarzania, dysk SSD SATA odpowiada na odczyt 4k w czasie od około 100 do 150 mikrosekund. NVMe odpowiada w czasie od około 80 do 100. Oba rozwiązania są szybkie i żadna uruchamiana aplikacja nie zauważy różnicy przy pojedynczym żądaniu. Przepaść pojawia się przy współbieżności. Głębokość kolejki, czyli liczba żądań przetwarzanych jednocześnie, jest ustawieniem decydującym o tym, czy oba nośniki będą wydawać się podobne, czy też bardzo różne.

Sieciowa pamięć masowa blokowa to trzecia klasa rozwiązań o innej charakterystyce fizycznej. Zapis przechodzi przez sieć do klastra pamięci masowej i jest potwierdzany dopiero wtedy, gdy klaster go przyjmie, dlatego opóźnienia mierzy się tu w milisekundach, a nie mikrosekundach. Ceną za te opóźnienia jest trwałość: wolumen przetrwa awarię hosta, do którego jest podłączony, a ponadto można tworzyć jego migawki i zmieniać 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 operacji IOPS (operacji wejścia/wyjścia na sekundę) przy losowym odczycie 4k i głębokości kolejki 32. Ten sam test dla dysku SATA SSD wskazuje wartość w okolicach 90,000, co wynika z ograniczeń pojedynczej kolejki AHCI oraz łącza 6 Gbit/s. Sieciowa pamięć blokowa jest zazwyczaj ograniczona przez dostawcę, a nie przez sprzęt, przy czym 12,500 stanowi często dokumentowany limit górny.

Opóźnienia wyrażają to samo w jednostkach odczuwalnych dla użytkowników. Opóźnienie odczytu p99, oznaczające 1 procent najwolniejszych żądań, wynosi około 0.4 ms dla lokalnego NVMe oraz 1.2 ms dla SATA. Dodanie sieci do ścieżki przesyłu zwiększa tę wartość do 6.5 ms, czyli ponad dziesięciokrotnie więcej niż w przypadku NVMe.

Odczyty sekwencyjne wykazują największą różnicę, będąc jednocześnie najmniej użytecznym wskaźnikiem: 3,400 MB/s w porównaniu do 550 MB/s. Prawie żadna usługa serwerowa nie odczytuje pojedynczego dużego pliku od początku do końca z pełną prędkością. Kolumny dotyczące operacji losowych oraz opóźnień lepiej opisują rzeczywiste działanie bazy danych, kolejki poczty czy menedżera pakietów.

Które obciążenia odczuwają wydajność dysku

Jedna zasada wyjaśnia wszystkie te przypadki: obciążenie odczuwa dysk tylko wtedy, gdy na niego oczekuje. Linux przechowuje ostatnio używane dane plików w pamięci RAM, w tzw. page cache, więc drugie odczytanie pliku nigdy nie dociera do nośnika. Jeśli zestaw roboczy, czyli dane faktycznie używane, mieści się w pamięci RAM, odczyty stają się operacjami na pamięci po pierwszym przejściu. Zapisy działają inaczej. Każdy zapis, który aplikacja wymusza za pomocą fsync(), musi znaleźć się na trwałym nośniku, zanim aplikacja będzie mogła kontynuować pracę.

Praca wymagająca zatwierdzenia (commit). PostgreSQL, MySQL i SQLite wywołują fsync() lub fdatasync() podczas zatwierdzania transakcji, a każde zatwierdzenie czeka na odpowiedź urządzenia. Szybkość zatwierdzania dla jednego połączenia jest zatem określana przez opóźnienie zapisu (latency), a nie przez przepustowość (bandwidth). Urządzenie, które wykonuje flush w czasie 0.2 ms, pozwala na znacznie więcej zatwierdzeń na sekundę niż takie, które potrzebuje 5 ms, i żadna zmiana przepustowości tego nie zmieni. MySQL informuje o tym w dzienniku błędów, gdy operacja flush nie nadąża:

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

PostgreSQL raportuje to w liniach checkpoint, gdzie duża wartość sync= oznacza, że sama operacja flush była powolna:

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

Praca operująca na wielu małych plikach. Każdy plik wiąże się z operacjami na metadanych, których nie ma przy jednym dużym odczycie sekwencyjnym. npm install, git clone dużego repozytorium, rozpakowywanie obrazów kontenerów, magazyn poczty Maildir oraz tworzenie kopii zapasowej przeszukującej duże drzewo katalogów – wszystkie te zadania spędzają czas na losowym dostępie do małych danych. Zadanie kopii zapasowej restic na VPS odczytuje i haszuje każdy plik, którego wcześniej nie widziało, więc rzeczywisty czas wykonania kopii zapasowej miliona plików ściśle zależy od opóźnień losowego odczytu. To samo dotyczy du -sh, które odczytuje wyłącznie metadane.

Do tej kategorii należą również bazy danych, które przekraczają rozmiar pamięci RAM. Gdy indeks przestaje mieścić się w page cache, każde wyszukiwanie staje się losowym odczytem, a dysk ponownie staje się wąskim gardłem.

Które obciążenia nie odczuwają wydajności dysku

Blog lub witryna małej firmy. Strony są niewielkie, pamięć podręczna (page cache) przechowuje je wszystkie po pierwszym żądaniu, a ograniczeniem jest procesor (CPU) podczas renderowania lub przepustowość łącza dla zasobów. Stos LAMP na Ubuntu 24.04 obsługujący witrynę o niskim ruchu niemal 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 generuje odczyt na poziomie 5 MB/s. Dziesięć takich strumieni to 50 MB/s, co jest wartością obsługiwaną bez trudu nawet przez sieciowe pamięci masowe typu block storage. Serwer multimediów Jellyfin na VPS jest ograniczony limitem transferu wychodzącego sieci oraz mocą procesora podczas transkodowania, a nie nośnikiem danych.

Lokalna inferencja modeli. Uruchomienie Ollama na VPS w celu hostowania LLM powoduje jednorazowy odczyt pliku modelu, po czym praca odbywa się w pamięci RAM. NVMe skraca czas ładowania modelu o rozmiarze 20 GB z minut do sekund. Nie wpływa to jednak na liczbę generowanych tokenów na sekundę, która zależy od przepustowości pamięci i procesora.

Wszelkie zadania oczekujące na usługę zewnętrzną. Proces roboczy (worker), który spędza 800 ms na każde zadanie oczekując na żądanie HTTP, nie przyspieszy dzięki szybszemu dyskowi.

Dlaczego hypervisor jest równie ważny co nośnik danych

Komunikacja nigdy nie odbywa się bezpośrednio z urządzeniem. System operacyjny gościa korzysta z wirtualnego dysku prezentowanego przez hypervisor, zazwyczaj za pośrednictwem virtio. Decyzje podjęte na tej warstwie mają większe znaczenie niż wybór między NVMe a SATA.

Wewnątrz systemu gościa nie można zobaczyć fizycznego nośnika. lsblk -d -o NAME,ROTA,SIZE,MODEL wyświetla vda z pustym modelem, ponieważ virtio nie przekazuje identyfikatora dysku. cat /sys/block/vda/queue/rotational raportuje informacje dostarczane przez hypervisor, więc wartość 0 nie stanowi dowodu na użycie pamięci flash. nvme list, pochodzące z pakietu nvme-cli, na większości VPS nie zwraca żadnych danych, nawet jeśli host korzysta z dysków NVMe. Wynika to z faktu, że dysk jest urządzeniem typu virtio, a nie NVMe. Oferta wspominająca o NVMe zazwyczaj opisuje jedynie specyfikację hosta. Wolumen może być nadal podłączony przez sieć.

Tryb pamięci podręcznej hosta wpływa na wyniki bardziej niż sam nośnik. Przy włączonym buforowaniu typu writeback na hoście, operacja fsync() w systemie gościa kończy się w momencie zapisania danych w pamięci RAM hosta. Generuje to wyniki testów wydajnościowych, których nie osiągnie żadne fizyczne urządzenie. Oznacza to również, że awaria hosta może spowodować utratę zapisów, które baza danych uznała za bezpieczne. W trybie pamięci podręcznej none wyniki są niższe, ale odzwierciedlają rzeczywisty stan.

Limity i kredyty wydajności (burst). Wielu dostawców ogranicza IOPS dla wolumenu lub planu, a wiele wolumenów sieciowych korzysta z mechanizmu burst. Jest to pula kredytów: wolumen pracuje z wysoką wydajnością, dopóki kredyty są dostępne, a następnie zwalnia do znacznie niższego poziomu bazowego. Objawy tego zjawiska są łatwe do rozpoznania. Import lub przywracanie danych przebiega szybko przez kilka minut, po czym gwałtownie zwalnia i pozostaje na niskim poziomie, mimo braku zmian w konfiguracji. Kredyty zostały wyczerpane.

Sąsiedztwo na hoście. Na współdzielonym hoście opóźnienia dysku zmieniają się w zależności od aktywności innych gości. Jest to powód, dla którego pomiary należy wykonywać wielokrotnie. Ten sam test warto przeprowadzić rano i wieczorem, a następnie porównać rozbieżności. Na obciążonym hoście różnica między dwoma uruchomieniami testu na tym samym wolumenie jest często większa niż deklarowana różnica wydajności między dwoma typami nośników.

Jak zmierzyć rzeczywistą wydajność dysku VPS

Zainstaluj fio, standardowe narzędzie do testów IO, i wykonaj pomiar. Najpierw trzy ostrzeżenia. Test tworzy plik, więc zużywa miejsce na dysku i wlicza się do limitów IOPS, za które płacisz. Wykonuj krótkie testy. Nie uruchamiaj testu z pełną głębokością kolejki na wolumenie obsługującym aktywny ruch, ponieważ będziesz konkurować z własną aplikacją.

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

Odczyt losowy przy głębokości kolejki 32, czyli wartości podawanej 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

Istotna linia zaczyna się od read:

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

--direct=1 pomija pamięć podręczną systemu gościa, więc wynik opisuje urządzenie, a nie pamięć RAM. Pomiń ten parametr, a zmierzysz pamięć, co zwróci wynik nieosiągalny dla żadnego dysku. Użyj --size=4G lub większego pliku, jeśli masz miejsce, ponieważ plik 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 surowe opóźnienie, czyli to, czego doświadcza 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 commit przewiduje zachowanie bazy danych. Zapisuje 4k i wywołuje fdatasync() po każdym zapisie, więc raportowana szybkość uwzględnia operację flush:

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 testu jest zbliżona do maksymalnej liczby małych transakcji na sekundę, jakie może zatwierdzić jedno połączenie z bazą danych, ponieważ commit oczekuje na to samo opróżnienie bufora.

Dla szybkiego sprawdzenia bez 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 średnie odchylenie, jest równie istotna co średnia. Duże odchylenie na bezczynnym serwerze oznacza, że backend pamięci masowej jest współdzielony i obciążony.

Jak interpretować wyniki

Według stanu na lipiec 2026 r. są to rozsądne odczyty dla małego serwera VPS. Dziesiątki tysięcy operacji IOPS przy losowym odczycie 4k i głębokości kolejki 32 oraz opóźnienie poniżej około 0,3 ms przy głębokości kolejki 1 są typowe dla lokalnej pamięci flash. Opóźnienie rzędu kilku milisekund przy głębokości kolejki 1 oznacza obecność sieci w ścieżce dostępu, niezależnie od nazwy planu taryfowego. Odczyty sekwencyjne kończące się w okolicach 550 MB/s są charakterystyczne dla interfejsu SATA. Wynik znacznie przewyższający możliwości pojedynczego urządzenia oznacza, że w ścieżce znajduje się warstwa buforowania, niemal zawsze po stronie hosta.

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 zwrócić uwagę na r_await oraz w_await, czyli średni czas oczekiwania żądania w milisekundach, oraz aqu-sz, czyli średnią długość kolejki. W przypadku dysku wirtualnego należy zignorować %util. Wartość ta informuje o udziale czasu, w którym oczekiwało co najmniej jedno żądanie, co nie mówi nic o nasyceniu urządzenia obsługującego wiele żądań jednocześnie. Dlatego %util na poziomie 100 przy r_await wynoszącym 0,2 ms oznacza, że dysk pracuje poprawnie. W vmstat kolumna wa określa procent czasu procesora spędzonego na oczekiwaniu na operacje wejścia-wyjścia. Jeśli w używanym jądrze dostępna jest wartość /proc/pressure/io, to jej parametr some avg10= wskazuje udział czasu z ostatnich 10 sekund, w którym przynajmniej jedno zadanie było wstrzymane z powodu operacji IO. Jest to najbardziej bezpośrednia odpowiedź na pytanie, czy pamięć masowa stanowi wąskie gardło systemu.

Jak rozpoznać VPS ograniczony wydajnością dysku

Wysoki wskaźnik load average przy niskim użyciu CPU oraz duża wartość wa w vmstat oznaczają, że procesy oczekują w kolejce na dostęp do dysku. Najbardziej czytelnym sygnałem z jądra jest poniższy 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 oczekiwał ponad dwie minuty na odpowiedź nośnika, co zostało zarejestrowane przez mechanizm hung task watchdog. jbd2 to wątek dziennika ext4, co oznacza, że cały system plików był w stanie oczekiwania, a nie tylko jeden nieprawidłowo działający program. Na VPS zazwyczaj wskazuje to na problemy z backendem pamięci masowej lub wyczerpanie limitu IOPS.

Objawy w aplikacjach wykazują ten sam wzorzec. Mediana czasu odpowiedzi pozostaje akceptowalna, podczas gdy najwolniejsze żądania generują długi czas oczekiwania, ponieważ koszt ponoszą tylko te żądania, które wymagają operacji dyskowych. apt upgrade pozostaje w stanie rozpakowywania przez minuty, ponieważ dpkg wykonuje operacje flush podczas zapisu. git status w dużym repozytorium trwa sekundy. Są to koszty metadanych i operacji flush, więc zwiększenie przepustowości nie przyniesie poprawy.

Co zrobić, gdy ograniczeniem jest dysk

Zwiększ ilość pamięci RAM przed zakupem IOPS. Jeśli zbiór roboczy mieści się w pamięci podręcznej stron (page cache), operacje odczytu przestają docierać do dysku. Podwojenie pamięci często daje lepsze rezultaty niż przejście na szybszą klasę pamięci masowej i zazwyczaj kosztuje mniej.

Zredukuj liczbę operacji zapisu (flush), jeśli pozwalają na to wymagania danych. W PostgreSQL parametr synchronous_commit = off pozwala na zwrócenie potwierdzenia transakcji (commit) przed fizycznym zapisem na dysku. W przypadku awarii serwera można utracić ułamek sekundy ostatnich transakcji. Baza danych nie ulega uszkodzeniu, ponieważ dziennik transakcji (write-ahead log) jest nadal zapisywany w odpowiedniej kolejności. Taki kompromis jest dopuszczalny dla kopii analitycznych, ale nie dla systemów płatności. innodb_flush_log_at_trx_commit = 2 w MySQL stanowi analogiczny kompromis.

Grupuj małe pliki. Transfer lub kopia zapasowa miliona małych plików jest ograniczona narzutem na każdy pojedynczy plik. Archiwizacja danych przed przesłaniem i przeniesienie jednego strumienia jest szybsze w przypadku pamięci o wysokim opóźnieniu niż kopiowanie drzewa katalogów plik po pliku.

Utrzymuj działanie operacji discard na woluminach typu thin. W przypadku pamięci masowej typu thin provisioned backend nie wie, że blok jest wolny, dopóki system plików nie przekaże takiej informacji. Wolumin, na którym nigdy nie wykonano operacji trim, stopniowo traci wydajność zapisu. System Ubuntu zawiera cotygodniowy timer do tego zadania:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av wyświetla liczbę bajtów zwolnionych dla każdego punktu montowania. Komunikat informujący, że operacja discard nie jest obsługiwana, oznacza, że wirtualny dysk nie przekazuje poleceń discard do hosta, więc nie ma elementów do naprawy po stronie użytkownika.

Pomiń dostrajanie harmonogramu operacji wejścia/wyjścia (IO scheduler).. Na dysku typu virtio parametr cat /sys/block/vda/queue/scheduler zazwyczaj wskazuje już none, a właściwe szeregowanie odbywa się na hoście, do którego nie ma dostępu. Pomiń również noatime: system Ubuntu domyślnie montuje systemy plików z opcją relatime, co pozwala uniknąć niemal każdego zapisu atime.

Wybór planu

Wybierz NVMe, jeśli na serwerze działa baza danych, serwer pocztowy, CI runner lub proces budowania aplikacji z dużą liczbą pakietów. Nie przepłacaj za pamięć NVMe w przypadku stron WWW z cachem lub aplikacji, których czas wykonania zależy głównie od zewnętrznych wywołań API. Jeśli nie masz pewności, dysk prawdopodobnie nie jest wąskim gardłem, ponieważ większość małych instancji VPS wyczerpuje najpierw zasoby RAM lub przepustowość łącza.

Wykonaj pomiary pierwszego dnia, podczas pracy nad pierwszymi dziesięcioma minutami na nowym VPS, i zapisz wyniki w pliku. Dane bazowe pozwolą w przyszłości udowodnić, że to host zwolnił, a nie Twój kod. Wybieraj dostawców, którzy jasno określają klasę pamięci masowej oraz limity IOPS. Jeśli plan oferuje NVMe, a odczyt przy głębokości kolejki 1 zajmuje 4 ms, oznacza to, że korzystasz z pamięci sieciowej na hoście wyposażonym w NVMe. Jest to akceptowalny produkt, ale należy mieć świadomość, że kupuje się coś innego niż lokalny dysk NVMe.

FAQ

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

Nie. Przy głębokości kolejki 1 oba rozwiązania są zbliżone, osiągając około 80 do 150 mikrosekund dla odczytu 4k, a program jednowątkowy nie wykaże różnicy. NVMe zyskuje przewagę, gdy w kolejce znajduje się wiele żądań, ponieważ AHCI oferuje jedną kolejkę o głębokości 32 poleceń, podczas gdy NVMe oferuje tysiące głębszych kolejek. Na współdzielonym hoście obciążenie generowane przez innych użytkowników wpływa na opóźnienia bardziej niż sam nośnik, dlatego należy zmierzyć wydajność własnego wolumenu za pomocą fio, zamiast polegać na nazwie planu.

Jak sprawdzić, czy mój VPS faktycznie korzysta z NVMe?

Nie można tego sprawdzić bezpośrednio, ponieważ virtio ukrywa fizyczne urządzenie. lsblk pokazuje vda bez ciągu znaków modelu, nvme list nie zwraca żadnych danych, a /sys/block/vda/queue/rotational raportuje tylko to, co udostępnia hypervisor. Zamiast tego należy zmierzyć zachowanie systemu. Losowy odczyt 4k przy głębokości kolejki 1 poniżej około 0.3 ms oznacza lokalną pamięć flash. Wynik rzędu kilku milisekund wskazuje na obecność przeskoku sieciowego. Odczyty sekwencyjne kończące się w okolicach 550 MB/s wskazują na łącze SATA.

Czy NVMe przyspiesza ładowanie mojej strony internetowej?

Zazwyczaj nie. Po pierwszym żądaniu system Linux serwuje pliki z pamięci podręcznej stron (page cache) w pamięci RAM, więc dysk pozostaje bezczynny. Szybkość ładowania strony na małym VPS jest zazwyczaj ograniczona czasem procesora aplikacji oraz przepustowością sieci. Dysk staje się wąskim gardłem tylko wtedy, gdy strona zapisuje dane przy każdym żądaniu, na przykład w przypadku koszyka opartego na bazie danych, który często wykonuje operacje commit, ponieważ każde zatwierdzenie czeka na zakończenie zapisu (flush).

Jaki wynik fio jest dobry dla VPS?

Według stanu na lipiec 2026, mały VPS na lokalnej pamięci flash zazwyczaj osiąga dziesiątki tysięcy operacji IOPS przy losowym odczycie 4k i głębokości kolejki 32, przy opóźnieniu poniżej 0.3 ms dla głębokości kolejki 1. Sieciowa pamięć masowa zazwyczaj osiąga kilka tysięcy IOPS przy opóźnieniu rzędu kilku milisekund. Test należy wykonać trzykrotnie o różnych porach dnia. Duża rozbieżność między wynikami mówi więcej niż średnia, ponieważ pokazuje, w jakim stopniu inni użytkownicy na hoście wpływają na wydajność Twojej instancji.

Czy powinienem umieścić bazę danych na sieciowej pamięci masowej?

Można to zrobić i wiele usług zarządzanych tak działa, ale ścieżka zatwierdzania transakcji (commit path) wiąże się z kosztem wydajnościowym. Każda operacja zapisu przechodzi przez sieć, więc 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. Jeśli wybierzesz pamięć sieciową dla bazy danych intensywnie zapisującej dane, grupuj operacje w większe transakcje, aby mniejsza liczba operacji zapisu obejmowała więcej wierszy.