Миф: NVMe ускорит любой проект

MAATRIX

«Перейдите на NVMe — и сайт полетит» — фраза, которую слышит каждый, кто хоть раз жаловался на тормозящий сервер. Иногда это правда: NVMe действительно кардинально меняет картину. Но чаще — нет, потому что диск в вашем случае вообще не при чём, а деньги за апгрейд уже потрачены. Разберёмся, когда NVMe даёт реальный прирост, а когда это дорогая иллюзия решения проблемы.

Откуда взялся миф и в чём он отчасти прав

NVMe действительно на порядок быстрее SATA SSD по задержке и параллелизму: там, где SATA-накопитель обслуживает одну очередь команд ограниченной глубины через контроллер AHCI, NVMe работает поверх PCIe и может держать десятки тысяч команд в очереди на канал, распределённых по нескольким параллельным очередям. Если раньше на сервере стоял вращающийся HDD или бюджетный SATA SSD, а нагрузка была реально дисковой — переход на NVMe действительно снимает узкое место, и разница ощущается сразу.

Проблема мифа не в том, что NVMe плохой — проблема в обобщении. Маркетинг накопителей продаёт скорость, а не контекст: цифры в спецификациях (IOPS, MB/s) достигаются в синтетических тестах с высоким параллелизмом запросов, которых у вашего конкретного приложения может просто не быть. Купить NVMe — простое, понятное и относительно недорогое действие. Найти реальное узкое место — требует профилирования, а это уже работа. Отсюда и соблазн: сначала поменять диск, а разбираться потом, если не помогло.

Что физически ускоряет NVMe, а что нет

NVMe даёт прирост по трём параметрам: задержка одной операции (latency), количество операций в секунду при параллельных запросах (IOPS) и глубина очереди команд, которую накопитель способен переваривать одновременно. Здесь — ключевое слово «параллельно». Одна последовательная операция чтения большого файла на приличном SATA SSD и на NVMe может показывать почти одинаковую скорость: пропускной способности интерфейса SATA (около 550-600 МБ/с) часто достаточно для последовательного чтения, и здесь NVMe просто не успевает раскрыться.

Разница взрывается там, где одновременно летит множество мелких случайных операций ввода-вывода — то есть при высоком параллелизме и случайном доступе к данным. Это классическая нагрузка баз данных с интенсивной записью: множество параллельных транзакций, каждая из которых читает и пишет в разные, не связанные друг с другом участки диска. Про то, почему это критично именно для СУБД, у нас есть отдельный разбор — почему важна скорость диска для баз данных. Там же, где операций мало и они последовательны — например, редкая запись логов или раздача статики, которая и так лежит в кэше, — глубина очереди NVMe просто не заполняется, и её преимущество остаётся невостребованным.

Почему для многих проектов диск — не проблема

Прежде чем платить за NVMe, стоит честно ответить: а диск ли вообще тормозит ваш проект? На практике узкое место чаще оказывается в другом месте:

• Процессор. Медленный рендеринг шаблонов, неэффективные циклы, тяжёлая сериализация JSON, недостаточно ядер под пиковую нагрузку — всё это упирается в CPU, а не в диск. Смена накопителя здесь не изменит ничего: как найти настоящую причину высокой загрузки CPU, разобрано в статье высокая нагрузка на процессор: как найти причину.
• Память. Если приложению не хватает RAM и оно начинает уходить в своп, тормоза будут выглядеть как дисковые — но лечатся добавлением памяти, а не сменой диска. Своп сам по себе создаёт дисковую нагрузку, которая с NVMe станет чуть менее болезненной, но проблема останется — она в нехватке RAM.
• Сеть. Долгие внешние запросы к API, медленный DNS, недостаточная пропускная способность канала — частая причина «тормозящего» сайта, которая с диском вообще не связана.
• Неоптимальный код и запросы. N+1-запросы к базе, отсутствие индексов, синхронные вызовы там, где нужен пул соединений, — всё это создаёт задержки, которые никакой NVMe не компенсирует. Если база данных «тормозит», часто дело не в диске, а в плане выполнения запроса.

Отдельно стоит кэш — он способен полностью замаскировать возможности диска, и об этом отдельный разговор ниже.

Как кэш обнуляет разницу между SATA и NVMe

Для многих небольших и средних проектов с активным кэшированием разница между SATA SSD и NVMe может быть попросту незаметна — и вот почему. Операционная система держит в оперативной памяти page cache: часто читаемые блоки файлов физически не доходят до диска повторно, они отдаются прямо из RAM. СУБД поверх этого держат собственный буферный пул (buffer pool в MySQL/InnoDB, shared_buffers в PostgreSQL), кэширующий страницы данных и индексы — при достаточном объёме памяти большинство операций чтения вообще не касается физического накопителя. Мы подробно разбирали это в статье буферный пул базы: почему он важнее диска.

