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 передают несколько гигабайт в секунду, поэтому ограничением перестаёт быть канал.

Ожидания обычно ошибочны именно в отношении задержки. При глубине очереди 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 ms для локального NVMe и 1.2 ms для SATA. Если добавить в путь сетевое соединение, задержка возрастает до 6.5 ms. Это более чем в десять раз больше показателя 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.

Любая задача, ожидающая внешний сервис. 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. В результате benchmark показывает производительность, которой не способно обеспечить ни одно физическое устройство. Кроме того, при сбое хоста могут быть потеряны записи, которые база данных считает надёжно сохранёнными. При режиме кэширования none показатели ниже и достовернее.

Ограничения и burst credits. Многие провайдеры ограничивают IOPS для каждого тома или тарифа. Многие сетевые тома используют burst allowance. Burst allowance — это пул credits: том работает быстро, пока credits не закончатся, а затем переходит на значительно более низкий базовый уровень. Этот симптом легко распознать. Импорт или восстановление несколько минут выполняется быстро, затем резко замедляется и остаётся медленным, хотя конфигурация не менялась. Credits израсходованы.

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

Как измерить фактический объем диска 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 — среднее отклонение — не менее важно, чем среднее значение. Большое отклонение на простаивающем сервере означает, что серверная часть хранилища используется совместно и перегружена.

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

По состоянию на июль 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 это обычно указывает на внутреннюю систему хранения или на исчерпанный лимит IOPS.

Симптомы приложения соответствуют той же картине. Медианное время ответа остается приемлемым, а самые медленные запросы образуют длинный хвост, потому что задержка возникает только у запросов, которым требуется доступ к диску. apt upgrade в течение нескольких минут остается на этапе Unpacking, потому что dpkg сбрасывает данные на диск по мере записи. Выполнение git status в большом репозитории занимает несколько секунд. Это затраты на работу с метаданными и сброс данных, поэтому увеличение пропускной способности не поможет.

Что делать, если ограничением является диск

Сначала увеличьте объем RAM, а затем покупайте IOPS. Если рабочий набор помещается в page cache, операции чтения вообще перестают обращаться к диску. Удвоение объема памяти часто дает больший эффект, чем переход на более быстрый класс хранилища, и обычно обходится дешевле.

Сократите количество операций flush, если это допускают требования к данным. В PostgreSQL параметр synchronous_commit = off позволяет вернуть результат commit до записи данных на диск. При сбое сервера можно потерять транзакции за последнюю долю секунды. База данных не будет повреждена, поскольку write-ahead log по-прежнему записывается последовательно. Такой компромисс подходит для аналитической копии, но не подходит для платежей. В MySQL параметр innodb_flush_log_at_trx_commit = 2 обеспечивает такой же компромисс.

Объединяйте небольшие файлы в архивы. При передаче или резервном копировании миллиона небольших файлов основная задержка связана с затратами на обработку каждого файла. Поэтому на хранилище с высокой задержкой сначала создать архив и передать один поток быстрее, чем копировать дерево файл за файлом.

Обеспечьте работу discard на thin-томах. В thin provisioned storage backend не знает, что блок свободен, пока файловая система не сообщит об этом. Том, на котором trim никогда не выполняется, постепенно теряет производительность записи. Ubuntu поставляется с еженедельным timer для этого:

systemctl status fstrim.timer
sudo fstrim -av

Команда fstrim -av выводит количество bytes, освобожденных для каждой точки монтирования. Сообщение о том, что операция discard не поддерживается, означает, что virtual disk не передает 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, когда одновременно выполняется много запросов: AHCI предоставляет одну очередь глубиной 32 команды, а NVMe — тысячи более глубоких очередей. На общем хосте нагрузка от других гостевых систем может сильнее повлиять на задержку, чем тип носителя. Поэтому измерьте свой том с помощью fio, а не ориентируйтесь на название тарифа.

Как проверить, действительно ли мой VPS использует NVMe?

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

Ускоряет ли NVMe загрузку моего сайта?

Обычно нет. После первого запроса Linux обслуживает файлы из page cache в оперативной памяти, поэтому диск простаивает. Скорость загрузки страницы на небольшом VPS обычно ограничена временем работы приложения и пропускной способностью сети. Диск снова становится частью критического пути, если сайт выполняет запись при каждом запросе. Например, корзина на базе базы данных может часто выполнять commit, поскольку каждый commit ожидает завершения flush.

Какой результат fio считается хорошим для VPS?

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

Следует ли разместить базу данных в сетевом блочном хранилище?

Это возможно, и многие управляемые сервисы так делают, но путь выполнения commit становится более медленным. Каждая операция flush проходит через сеть, поэтому одно соединение выполняет меньше небольших транзакций в секунду, чем при использовании локальных флеш-накопителей. Взамен вы получаете сохранность данных при сбое хоста. Если вы выбираете сетевое хранилище для базы данных с высокой нагрузкой на запись, объединяйте операции в более крупные транзакции, чтобы за меньшее число операций flush сохранялось больше строк.