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

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

Сетевые блочные хранилища — это третий класс устройств с другой физикой работы. Запись передается по сети в кластер хранения и подтверждается только после того, как кластер принял данные, поэтому задержки здесь измеряются в миллисекундах, а не в микросекундах. Вы платите за эти задержки ради надежности: том продолжает существовать после выхода из строя хоста, к которому он был подключен, а также его можно копировать (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 является распространенным задокументированным пределом.

Задержка (latency) отражает те же показатели в единицах, ощутимых для пользователей. Задержка чтения p99, то есть время выполнения самого медленного 1 процента запросов, составляет около 0.4 мс для локального NVMe и 1.2 мс для SATA. При добавлении сети в путь прохождения данных этот показатель возрастает до 6.5 мс, что более чем в десять раз превышает значение для NVMe.

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

Какие рабочие нагрузки зависят от диска

Все их объединяет одно правило: рабочая нагрузка зависит от диска только тогда, когда она ожидает завершения операций ввода-вывода. Linux хранит недавно использованные данные файлов в оперативной памяти, в page cache, поэтому повторное чтение файла никогда не обращается к накопителю. Если рабочий набор данных, то есть информация, которая фактически используется, помещается в RAM, то после первого прохода чтение становится операцией с памятью. С записью ситуация иная. Любая запись, которую приложение сбрасывает на диск с помощью fsync(), должна оказаться на энергонезависимом носителе, прежде чем приложению будет разрешено продолжить работу.

Задачи с фиксацией данных. PostgreSQL, MySQL и SQLite вызывают fsync() или fdatasync() при фиксации транзакции (commit), и каждая такая операция ожидает ответа от устройства. Таким образом, скорость фиксации для одного соединения определяется задержкой записи (latency), а не пропускной способностью. Устройство, выполняющее сброс за 0.2 мс, позволяет совершать гораздо больше фиксаций в секунду, чем устройство с задержкой 5 мс, и никакое увеличение пропускной способности это не изменит. 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 большого репозитория, распаковка образов контейнеров, хранилище почты Maildir и обход большого дерева каталогов при резервном копировании — всё это тратит время на случайный доступ к мелким объектам. Задача резервного копирования restic на VPS считывает и хеширует каждый новый файл, поэтому общее время выполнения резервного копирования миллиона файлов напрямую зависит от задержки случайного чтения. То же самое касается du -sh, который считывает только метаданные.

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

Какие рабочие нагрузки не зависят от диска

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

Потоковое вещание медиа. Один поток 4K со скоростью 40 Мбит/с требует чтения 5 МБ/с. Десять таких потоков требуют 50 МБ/с, что легко обеспечивается даже сетевыми блочными хранилищами. Медиасервер Jellyfin на VPS ограничен лимитом исходящего сетевого трафика и мощностью процессора при транскодировании, а не типом накопителя.

Локальный запуск моделей. Запуск Ollama на VPS для хостинга LLM считывает файл модели один раз, после чего работа ведётся в оперативной памяти. NVMe сокращает время загрузки модели объёмом 20 ГБ с минут до секунд. Это не влияет на скорость генерации токенов, которая ограничена пропускной способностью памяти и мощностью процессора.

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

Лимиты и кредиты на пиковую нагрузку. Многие провайдеры ограничивают IOPS для тома или тарифного плана, а многие сетевые тома используют систему кредитов на пиковую нагрузку (burst). Кредиты — это пул ресурсов: том работает быстро, пока есть кредиты, а затем скорость падает до базового уровня. Этот симптом легко распознать. Импорт или восстановление данных проходят быстро в течение нескольких минут, а затем резко замедляются и остаются медленными, хотя в конфигурации ничего не менялось. Вы просто исчерпали кредиты.

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

Как измерить реальную производительность диска на VPS

Установите fio, стандартный инструмент для тестирования ввода-вывода, и выполните замеры. Сначала три предостережения. Тест создает файл, поэтому он занимает место на диске и расходует лимит 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 отключает кэш страниц гостевой системы, поэтому результат описывает устройство, а не вашу оперативную память. Если его убрать, вы будете измерять память, что даст значения, недостижимые для любого диска. Используйте --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

Тест коммитов предсказывает поведение базы данных. Он записывает 4k и вызывает fdatasync() после каждой записи, поэтому указанная скорость включает операцию сброса данных на диск:

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 в этом тесте близко к максимальному количеству мелких транзакций в секунду, которое может зафиксировать одно соединение с базой данных, так как коммит ожидает завершения того же сброса данных.

Для быстрой проверки без использования 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 и задержка менее 0.3 мс при глубине очереди 1 соответствуют локальному 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 мс означает, что диск работает нормально. В vmstat столбец wa показывает процент времени CPU, затраченного на ожидание ввода-вывода (IO). Если в вашем ядре присутствует /proc/pressure/io, то его значение some avg10= отражает долю времени за последние 10 секунд, в течение которой хотя бы одна задача была заблокирована в ожидании ввода-вывода. Это самый прямой ответ на вопрос о том, является ли дисковая подсистема «узким местом».

Признаки VPS с ограничением производительности диска

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

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

Эта строка появляется, когда поток ядра ожидает ответа от хранилища более двух минут, после чего срабатывает watchdog зависших задач. jbd2 — это поток журнала ext4, что означает ожидание всей файловой системы, а не отдельной некорректно работающей программы. На VPS это обычно указывает на проблемы с бэкендом хранилища или исчерпание лимита IOPS.

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

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

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

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

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

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

systemctl status fstrim.timer
sudo fstrim -av

Команда fstrim -av выводит количество байт, очищенных для каждой точки монтирования. Сообщение о том, что операция discard не поддерживается, означает, что виртуальный диск не передает команды discard на хост, поэтому исправлять здесь нечего.

Не тратьте время на настройку планировщика ввода-вывода. На дисках virtio параметр cat /sys/block/vda/queue/scheduler обычно уже показывает none, а реальное планирование происходит на хосте, к которому у вас нет доступа. Также пропустите noatime: Ubuntu по умолчанию монтирует разделы с параметром relatime, что уже позволяет избежать практически всех записей atime.

Выбор тарифного плана

Оплачивайте NVMe, если на сервере размещены база данных, почтовый сервер, CI-раннер или процесс сборки с большим количеством пакетов. Не переплачивайте за кэшируемый веб-сайт или приложение, основное время работы которого уходит на внешние вызовы. Если вы не уверены, скорее всего, диск не является узким местом, так как большинство задач на небольших VPS упираются в объем RAM или пропускную способность сети.

Проведите замеры в первый же день, пока вы выполняете первые десять минут настройки нового VPS, и сохраните вывод в файл. Базовые показатели — это способ доказать в будущем, что замедлился хостинг, а не ваш код. Отдавайте предпочтение провайдерам, которые письменно указывают класс хранилища и любые ограничения IOPS. Если в тарифе заявлен NVMe, а чтение с глубиной очереди 1 занимает 4 мс, значит, вы используете сетевое хранилище на хосте с NVMe. Это допустимый товар для продажи, но совсем другой продукт для покупки.

FAQ

Всегда ли NVMe быстрее, чем SATA SSD на VPS?

Нет. При глубине очереди 1 показатели близки: примерно от 80 до 150 микросекунд для чтения 4k, и однопоточная программа не заметит разницы. NVMe вырывается вперед, когда в обработке находится много запросов, так как 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 обычно ограничена процессорным временем приложения и пропускной способностью сети. Диск становится критическим узлом, если сайт выполняет запись при каждом запросе (например, корзина на базе БД, которая часто делает коммиты), так как каждый коммит ожидает завершения операции сброса данных на диск.

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

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

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

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