Если ваш проект — сайт на WordPress с типовым трафиком, небольшой SaaS с несколькими сотнями активных пользователей или API с умеренной нагрузкой, то горячий набор данных (working set), к которому реально идут обращения, скорее всего целиком помещается в RAM после прогрева кэша. В этом случае диск используется в основном для редкой записи и холодного чтения — а не для постоянного параллельного потока операций, где раскрывается NVMe. Мы отдельно писали, почему кэш не панацея и не решает всех проблем производительности разом — но верно и обратное: там, где кэш работает хорошо, он снимает нагрузку с диска настолько, что тип накопителя перестаёт быть заметным фактором. Подробнее — в материале миф: кэш решит проблему производительности.

Есть и обратная сторона: если рабочий набор данных больше объёма RAM (типичная ситуация для аналитики, больших индексов полнотекстового поиска или баз с историей на сотни гигабайт), кэш не спасает — каждое обращение к «холодным» данным реально идёт на диск, и здесь NVMe снова выходит на первый план.

Как проверить, упирается ли именно ваш проект в диск

Не гадайте — измерьте. На Linux-сервере есть штатные инструменты, которые за пару минут дают честный ответ.

Первый шаг — iostat с разбивкой по устройствам:

iostat -x 1 10

Смотрите на колонки %util (загрузка устройства), await (среднее время ожидания операции в мс) и r/s/w/s (операции в секунду). Если %util держится в районе 90-100% продолжительное время, а await растёт — диск действительно является узким местом. Если %util низкий (10-20%), а приложение всё равно тормозит — причина не в диске. Важный нюанс: сама по себе загрузка диска в 100% ещё не всегда означает физический предел — иногда это особенность метрики, а не реальный потолок пропускной способности, подробнее в статье загрузка диска 100% — не значит предел.

Второй шаг — общая картина через vmstat:

vmstat 1 10

Колонки wa (I/O wait, доля времени CPU в ожидании диска) и b (процессы, заблокированные в очереди на I/O) быстро показывают, простаивает ли процессор в ожидании накопителя. Высокий wa при низкой загрузке CPU в целом — характерный признак дисковой зависимости. Если вместо этого высокий us/sy (пользовательское и системное время CPU) — вы упираетесь в процессор, и NVMe тут не поможет.

Третий шаг — если общие метрики намекают на диск, проверьте гипотезу нагрузочным тестом, максимально похожим на профиль вашего приложения, а не абстрактным «на максимум»:

fio --name=randwrite --ioengine=libaio --direct=1 \
    --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 \
    --size=1G --runtime=60 --group_reporting

Меняйте --rw (randread, randwrite, read, write) и --bs (размер блока) под свой реальный паттерн доступа — базе данных ближе randwrite/randread с блоком 4-16 КБ и высоким iodepth, файловому хранилищу статики — последовательное чтение крупными блоками. Подробный разбор параметров и типичных ошибок при замере — в статье fio для честного замера диска. Общий алгоритм диагностики медленного диска на VPS с чек-листом команд собран в материале медленный диск на VPS: как проверить, а как на глаз отличить реальный упор в IOPS от прочих узких мест — в статье предел IOPS: как отличить упор в диск.

Алгоритм принятия решения перед покупкой NVMe

Прежде чем платить за апгрейд, пройдите короткую последовательность проверок — это займёт максимум полчаса, а сэкономить может месяц ожидания «прироста», которого не будет.

1. Замерьте CPU. top или htop под нагрузкой: если ядра забиты на 90%+ постоянно — это первый кандидат на апгрейд, не диск.
2. Замерьте память. free -m: если swap активно используется (не ноль и растёт) — добавьте RAM, диск здесь ни при чём, даже если своп физически создаёт дисковую нагрузку.
3. Замерьте сеть. Проверьте задержки внешних запросов (к API, платёжным шлюзам, внешним базам) отдельно от локальной обработки — иногда «тормозит сервер», а на деле тормозит партнёрский API.
4. Замерьте диск. iostat -x и vmstat в момент пиковой нагрузки — если %util и await высокие одновременно с ростом wa в vmstat, диск — реальный кандидат.
5. Проверьте гипотезу нагрузочным тестом, максимально приближенным к профилю вашего приложения (см. предыдущий раздел).
6. Оцените параллелизм. Даже если диск действительно узкое место, посмотрите на реальную глубину очереди операций в момент пика — при низком параллелизме выигрыш NVMe относительно SATA SSD будет намного скромнее, чем в синтетических бенчмарках производителя.

Если после этих шагов диск подтверждён как узкое место — переход на NVMe оправдан. Если нет — деньги стоит вложить туда, где реально болит: в CPU, RAM, оптимизацию запросов или кэш.

Когда NVMe даёт реальный, ощутимый эффект

Есть сценарии, где переход на NVMe — не мода, а рациональное решение с предсказуемым результатом:

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

Частые вопросы