NVMe чи SSD на VPS: чи є різниця?

Чи має значення NVMe на VPS?

NVMe має значення на VPS, коли ваше програмне забезпечення виконує багато невеликих операцій читання та запису й очікує завершення кожної з них. Для сайту, який обслуговує кешовані сторінки, або програми, що переважно очікує на мережу, це майже нічого не змінює. Тип носія є лише одним із чинників. Гіпервізор, через який здійснюється доступ до диска, та інші гостьові системи на тому самому хості визначають фактичну межу продуктивності.

Що змінює NVMe, а що — ні

NVMe (non-volatile memory express) — це не різновид флешпам’яті. Це протокол і з’єднання, які використовуються для доступу до флешпам’яті. Пристрій NVMe працює через лінії PCIe (peripheral component interconnect express) і використовує протокол NVMe. SSD SATA (serial ATA) працює через з’єднання SATA і використовує AHCI (advanced host controller interface). Мікросхеми пам’яті, у яких зберігаються ваші дані, в обох випадках можуть бути однаковими.

Відрізняються два параметри. Обидва стосуються шляху проходження команд, а не самого сховища.

Черги. AHCI надає ядру одну чергу команд, яка містить 32 команди. NVMe підтримує тисячі черг, на практиці — по одній на кожне ядро CPU, і кожна з них значно глибша за 32 команди. Один процес, який читає по одному блоку за раз, цієї різниці не помітить. База даних із 64 одночасними операціями читання її помітить: у SATA 33-й запит чекає на вільний слот у черзі, перш ніж пристрій його побачить, а пристрій NVMe приймає всі запити й обробляє їх одночасно.

Ширина каналу. З’єднання SATA III працює на швидкості 6 Gbit/s, що після врахування накладних витрат протоколу становить приблизно 550 MB/s реальних даних. Це фіксована максимальна швидкість незалежно від того, яка флешпам’ять підключена за ним. Чотири лінії PCIe передають кілька гігабайт за секунду, тому канал перестає бути обмеженням.

Затримка зазвичай не відповідає очікуванням. За глибини черги 1, тобто коли виконується один запит, SSD SATA відповідає на операцію читання 4k приблизно за 100–150 мікросекунд. NVMe відповідає приблизно за 80–100 мікросекунд. Обидва варіанти швидкі, і жодна програма не помітить різниці під час виконання одного запиту. Різниця стає помітною за паралельного навантаження. Глибина черги — кількість одночасних запитів — визначає, чи будуть ці два типи носіїв виглядати однаково або дуже по-різному.

Мережеве блочне сховище — це третій клас, який працює за іншими фізичними принципами. Запис проходить через мережу до кластера сховища, і підтвердження надходить лише після того, як кластер збереже дані. Тому затримка вимірюється в мілісекундах, а не в мікросекундах. Перевага такої затримки — надійність зберігання: том існує довше за хост, до якого його підключено, а також його можна створювати як знімок і змінювати його розмір.

Типові опубліковані показники: NVMe, SATA SSD і мережеве сховище

[
  {
    "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"
  }
]

Для локального пристрою NVMe зазвичай вказують 184,000 випадкових операцій читання IOPS для блоків 4k (операцій введення-виведення за секунду) за глибини черги 32. У тому самому тесті для SATA SSD зазвичай отримують близько 90,000. Результат обмежують одна черга AHCI та канал зі швидкістю 6 Gbit/s. Мережеве блокове сховище зазвичай обмежене постачальником, а не апаратним забезпеченням. 12,500 — поширена задокументована максимальна межа.

Затримка показує те саме в одиницях, які відчувають користувачі. Затримка читання p99, тобто затримка найповільніших 1 відсотка запитів, становить приблизно 0.4 мс для локального NVMe та 1.2 мс для SATA. Якщо додати мережу до шляху передавання, значення зростає до 6.5 мс — це більш ніж у десять разів більше за показник NVMe.

