Введение
Хранилище напрямую влияет на скорость приложений. NVMe обещает «в разы быстрее», но не всегда эта скорость превращается в пользу для конкретного проекта. Разберёмся, где NVMe критичен, а где SATA остаётся разумным и экономичным выбором.
Кратко: NVMe и SATA — в чём разница
- Интерфейс:
- SATA (AHCI) — исторически для HDD, ограничение ~600 MB/s на устройство.
- NVMe — современный протокол поверх PCIe, множественные очереди, низкая латентность.
- Латентность (порядок величин):
- SATA SSD: ~80–120 мкс.
- NVMe SSD: ~20–40 мкс (и ниже у топовых моделей).
- Параллелизм: NVMe поддерживает тысячи команд в десятках очередей, SATA — одна очередь на 32 команды.
Производительность и латентность
- Последовательное чтение/запись: NVMe достигает нескольких GB/s, SATA ограничен ~550 MB/s.
- Случайное чтение/запись 4K (типично для БД): NVMe даёт кратно больше IOPS при меньшей задержке.
- Стабильность под нагрузкой: у NVMe выше устойчивость при росте очередей и смешанных паттернах (R/W 70/30).
Типы нагрузок: где что выбирать
- Базы данных OLTP (PostgreSQL, MySQL): NVMe почти всегда окупается — чувствительность к латентности максимальна.
- Кеши и очереди (Redis, Kafka, RabbitMQ): NVMe улучшает p99 задержки и пропускную способность.
- CI/CD, сборки, Docker-образы: NVMe ускоряет распаковку, компиляции, интенсивную работу с мелкими файлами.
- Логи, аналитика (ELK, ClickHouse): NVMe полезен при высокой конкурентности; для «холодного» слоя SATA допустим.
- Статический контент, лендинги, простые API: SATA обычно достаточно, узкое место — сеть/CPU.
- Бэкапы и холодные данные: SATA/объектное хранилище оптимальнее по цене за GB.
Профили I/O: на что смотреть
- 4K random R/W — главный ориентир для БД.
- Очередь (queue depth): у NVMe производительность лучше масштабируется.
- Метрики p95/p99: усреднения скрывают хвосты задержек; смотрите распределение.
Виртуализация и контейнеры
- Over-subscription на уровне площадки может нивелировать преимущества. Выбирайте тарифы с гарантированными IOPS/Latency, если есть.
- Драйверы: для KVM — virtio-blk/nvme, актуальное ядро; это снижает накладные расходы стека.
Надёжность, ресурс и троттлинг
- TBW/DWPD: ориентируйтесь на паспортный ресурс — для нагрузок с интенсивной записью NVMe-модели обычно выносливее.
- PLP (Power Loss Protection): критично для БД — снижает риск потерь при внезапном отключении.
- Тепловой троттлинг: NVMe под длительной нагрузкой может сбрасывать частоты — следите за охлаждением на «железе».
Экономика: €/GB и €/IOPS
- SATA выигрывает по цене за объём.
- NVMe выигрывает по цене за IOPS и по «стоимости миллисекунды». Если 1% ускорения даёт ощутимый бизнес-эффект — NVMe выгоднее.
Практика: как проверить свою нагрузку
Минимальный тест перед миграцией на NVMe:
# чтение 4K random, 1 минута
fio --name=randread --filename=/mnt/vol/testfile --size=2G \
--bs=4k --iodepth=32 --rw=randread --ioengine=libaio --direct=1 --runtime=60 --time_based
# запись 4K random, 1 минута (осторожно в проде)
fio --name=randwrite --filename=/mnt/vol/testfile --size=2G \
--bs=4k --iodepth=32 --rw=randwrite --ioengine=libaio --direct=1 --runtime=60 --time_based
Сравните IOPS и латентность (clat p95/p99) на ваших данных/сценариях.
Тюнинг Linux (коротко)
- Планировщик I/O: для NVMe обычно
none
/mq-deadline
, для SATA —mq-deadline
/bfq
(зависит от ядра). - Mount options:
noatime
, корректныйcommit
для ext4/xfs по требованиям консистентности. - TRIM: периодический
fstrim
илиdiscard
для длительной стабильности. - RAID: mdadm RAID10 для записи, RAID0 для максимальной производительности (без отказоустойчивости).
Файловые системы и БД
- ext4 — консервативно и предсказуемо.
- xfs — хорошо масштабируется на больших NVMe.
- Для PostgreSQL: следите за
effective_io_concurrency
,checkpoint_timeout
, размером WAL и местом его хранения.
Мониторинг
- I/O:
iostat -x 1
,pidstat -d 1
. - SMART/здоровье:
smartctl -a
(если доступно). - Нагрузочные пики: отслеживайте p95/p99 latency и queue depth на уровне приложения.
Частые ошибки
- Переезд на NVMe без анализа: узкое место может быть в CPU/сети/БД-планах.
- Отсутствие TRIM — деградация со временем.
- «Все в один том»: WAL/журналы и данные лучше разводить по разным устройствам/слоям.
Чеклист выбора
- Нужны ли p99 < 2–3 мс под пиковой нагрузкой? → NVMe.
- Много мелких R/W 4K, высокая конкурентность? → NVMe.
- Преимущественно большие последовательные чтения, экономия важнее? → SATA.
- Бэкапы/архивы/статический контент? → SATA/объектное.
FAQ
NVMe всегда быстрее? Быстрее по потенциалу, но итог зависит от стека и реальной нагрузки.
Можно ли совместить? Да: горячие данные — NVMe, холодные — SATA/объектное.
Как понять, что упираюсь в диск? Высокий iowait, рост очередей, ухудшение p95/p99 при увеличении нагрузки — сигналы I/O-бутылочного горлышка.
Итоги
- NVMe — для латентности и IOPS-чувствительных задач.
- SATA — для объёма, экономии и «холодных» сценариев. Главное — измерять свою нагрузку и выбирать по метрикам, а не только по рекламным цифрам.