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

Чи важливий NVMe на VPS?

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

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

NVMe (non-volatile memory express) — це не різновид flash-пам’яті. Це протокол і підключення, через які здійснюється доступ до flash-пам’яті. Пристрій 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 реальних даних. Це фіксована верхня межа незалежно від того, яка flash-пам’ять розташована за цим каналом. Чотири лінії PCIe передають кілька гігабайтів за секунду, тому канал перестає бути обмеженням.

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

Мережеве block storage — це третій клас із іншою фізикою процесів. Операція запису проходить через мережу до кластера сховища, і підтвердження надходить лише після того, як кластер збереже дані. Тому затримка вимірюється в мілісекундах, а не в мікросекундах. Натомість ви отримуєте надійність зберігання: volume переживає host, до якого його підключено, а також підтримує створення snapshot і зміну розміру.

Типові опубліковані показники: 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 мс, що більш ніж у 10 разів перевищує показник NVMe.

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

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

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

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

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

PostgreSQL повідомляє про це в рядках checkpoint. Велике значення 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 великого репозиторію, розпакування container images, сховище пошти Maildir і резервне копіювання під час обходу великого дерева каталогів витрачають час на малі операції довільного доступу. Завдання резервного копіювання restic на VPS читає та хешує кожен файл, якого ще не бачило, тому загальний час резервного копіювання мільйона файлів тісно залежить від затримки довільного читання. Те саме стосується du -sh, яке читає лише метадані.

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

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

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

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

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

Будь-які процеси, що очікують на зовнішній сервіс. Worker, який витрачає 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 обходить кеш сторінок guest-системи, тому результат описує пристрій, а не вашу 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, тобто середнє відхилення, не менш важливе за середнє значення. Велике відхилення на незавантаженому сервері означає, що бекенд сховища спільно використовується та перевантажений.

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

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

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

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. Якщо у вашому ядрі є /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 це зазвичай вказує на проблеми зі storage backend або на вичерпаний ліміт IOPS.

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

Що робити, коли диск є обмежувальним ресурсом

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

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

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

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

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av виводить кількість bytes, очищених для кожної точки монтування. Повідомлення про те, що операція 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?

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

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

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

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

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

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

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

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

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