Послідовне читання дає найбільшу різницю, але найменше допомагає для оцінювання реального навантаження: 3,400 MB/s проти 550 MB/s. Майже жоден сервер не читає один великий файл від початку до кінця на максимальній швидкості. Стовпці випадкових операцій і затримки краще описують фактичну роботу бази даних, черги пошти або менеджера пакетів.

Які робочі навантаження відчувають вплив диска

Усі їх пояснює одне правило: робоче навантаження відчуває вплив диска лише тоді, коли очікує на диск. Linux зберігає нещодавно використані дані файлів у RAM, у кеші сторінок, тому під час другого читання файл не звертається до сховища. Якщо робочий набір, тобто дані, які фактично використовуються, вміщується в RAM, після першого проходу читання відбувається з пам’яті. Запис працює інакше. Будь-які дані, які застосунок скидає за допомогою fsync(), мають бути записані на стабільний носій, перш ніж застосунок зможе продовжити роботу.

Операції, які фіксують транзакції. PostgreSQL, MySQL і SQLite викликають fsync() або fdatasync() під час фіксації транзакції, і кожна фіксація очікує на відповідь пристрою. Тому швидкість фіксації одного з’єднання визначається затримкою запису, а не пропускною здатністю. Пристрій, який виконує скидання за 0.2 ms, дає змогу виконувати значно більше фіксацій за секунду, ніж пристрій, якому потрібно 5 ms, і жодна пропускна здатність цього не змінить. MySQL повідомляє про це в журналі помилок, коли скидання не встигає за навантаженням:

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

PostgreSQL повідомляє про це в рядках контрольних точок, де велике значення sync= означає, що саме скидання було повільним:

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

Операції з великою кількістю малих файлів. Кожен файл потребує операцій із метаданими, яких немає під час одного великого послідовного читання. npm install, git clone великого репозиторію, розпакування образів контейнерів, сховище пошти Maildir і резервне копіювання з обходом великого дерева каталогів витрачають час на малий довільний доступ. Завдання резервного копіювання restic на VPS читає та обчислює хеш кожного файла, якого ще не бачило, тому тривалість резервного копіювання мільйона файлів майже безпосередньо залежить від затримки довільного читання. Те саме стосується du -sh, яке читає лише метадані.

До цієї категорії також належать бази даних, які перевищили обсяг RAM. Коли індекс більше не вміщується в кеші сторінок, кожен пошук перетворюється на довільне читання, і диск знову стає критичною ланкою.

Які робочі навантаження не залежать від диска

Блог або сайт невеликої компанії. Сторінки невеликі, кеш сторінок утримує їх після першого запиту, а обмеженням є CPU під час рендерингу або пропускна здатність для ресурсів. Стек LAMP на Ubuntu 24.04, який обслуговує сайт із невеликим трафіком, після прогрівання майже не виконує дискових операцій вводу-виводу.

Потокове передавання медіа. Один потік 4K зі швидкістю 40 Mbit/s читає 5 MB/s. Десять потоків читають 50 MB/s, що без проблем забезпечує навіть мережеве блочне сховище. Медіасервер Jellyfin на VPS обмежений дозволеним обсягом вихідного мережевого трафіку, а під час транскодування — CPU, а не типом сховища.

Локальний запуск моделей. Запуск Ollama на VPS для самостійного розгортання LLM зчитує файл моделі один раз, після чого працює в RAM. NVMe скорочує час завантаження моделі розміром 20 GB із хвилин до секунд. Це не змінює кількість токенів за секунду, оскільки цей показник обмежується пропускною здатністю пам’яті та CPU.

Будь-які завдання, що очікують на зовнішню службу. Воркер, який витрачає 800 ms на HTTP-запит для кожного завдання, не працюватиме швидше на кращому диску.

Чому гіпервізор не менш важливий, ніж тип носія

Ви не взаємодієте безпосередньо з пристроєм. Ви працюєте з віртуальним диском, який представляє гіпервізор, зазвичай через virtio. Кілька рішень на цьому рівні важливіші за різницю між NVMe і SATA.

