Зачем тестировать и сравнивать: цели и методология нашего исследования
Выбор дисков, RAID-конфигурации и файловой системы в 2026 году — это не просто вопрос стоимости и емкости. Это фундаментальное решение, которое определяет производительность и надежность всей вашей инфраструктуры. Спецификации производителей часто дают лишь теоретические максимумы, а реальная производительность в рабочих условиях зависит от множества факторов: типа нагрузки, конфигурации RAID, настройки файловой системы и даже версии ПО. Эта статья предоставляет результаты практических тестов, проведенных на актуальном оборудовании и программных версиях, чтобы дать вам объективную картину и готовые инструменты для принятия взвешенных решений.
Все тесты были проведены в марте 2026 года на следующем стенде:
- Накопители: NVMe SSD PCIe 4.0 (например, Samsung PM9A3), SATA SSD (например, Crucial MX500), HDD SATA 7200 RPM (например, Seagate IronWolf).
- Конфигурации RAID: Программный RAID через mdadm (RAID5, RAID6, RAID10) и ZFS (mirror, RAIDZ1, RAIDZ2).
- Файловые системы: ZFS (версия из FreeBSD 14-STABLE), ext4 (с параметрами noatime, nodiratime), XFS.
- Система: Ubuntu Server 24.04 LTS с актуальными патчами, 12-ядерный CPU, 64 GB RAM.
- Инструменты: fio (Flexible I/O Tester) 3.36, стандартные утилиты dd и iostat.
Мы оценивали три ключевые метрики: IOPS (операции ввода-вывода в секунду) для случайного доступа, пропускную способность (MB/s) для последовательного доступа и задержку (latency), особенно критичную для баз данных. Акцент был сделан на устойчивом состоянии (steady-state) после продолжительных тестов, что отражает реальную рабочую нагрузку.
Методика нагрузочного тестирования: как мы получали цифры
Для получения релевантных результатов мы использовали fio с профилями, имитирующими разные рабочие нагрузки. Каждый тест длился не менее 5 минут для выхода на steady-state. Ключевые параметры:
- Размер блока (bs): 4k, 8k для нагрузок типа СУБД; 128k, 1M для файловых серверов.
- Глубина очереди (iodepth): От 1 (для измерения чистой задержки) до 32 (для максимальной параллельной нагрузки).
- Обход кэша (direct=1): Все тесты выполнялись с прямым I/O, чтобы исключить влияние кэша ОС и получить чистые результаты работы дисков.
- Измерение задержки: Особое внимание уделялось 99-му и 99.99-му перцентилям (clat percentiles), так как они показывают худшие случаи, критичные для пользовательского опыта.
Пример команды для тестирования случайного чтения (random read), характерного для OLTP-баз данных:
fio --name=random-read --ioengine=libaio --rw=randread --bs=4k --size=10G --numjobs=4 --iodepth=16 --runtime=300 --time_based --direct=1 --group_reportingЭта команда создает 4 параллельных потока (numjobs=4) с глубиной очереди 16 (iodepth=16) и выполняет случайное чтение блоков размером 4k на протяжении 300 секунд. Вывод fio дает детальную статистику по IOPS, пропускной способности и задержкам для каждого потока и в целом.
Бенчмарки 2026: NVMe vs SATA SSD vs HDD в разных сценариях
Результаты тестов четко показывают, что разрыв между NVMe и SATA SSD остается значительным, особенно для задач с высокой параллельностью и низкой задержкой. HDD, несмотря на рост емкости, остаются узким местом для любых задач, требующих скорости.
| Сценарий / Тип накопителя | IOPS (Random Read 4k) | Пропускная способность (Seq. Read 1M) | Задержка (99-й перцентиль, Random Read) |
|---|---|---|---|
| NVMe SSD (PCIe 4.0) | ~800 000 | ~6500 MB/s | ~150 μs |
| SATA SSD | ~90 000 | ~550 MB/s | ~900 μs |
| HDD (7200 RPM) | ~150 | ~200 MB/s | ~15 ms |
NVMe обеспечивает примерно 9x больше IOPS и 12x выше пропускную способность при последовательном чтении по сравнению с SATA SSD. Задержка NVMe на порядок ниже, что критично для транзакционных систем.
Производительность для рабочих нагрузок СУБД (высокий IOPS, низкая задержка)
Для баз данных типа PostgreSQL или MySQL, где доминируют операции случайного чтения и записи малых блоков (4k-8k), NVMe является безальтернативным выбором в 2026 году. Наши тесты показали, что даже один NVMe диск превосходит по IOPS массив из 4 SATA SSD в RAID10. Ключевой показатель — задержка на 99-м перцентиле: для NVME она оставалась в пределах 200 микросекунд даже под высокой нагрузкой, тогда для SATA SSD она превышала 1 миллисекунд, что уже может ощущаться в высоконагруженных системах.
При использовании SATA SSD для СУБД важно обеспечить достаточную параллельность: несколько дисков в RAID10 могут увеличить совокупный IOPS, но не улучшают индивидуальную задержку каждого запроса. Для средних нагрузок это может быть приемлемым компромиссом.
Пропускная способность для веб-сервисов и хранилищ данных
Для веб-сервисов, файловых хранилищ или систем резервного копирования, где часто происходит передача больших файлов (последовательный доступ), пропускная способность становится ключевой метрикой. Здесь NVMe также лидирует, но для многих сценариев SATA SSD уже предоставляет достаточную скорость. Например, для веб-сервера, раздающего статичные файлы через сеть 1 Gbps (максимум ~125 MB/s), даже один SATA SSD (~550 MB/s) не будет ограничивающим фактором — узким местом станет сеть.
Для NAS или систем архивирования, где емкость важнее скорости, массивы HDD в RAID6 могут обеспечить приемлемую пропускную способность (~600-800 MB/s из 4 дисков), но задержка при случайном доступе будет катастрофически высокой. Такие массивы подходят только для последовательных операций.
RAID и файловые системы: ZFS против mdadm/ext4 на практике
Выбор между программным RAID (mdadm) и ZFS — это выбор между простотой и функциональностью. Наши тесты на массиве из 4 одинаковых SATA SSD показали следующие результаты для различных конфигураций:
| Конфигурация / Файловая система | Скорость записи (Sequential Write 1M) | Скорость чтения (Random Read 4k) | Нагрузка на CPU (во время rebuild) |
|---|---|---|---|
| mdadm RAID10 + ext4 | ~1050 MB/s | ~350 000 IOPS | Средняя |
| mdadm RAID6 + ext4 | ~450 MB/s | ~270 000 IOPS | Высокая |
| ZFS mirror (2x2 диска) | ~1100 MB/s | ~340 000 IOPS | Низкая |
| ZFS RAIDZ1 (аналог RAID5) | ~380 MB/s | ~250 000 IOPS | Средняя |
| ZFS RAIDZ2 (аналог RAID6) | ~350 MB/s | ~240 000 IOPS | Высокая |
RAID10 (или ZFS mirror) демонстрирует наилучшую производительность записи и чтения, но «стоимость» в виде потерянной емкости (50%) высока. RAID5/6 (или RAIDZ1/Z2) более эффективны по емкости, но имеют значительный «штраф» на запись (write penalty), что видно по результатам. ZFS в целом показывает сопоставимые с mdadm цифры по чистой производительности, но добавляет огромный набор дополнительных функций: моментальные снапшоты, дедупликация, компрессия, саморемонт данных.
ZFS: особенности производительности пулов и файловых систем
Ключевой параметр ZFS, влияющий на производительность — recordsize (или volblocksize для zvol). Для нагрузок, характерных для баз данных (малые случайные операции), оптимальный recordsize равен 8k или 16k, что соответствует размеру страницы большинства СУБД. Для файловых серверов с большими файлами recordsize можно увеличить до 128k или 1M для повышения пропускной способности. Неправильный выбор этого параметра может снизить производительность на 30-50%.
Кэши ARC (Adaptive Replacement Cache) в памяти эффективно ускоряет повторное чтение, но для увеличения кэша для чтения можно добавить L2ARC на быстром SSD (например, NVMe). SLOG (Separate LOG) — это не кэш записи, а устройство для журнала метаданных транзакций ZFS. Использование быстрого NVMe диска с высокой отказоустойчивостью (например, с зеркалированием) для SLOG может значительно уменьшить задержку операций синхронной записи, критичных для NFS или СУБД. Однако, использование обычного потребительского NVMe для SLOG — это риск, так как при его отказе может быть потеряна целостность данных.
Компрессия (например, lz4) в ZFS обычно дает положительный эффект: уменьшение объема данных часто компенсирует накладные расходы на сжатие, особенно при последовательном чтении/записи. Для наших тестов с lz4 компрессия показала небольшой прирост (~5%) в пропускной способности для текстовых данных.
Аппаратный RAID: есть ли смысл в 2026 году?
Аппаратные RAID-контроллеры с собственным процессором и кэшем (часто с батарейкой BBU) исторически использовались для разгрузки CPU и обеспечения стабильности кэша записи. Наши сравнения показали, что для современных многоядерных CPU разница в нагрузке между аппаратным RAID (например, на контроллере с кэшем 1GB) и программным mdadm или ZFS стала минимальной в большинстве сценариев.
Преимущества аппаратного RAID сегодня сводятся к:
- Стабильность кэша с BBU: Гарантия, что данные в кэше записи не будут потеряны при сбое питания.
- Упрощенное управление: Единый интерфейс для создания и мониторинга массива, независимый от ОС.
Недостатки, однако, стали более весомыми:
- Вендор-лок и стоимость: Миграция массива на другой контроллер часто невозможна.
- Сложность диагностики: Проблемы могут быть специфичными для контроллера.
- Ограниченная функциональность: Отсутствие таких функций как снапшоты, дедупликация, саморемонт (ZFS).
В 2026 году аппаратный RAID может быть оправдан в специфических сценариях, где требуется максимальная стабильность кэша записи для критических транзакционных систем, и где функциональность ZFS не требуется. Для большинства других случаев программные решения (особенно ZFS) предлагают лучшую гибкость, функциональность и часто сопоставимую производительность. Если вы работаете с ZFS, то готовые конфигурации и оптимизации для TrueNAS могут дать значительный прирост производительности для вашего файлового сервера или хранилища виртуальных машин.
Готовые команды fio и методика замера в вашей среде
Теперь, имея понимание результатов, вы можете провести собственные тесты в своей инфраструктуре. Это особенно важно, если ваша нагрузка или оборудование отличаются от нашего тестового стенда.
1. Установка fio: В большинстве дистрибутивов Linux fio доступен из репозиториев.
apt install fio # для Debian/Ubuntu
yum install fio # для CentOS/RHEL2. Создание тестового файла: fio работает с файлами, поэтому нужно создать файл, который будет использоваться для тестов. Убедитесь, что он создается на том разделе или файловой системе, которую хотите тестировать.
touch /mnt/teststorage/testfile.fio
# или используйте параметр filename в команде fio3. Набор готовых команд fio для типовых сценариев:
- Быстрый тест «на вскидку» (смешанная нагрузка):
fio --name=quick-test --ioengine=libaio --rw=randrw --bs=4k --size=1G --numjobs=1 --iodepth=4 --runtime=60 --time_based --direct=1 --group_reporting - Полное тестирование для БД (random read/write):
fio --name=db-test --ioengine=libaio --rw=randrw --bs=8k --size=10G --numjobs=8 --iodepth=16 --runtime=300 --time_based --direct=1 --group_reporting - Тестирование пропускной способности (sequential):
fio --name=seq-test --ioengine=libaio --rw=read --bs=1M --size=20G --numjobs=1 --iodepth=1 --runtime=120 --time_based --direct=1 --group_reporting - Измерение задержек (low queue depth):
fio --name=latency-test --ioengine=libaio --rw=randread --bs=4k --size=1G --numjobs=1 --iodepth=1 --runtime=180 --time_based --direct=1 --group_reporting
4. Что делать, если результаты ниже ожидаемых: Проверьте выравнивание разделов (особенно для RAID), убедитесь, что тесты запускаются с direct=1 (обход кэша), проверьте параметры монтирования файловой системы (например, noatime для ext4 может помочь), исключите сетевые ограничения (если тестируете сетевое хранилище). Также убедитесь, что на дисках достаточно свободного пространства — производительность SSD может падать при заполнении.
Интерпретация результатов: на что смотреть в выводе fio
После запуска fio вы получите подробный отчет. Ключевые строки:
- IOPS:
read: IOPS=85.3k, write: IOPS=78.9k— показывает количество операций в секунду. - Пропускная способность (bandwidth):
read: BW=341MiB/s (358MB/s), write: BW=316MiB/s (332MB/s)— скорость передачи данных. - Задержка (latency, clat): Особенно важны перцентили:
clat percentiles (usec): 99.00th=[ 1200], 99.99th=[ 2500]. 99-й перцентиль показывает, что 99% операций завершились за 1200 микросекунд или меньше. 99.99-й перцентиль (2500 микросекунд) показывает «худшие» случаи, которые могут быть критичны для пользователей. Средняя задержка (clat avg) менее информативна, так как маскирует редкие, но длительные операции.
Если вы видите высокие значения на 99.99-м перцентиле, это указывает на периодические просадки (latency spikes), которые могут быть вызваны внутренними процессами диска (например, сборкой мусора на SSD) или проблемами в драйвере/файловой системе.
Итоговые рекомендации по выбору конфигурации на 2026 год
На основе проведенных тестов и анализа современных тенденций можно сформулировать следующие рекомендации для различных сценариев использования.
- Высоконагруженная база данных (OLTP, например, PostgreSQL, MySQL):
Выбирайте NVMe диски в конфигурации зеркала (ZFS mirror или RAID10). Это обеспечит максимальные IOPS и минимальную задержку. Для ZFS обязательно установите recordsize=8k или 16k, соответствующий размеру страницы вашей СУБД. Рассмотрите добавление выделенного SLOG на отказоустойчивом NVMe для снижения задержки синхронной записи. Конфигурации RAID5/6 (или RAIDZ1/Z2) для такой нагрузки не рекомендуются из-за высокого write penalty. - Файловое хранилище / Веб-сервер (преобладает последовательный доступ, большие файлы):
SATA SSD в RAIDZ2 (ZFS) или RAID6 (mdadm/ext4) будут эффективным выбором, обеспечивая хорошую пропускную способность и отказоустойчивость при приемлемой стоимости. Для ZFS установите recordsize=1M. Если нагрузка очень высокая или требуется низкая задержка для множества мелких файлов, переходите на NVMe. Убедитесь, что ваша сеть (например, 10GbE) не станет узким местом после перехода на быстрые диски. - Архивное / холодное хранение (емкость важнее скорости):
HDD в RAID6 (или RAIDZ2) с активным мониторингом состояния дисков (smartctl, zpool status). Используйте компрессию в ZFS для экономии пространства. Производительность будет низкой для случайного доступа, но достаточной для последовательного чтения/записи больших файлов. - Гиперконвергентная инфраструктура / виртуализация:
NVMe диски обязательны. Рассмотрите распределенные решения типа vSAN или аналоги, которые используют локальные NVMe диски на каждом узле, создавая общий пул хранения. Для традиционных SAN/NAS используйте NVMe в зеркалах или RAID10 на уровне хранилища.
При оптимизации производительности важно рассматривать систему целиком. Например, неправильная настройка Docker-томов может существенно ограничить преимущества быстрых дисков. Для контейнеров с базами данных или кэшами обязательно обратитесь к практическим рекомендациям по оптимизации Docker-томов, где подробно разбираются параметры монтирования и выбор файловой системы хоста.
Чего избегать: типовые ошибки и узкие места
На основе нашего опыта тестирования и реальных случаев, мы выделяем следующие анти-паттерны:
- RAID5/6 на SATA SSD для высокой нагрузки на запись: Write penalty в таких конфигурациях приводит к значительному снижению производительности записи (до 60% по сравнению с RAID10). Используйте зеркала или RAID10.
- Неправильное выравнивание разделов на RAID: Особенно критично для RAID5/6 и SSD. Неправильное выравнивание может снизить производительность на 10-30%. Используйте инструменты типа
fdisk -lдля проверки. - Игнорирование wear leveling и состояния SSD: Регулярно проверяйте SMART-атрибуты (smartctl) или статус пула ZFS (zpool status) для предупреждения о деградации.
- SLOG на обычном потребительском NVMe диске: Это создает риск потери данных при отказе диска. Для SLOG используйте только диски с высокой отказоустойчивостью (например, модели с повышенной надежностью) и обязательно в зеркале.
- Сетевой bottleneck: Размещение массива NVMe, способного выдавать 6000 MB/s, behind сетью 1 Gbps (125 MB/s) — бессмысленно. Сопоставляйте скорость сети и дисков.
Тренд 2026 года: узкие места в дисковых системах все чаще смещаются от самих накопителей к другим компонентам — сети, памяти (особенно для кэширования) и даже к программным настройкам файловых систем и приложений. Тщательное тестирование и балансировка всей системы становятся критически важными.