Усередині гостьової системи не можна побачити тип носія. lsblk -d -o NAME,ROTA,SIZE,MODEL показує vda з порожнім полем моделі, оскільки virtio не передає ідентифікаційні дані диска. cat /sys/block/vda/queue/rotational повідомляє те, що оголошує гіпервізор, тому значення 0 не доводить, що використовується flash-пам’ять. nvme list з пакета nvme-cli на більшості VPS нічого не показує, навіть якщо хост оснащено дисками NVMe, оскільки ваш диск є пристроєм virtio, а не пристроєм NVMe. Позначення NVMe в тарифному плані зазвичай описує накопичувачі хоста. Ваш том усе одно може бути підключений через мережу.

Режим кешування на хості впливає на результати сильніше, ніж тип носія. Якщо на хості ввімкнено кешування writeback, гостьовий fsync() може завершитися одразу після того, як хост збереже дані у власній RAM. Це створює результат тесту, якого не зміг би забезпечити жоден фізичний пристрій. Крім того, у разі збою хоста можна втратити записи, які база даних вважає безпечно збереженими. У режимі кешування none результати нижчі, але відповідають дійсності.

Обмеження та burst credits. Багато провайдерів обмежують IOPS для кожного тому або тарифного плану. Багато мережевих томів використовують burst allowance. Burst allowance — це пул кредитів. Том працює швидко, доки кредити не вичерпано, а потім переходить на значно нижчу базову швидкість. Симптом легко розпізнати. Імпорт або відновлення кілька хвилин виконується швидко, потім різко сповільнюється і залишається повільним, хоча в конфігурації нічого не змінювалося. Ви витратили кредити.

Сусідні віртуальні машини. На спільному хості затримка диска змінюється залежно від того, що роблять інші гостьові системи. Тому потрібно виконати вимірювання кілька разів. Запустіть той самий тест вранці, а потім увечері, і порівняйте розкид результатів. На завантаженому хості різниця між двома запусками на одному томі часто більша, ніж опублікована різниця між двома типами носіїв.

Як виміряти фактичний дисковий простір VPS

Встановіть fio — стандартний інструмент для тестування IO — і виконайте вимірювання. Спочатку врахуйте три застереження. Тест створює файл, тому використовує дисковий простір і враховується в будь-якому ліміті IOPS, за який ви платите. Виконуйте тести недовго. Не запускайте тест із повною глибиною черги на томі, який обслуговує робочий трафік, оскільки це створить конкуренцію для вашого застосунку.

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

Випадкове читання з глибиною черги 32 — саме таку глибину зазвичай наводять постачальники:

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

Важливий рядок починається з read:

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

--direct=1 обходить кеш сторінок гостьової системи, тому результат описує пристрій, а не вашу RAM. Якщо не вказати цей параметр, ви вимірюватимете пам’ять і отримаєте значення, якого жоден диск не може досягти. Використовуйте --size=4G або більше, якщо маєте достатньо простору, оскільки файл розміром 1G може повністю поміститися в кеші хоста та завищити результат.

Глибина черги 1 показує фактичну затримку, яку відчуває однопотоковий процес:

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

Тест із commit дає змогу спрогнозувати поведінку бази даних. Він записує 4k і після кожного запису викликає fdatasync(), тому вказана швидкість враховує 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

Показник IOPS із цього запуску близький до максимальної кількості малих транзакцій за секунду, які може зафіксувати одне підключення до бази даних, оскільки commit очікує на той самий flush.

Для швидкої перевірки без 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

Значення mdev, тобто середнє відхилення, не менш важливе за середнє значення. Велике відхилення на простоюючому сервері означає, що backend сховища спільно використовується та перевантажений.

Як читати результат

Станом на July 2026 для невеликого VPS можна використовувати такі орієнтири. Десятки тисяч IOPS для випадкового читання блоками 4k за queue depth 32, коли затримка за queue depth 1 не перевищує приблизно 0.3 ms, відповідають локальному flash-накопичувачу. Затримка за queue depth 1 у кілька мілісекунд означає наявність мережевого шляху, незалежно від назви тарифу. Послідовне читання, яке зупиняється біля 550 MB/s, є ознакою SATA-з'єднання. Значення, що значно перевищує можливості будь-якого окремого пристрою, означає, що на цьому шляху працює кешування, майже завжди на host.

Щоб побачити, як поточне навантаження впливає на диск:

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

У виведенні iostat -x перегляньте r_await і w_await — середній час у мілісекундах, протягом якого запит очікував на обробку, — а також aqu-sz — середню довжину черги. Не враховуйте %util на віртуальному диску. Цей показник повідомляє, протягом якої частки часу в обробці перебував принаймні один запит, але нічого не говорить про насичення пристрою, який одночасно обслуговує багато запитів. Тому значення %util, близьке до 100, разом зі значенням r_await 0.2 ms означає, що диск активно працює у штатному режимі. У vmstat стовпець wa показує відсоток часу CPU, витрачений на очікування IO. Якщо у вашому kernel доступний /proc/pressure/io, його значення some avg10= показує частку останніх 10 секунд, протягом якої принаймні одне завдання було заблоковане через IO. Це найпряміша відповідь на питання, чи є сховище вузьким місцем.

Як виглядає VPS, обмежений дисковою підсистемою

Високе середнє навантаження за умови простою CPU та великого значення wa у vmstat означає, що процеси стоять у черзі в очікуванні диска. Найчіткіший сигнал ядра — це таке повідомлення у dmesg -T:

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

Цей рядок з’являється, оскільки потік ядра понад дві хвилини чекав відповіді від сховища, тому watchdog завислих завдань записав це повідомлення. jbd2 — це потік журналу ext4. Отже, чекала вся файлова система, а не одна проблемна програма. На VPS це зазвичай вказує на серверну частину сховища або вичерпаний ліміт IOPS.

Симптоми застосунків відповідають цій самій картині. Медіанний час відповіді залишається прийнятним, але найдовші запити утворюють довгий хвіст, оскільки витрати часу на диск виникають лише для запитів, що звертаються до нього. apt upgrade залишається на етапі Unpacking протягом кількох хвилин, оскільки dpkg скидає дані під час запису. git status у великому репозиторії триває кілька секунд. Це витрати на метадані та скидання даних, тому збільшення пропускної здатності не допоможе.

Що робити, коли диск є обмеженням

Придбайте RAM раніше, ніж IOPS. Якщо робочий набір вміщується в page cache, операції читання взагалі перестають звертатися до диска. Подвоєння обсягу пам’яті часто дає більший результат, ніж перехід на швидший клас сховища, і зазвичай коштує дешевше.

Зменшуйте кількість операцій flush, якщо це допускають дані. У PostgreSQL synchronous_commit = off дає змогу повернутися після commit до запису даних на диск. Якщо сервер відмовить, можна втратити останню частку секунди транзакцій. База даних не буде пошкоджена, оскільки write-ahead log і далі записується послідовно. Такий компроміс підходить для аналітичної копії, але не для платежів. innodb_flush_log_at_trx_commit = 2 у MySQL забезпечує такий самий компроміс.

Об’єднуйте малі файли в пакети. Передавання або резервне копіювання мільйона малих файлів здебільшого обмежене витратами на кожен файл. Тому на сховищі з високою затримкою спочатку створити архів, а потім передати один потік швидше, ніж копіювати дерево файлів по одному.

Підтримуйте discard на thin-томах. У thin provisioned сховищі backend не знає, що блок звільнено, доки файлова система не повідомить про це. Том, на якому ніколи не виконується trim, поступово втрачає продуктивність запису. Ubuntu постачається з щотижневим timer для цього:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av виводить кількість байтів, очищених для кожної точки монтування. Повідомлення про те, що операція discard не підтримується, означає, що віртуальний диск не передає discard до host. Виправляти тут нічого.

Не налаштовуйте IO scheduler. На диску virtio cat /sys/block/vda/queue/scheduler зазвичай уже показує none, а фактичне планування операцій виконується на host, до якого у вас немає доступу. Також не налаштовуйте noatime: Ubuntu типово монтує файлові системи з relatime, що вже усуває майже всі операції запису atime.

Вибір тарифу

Платіть за NVMe, якщо на сервері працює база даних, поштовий сервер, CI runner або збірка з великою кількістю пакетів. Не переплачуйте за кешований вебсайт або застосунок, який більшість часу витрачає на зовнішні виклики. Якщо ви не впевнені, диск, імовірно, не є вашим обмеженням, оскільки більшість невеликих робочих навантажень VPS спочатку вичерпують RAM або пропускну здатність.

Виконайте вимірювання в перший день під час проходження перших десяти хвилин на новому VPS і збережіть результати у файл. Базовий показник дає змогу згодом довести, що сервер став повільнішим, а не ваш код. Обирайте провайдерів, які письмово вказують клас сховища та обмеження IOPS, якщо воно є. Якщо в тарифі зазначено NVMe, але читання з queue depth 1 триває 4 ms, ви використовуєте мережеве сховище на хості з NVMe. Це цілком прийнятна пропозиція для продажу, але купуєте ви інший тип сховища.

FAQ

Чи завжди NVMe швидший за SATA SSD на VPS?

Ні. За глибини черги 1 ці два типи накопичувачів близькі: приблизно 80–150 мікросекунд для операції читання 4k, і однопотокова програма не може розрізнити їх. NVMe випереджає SATA SSD, коли одночасно обробляється багато запитів, оскільки AHCI використовує одну чергу завглибшки 32 команди, а NVMe — тисячі глибших черг. На спільному хості навантаження від інших гостьових систем може впливати на затримку сильніше, ніж тип носія. Тому вимірюйте власний том за допомогою fio, а не орієнтуйтеся на назву тарифного плану.

Як перевірити, чи справді мій VPS використовує NVMe?

Безпосередньо перевірити це не можна, оскільки virtio приховує фізичний пристрій. lsblk показує vda без рядка моделі, nvme list нічого не повертає, а /sys/block/vda/queue/rotational повідомляє лише те, що оголошує гіпервізор. Натомість вимірюйте фактичні характеристики. Випадкове читання 4k за глибини черги 1 із затримкою меншою за приблизно 0.3 ms означає локальну флеш-пам’ять. Кілька мілісекунд означають, що на шляху є мережевий сегмент. Послідовне читання, швидкість якого зупиняється біля 550 MB/s, вказує на SATA-з’єднання.

Чи пришвидшить NVMe завантаження мого вебсайту?

Зазвичай ні. Після першого запиту Linux обслуговує файли з кешу сторінок у RAM, тому диск простоює. Швидкість завантаження сторінки на невеликому VPS зазвичай обмежується часом роботи процесора застосунку та пропускною здатністю. Диск знову стає критичним для обробки запиту, якщо сайт записує дані під час кожного запиту. Наприклад, кошик на основі бази даних, який часто виконує commit, очікує завершення flush для кожної такої операції.

Який результат fio вважається хорошим для VPS?

Станом на July 2026 невеликий VPS із локальною флеш-пам’яттю зазвичай забезпечує десятки тисяч IOPS випадкового читання 4k за глибини черги 32, а затримка за глибини черги 1 становить менше 0.3 ms. Мережеве блокове сховище зазвичай забезпечує кілька тисяч IOPS із затримкою в кілька мілісекунд. Виконайте тест 3 рази в різні години. Значний розкид між результатами повідомляє більше, ніж середнє значення, оскільки показує, наскільки на вас впливає навантаження від інших гостьових систем на хості.

Чи варто розміщувати базу даних у мережевому блоковому сховищі?

Так можна робити, і багато керованих сервісів працюють саме так, але шлях commit має додаткові витрати. Кожен flush проходить через мережу, тому одне з’єднання виконує менше малих транзакцій за секунду, ніж у разі локальної флеш-пам’яті. Натомість ви отримуєте стійкість даних, яка зберігається навіть у разі відмови хоста. Якщо ви обираєте мережеве сховище для бази даних із великим обсягом запису, об’єднуйте операції у більші транзакції, щоб менша кількість flush переносила більше рядків.