Хранилище и производительность серверов: как диски и файловые системы влияют на скорость работы

Короткий ответ: почему сервер может тормозить из-за хранилища

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

Главные признаки узкого места в подсистеме хранения: рост latency, очереди ввода-вывода, iowait и времени ответа сервиса. Высокая загрузка диска сама по себе не доказывает проблему: SSD и HDD могут работать при разной степени занятости и давать разный результат на одинаковом профиле нагрузки.

Проверку начинают с фиксации симптома и SLA, затем сопоставляют показатели приложения с IOPS, задержкой, throughput, queue depth и состоянием устройств. В Linux для первичной проверки используют iostat, vmstat, iotop и pidstat, а fio применяют позже, на отдельном тестовом файле или томе.

Какие симптомы указывают на узкое место в дисках

• Запросы к базе данных периодически выполняются дольше обычного, хотя загрузка CPU не достигла лимита.
• Контейнеры и виртуальные машины долго запускаются, останавливаются или зависают на операциях с файловой системой.
• Деплой занимает больше времени из-за распаковки архивов, записи логов, создания образов и большого числа мелких файлов.
• Резервное копирование или восстановление идет с нестабильной скоростью, а время ответа рабочих сервисов ухудшается.
• В мониторинге растут await, queue depth и iowait, появляются всплески записи или чтения на конкретном устройстве.
• Сервис отвечает рывками: среднее время отклика выглядит приемлемо, но хвостовые задержки для отдельных запросов резко увеличиваются.

Каждый симптом требует проверки. Медленный SQL-запрос, нехватка памяти, swap, DNS или перегруженный гипервизор могут выглядеть как проблема диска. Для понимания слоев хранения полезно заранее разобрать архитектуру программного хранилища, включая диски, RAID, пул, файловую систему, кеш, сеть и репликацию.

Почему свободные CPU и RAM не исключают проблему хранения

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

Пример причинной цепочки: база данных отправляет запись журнала, файловая система ждет подтверждения fsync, RAID-контроллер обрабатывает запись с четностью, а приложение удерживает рабочий поток. CPU остается свободным, RAM не исчерпана, но пользователь получает более долгий ответ.

Кеширование способно временно скрыть проблему. Данные попадают в page cache или кеш контроллера, и операция быстро возвращается приложению. Когда накопленный объем нужно сбросить на устройство, latency и очередь растут. Поэтому замер в спокойный момент без учета периода flush не описывает поведение сервера под длительной нагрузкой.

IOPS, latency, throughput и очередь ввода-вывода простыми словами

Четыре метрики описывают разные стороны одного процесса. IOPS показывает число операций, latency - время обслуживания операции, throughput - объем переданных данных, а queue depth - накопившийся параллелизм запросов. Их нужно читать вместе с размером блока, долей чтения и записи, случайным или последовательным доступом и количеством потоков.

IOPS: сколько операций чтения и записи выполняет хранилище

IOPS, input/output operations per second, означает количество операций ввода-вывода за секунду. Одна операция может работать с блоком 4 KiB, 8 KiB, 64 KiB или другим объемом, поэтому само число IOPS не говорит о пропускной способности без размера блока.

Расчет простой: 100 IOPS при блоке 8 KiB дают примерно 0,78 MiB/s. 10 000 IOPS при блоке 4 KiB дают около 39 MiB/s. Два теста с одинаковыми IOPS могут передавать разный объем данных, если их block size отличается.

IOPS особенно полезны для баз данных, виртуальных машин и каталогов с большим количеством мелких файлов. Журнал транзакций часто создает последовательную запись с требованиями к задержке, рабочий набор базы данных дает смесь случайных чтений и записей, а datastore виртуализации обслуживает запросы нескольких гостевых систем одновременно.

На показатель влияют:

• размер блока;
• соотношение read/write;
• random или sequential доступ;
• глубина очереди и число параллельных заданий;
• кеш операционной системы, RAID-контроллера или устройства;
• заполнение SSD и длительность записи.

Скорость копирования большого файла может выглядеть высокой при низких IOPS. Это нормальный результат последовательной нагрузки и плохой ориентир для транзакционной базы данных.

Latency: метрика, которая влияет на время ответа приложения

Latency - задержка между отправкой I/O-запроса и получением результата. Для синхронной операции она напрямую попадает в время ответа приложения. Если поток последовательно ждет несколько операций, задержки складываются.

Среднее значение скрывает редкие медленные операции. В рабочем мониторинге полезно смотреть p95, p99 или другой согласованный перцентиль, если система его предоставляет. Хвост latency часто растет во время flush, rebuild, конкурирующего backup, заполнения кеша или работы массива с четностью.

Сопоставляйте latency с профилем нагрузки. Для большого последовательного чтения задержка одной операции может быть менее заметна, чем throughput. Для журнала базы данных или синхронной записи небольшая прибавка к каждой операции быстро увеличивает время ответа.

Throughput: когда важна пропускная способность в МБ/с

Throughput показывает, какой объем данных система передает за единицу времени. Его обычно измеряют в MB/s или MiB/s, причем эти единицы нельзя смешивать без оговорки: MB использует десятичные множители, MiB - двоичные.

Пропускная способность важна для резервного копирования, репликации, переноса больших файлов, медиапотоков, восстановления образов и последовательного сканирования данных. Здесь результат ограничивает самый медленный участок пути: устройство, SATA или PCIe, контроллер, RAID, сеть NAS или SAN, CPU для сжатия и параметры приложения.

Высокий throughput не компенсирует высокую задержку при мелких случайных операциях. Обратная ситуация тоже возможна: хранилище быстро обслуживает короткие запросы, но плохо подходит для длительной передачи больших блоков.

Очередь I/O: как отличить рабочую нагрузку от накопившейся задержки

Queue depth показывает число ожидающих или обслуживаемых запросов. Очередь появляется, когда приложение создает I/O быстрее, чем устройство или слой хранения успевает его завершать. На NVMe параллельная работа может быть штатной, а для HDD та же очередь способна быстро увеличить задержку.

Длинная очередь не всегда означает неисправность. Она может быть следствием корректно настроенного параллелизма и высокой загрузки устройства. Тревожная комбинация выглядит иначе: очередь устойчиво растет, latency увеличивается, а сервис теряет время ответа.

Оценивать очередь нужно вместе с числом операций, размером блока, utilization, ошибками устройства и нагрузкой приложения. Универсального допустимого значения queue depth нет: его задают возможности конкретного носителя и требования SLA.

Как диски влияют на скорость работы сервера

Путь I/O проходит через приложение, системные вызовы, page cache, драйвер, контроллер или HBA, RAID, файловую систему и само устройство. В NAS или SAN к этому пути добавляются сеть, протокол доступа и конкуренция за общий пул. Итоговую скорость задает вся цепочка, а не паспортная цифра одного диска.

HDD, SATA SSD и NVMe: какие нагрузки они обслуживают по-разному

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

SATA SSD не имеет механической задержки, но его итоговую скорость ограничивает интерфейс SATA. Для ОС, веб-сервисов, умеренных баз данных и файловых операций он часто дает заметный выигрыш относительно HDD.

NVMe работает через PCIe и рассчитан на большое число параллельных очередей. Он особенно полезен для интенсивных случайных операций, виртуализации, высоконагруженных баз данных и временных рабочих наборов. Результат зависит от числа линий PCIe, поколения платформы, охлаждения и модели SSD.

Потребительские SSD могут менять поведение при длительной записи. После заполнения быстрого SLC-кеша, при высокой температуре или почти полном заполнении накопителя throughput и latency способны заметно ухудшиться. Сравнивать носители нужно на длительном прогоне с рабочим размером данных, а не по короткому пиковому тесту.

Практические результаты для NVMe, SATA SSD, HDD, RAID и ZFS собраны в сравнении дисковых подсистем. Его удобно использовать при подготовке собственного тестового сценария.

Почему случайные операции обычно сложнее последовательных

При последовательном доступе соседние блоки читаются или записываются подряд. Устройство и файловая система могут заранее планировать такие операции, поэтому throughput растет. Резервное копирование большого образа часто использует именно этот профиль.

При случайном доступе запросы обращаются к разным участкам устройства. У HDD перемещение головок добавляет механическое ожидание. SSD избегает механики, но все равно обрабатывает трансляцию адресов, очистку блоков, выравнивание записи и конкуренцию запросов.

Размер блока меняет картину. Запись 4 KiB и запись 1 MiB требуют разного числа операций, занимают разные очереди и дают разные IOPS. База данных, виртуальные диски и каталоги с мелкими файлами редко похожи на копирование одного большого файла.

Контроллер, интерфейс и сеть: ограничения за пределами диска

Диск может иметь запас производительности, а сервер все равно упираться в HBA, RAID-контроллер, PCIe-слот, SATA-линейку или сетевой линк. Проверьте режим линка, согласованную ширину PCIe, ошибки интерфейса, прошивку контроллера и распределение устройств по шинам.

Для RAID-контроллера нужно знать состояние кеша, политику write-back или write-through, наличие защиты питания и текущую фоновую работу. Неполадка батареи или supercapacitor может перевести контроллер в более безопасный режим записи и увеличить latency.

Удаленное хранилище добавляет сетевую задержку, потери пакетов, ограничение пропускной способности и конкуренцию между клиентами. В виртуализации несколько ВМ могут одновременно обращаться к одному datastore. В такой ситуации замена диска без анализа гипервизора и сети не подтверждает причину деградации.

RAID и производительность серверного хранилища

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

Как RAID меняет чтение, запись и задержки

При зеркалировании чтение можно распределять между копиями, а запись нужно подтвердить на каждом нужном диске. Полосование делит данные между устройствами и повышает параллелизм, но отказоустойчивость без зеркала отсутствует.

RAID 5 и RAID 6 хранят контроль четности. Для небольшой случайной записи массиву часто требуется прочитать старые данные и старую четность, вычислить новую четность и записать измененные блоки. Такой read-modify-write создает дополнительную работу, которую называют write penalty.

Фактическая задержка зависит от размера блока, выравнивания, реализации контроллера, кеша и состояния массива. Во время rebuild или resilver свободные ресурсы устройств расходуются на восстановление, поэтому рабочая нагрузка может получить более высокую latency.

RAID 1, RAID 10, RAID 5 и RAID 6: выбор по сценарию

Для ОС и сервисов часто достаточно зеркала, если емкость невелика. ВМ и транзакционная БД обычно требуют низкой latency при записи, поэтому RAID 10 часто проще согласовать с таким профилем. RAID 5 и RAID 6 выбирают после расчета емкости, допустимого окна восстановления, размера массива и характера записи.

Формулы IOPS, throughput и задержек для баз данных и виртуальных машин разобраны в руководстве по расчету производительности СХД. Расчет полезнее выбора RAID по числу дисков в сервере.

Почему RAID не заменяет резервное копирование

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

Резервная копия должна иметь отдельную точку отказа и проверенный сценарий восстановления. Для нее важны throughput, окно backup, срок хранения, объем ежедневных изменений и допустимое время восстановления.

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

Файловая система и кеширование: где меняется поведение I/O

Одинаковые диски дают разный результат при разных файловых системах и политике записи. Файловая система распределяет блоки, ведет журнал или метаданные, обрабатывает flush, создает снимки и взаимодействует с кешем ОС. Эти операции меняют профиль нагрузки еще до обращения к устройству.

ext4, XFS и ZFS: на какие задачи смотреть при выборе

ext4 обычно выбирают как универсальную Linux-файловую систему с журналированием и широким набором инструментов. При выборе оценивают размер тома, число файлов, требования к совместимости и сценарий восстановления.

XFS хорошо подходит для больших файлов, крупных томов и параллельных операций с каталогами. Его свойства нужно проверять на реальной нагрузке: профиль метаданных, размеры блоков, модель резервирования пространства и инструменты администрирования влияют на итог.

ZFS объединяет файловую систему и управление пулом, использует контрольные суммы, copy-on-write, снимки и кеш ARC. Такой набор функций меняет требования к памяти, дискам и планированию пула. До запуска нужно определить схему vdev, требования к свободному месту, тип данных, политику синхронной записи и правила резервного копирования.

Сравнивайте ext4, XFS и ZFS по конкретным критериям:

• размер и количество файлов;
• доля случайных и последовательных операций;
• требования к снимкам, квотам и контролю целостности;
• потребление RAM и поведение кеша;
• модель управления томами и совместимость с ОС;
• время восстановления после отказа и доступные инструменты проверки.

Page cache и кеш записи: почему бенчмарк может не отражать состояние диска

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

Операции flush и fsync заставляют систему передать данные на следующий слой и дождаться нужного подтверждения. Их поведение зависит от файловой системы, драйвера, контроллера и самого SSD. Параметр direct=1 в fio помогает обойти page cache, но не отменяет кеш устройства или контроллера.

Перед тестом фиксируйте, что именно измеряется: файловая система, кеш ОС, контроллер или накопитель. Сопоставляйте результат с мониторингом во время длительного прогона, когда кеш заполнен и устройство обслуживает устойчивую нагрузку.

Синхронная запись, журналирование и компромисс между скоростью и надежностью

Синхронная запись нужна приложениям, которым важно получить подтверждение сохранения перед продолжением работы. База данных может использовать такие операции для журнала транзакций. Ожидание безопасной фиксации данных увеличивает latency, зато снижает риск потери подтвержденных изменений при сбое питания.

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

Write-back кеш допустим при наличии защиты питания и корректной политике восстановления. Отключать барьеры, flush или синхронную запись ради красивого результата бенчмарка нельзя без анализа модели отказов, требований приложения и плана отката.

Как диагностировать медленное хранилище на рабочем сервере

Диагностика должна идти от симптома к измерению. Сначала фиксируют, что замедлилось, затем находят совпадение по времени в метриках ОС, устройства, RAID и приложения. Изменение параметров до сбора baseline усложняет сравнение и может скрыть исходную причину.

Шаг 1. Зафиксируйте симптомы и профиль нагрузки

Запишите время начала и окончания инцидента, затронутый сервис, путь к данным, тип операции и изменение времени ответа. Отдельно отметьте события, которые совпали с деградацией: backup, rebuild, миграция ВМ, выпуск новой версии, рост трафика или изменение размера базы.

Опишите профиль I/O:

• read, write или смешанная нагрузка;
• random или sequential доступ;
• размер блока и размер файлов;
• число параллельных запросов;
• пиковая и обычная скорость в IOPS и MB/s;
• требования к latency и синхронной записи.

Baseline должен содержать измерения при нормальной работе: время ответа сервиса, IOPS, throughput, latency, очередь, iowait, ошибки и состояние RAID. Снимайте показатели до изменений и на сопоставимой нагрузке после них.

Шаг 2. Проверьте метрики ОС и устройства

Для Linux начните с:

iostat -xz 1
vmstat 1
iotop -oPa
pidstat -d 1

iostat -xz 1 выводит расширенные показатели устройств с интервалом в одну секунду. Смотрите r/s и w/s, объем чтения и записи, await, queue, utilization и поля, связанные с обработкой устройства. Названия и единицы могут отличаться между версиями sysstat, поэтому сверяйте их с локальной справкой.

vmstat 1 помогает сопоставить iowait с общей активностью CPU, памятью и swap. iotop показывает процессы с интенсивным I/O, а pidstat -d 1 дает разрез по процессам. Эти данные помогают отличить нагрузку базы данных от backup, логирования, контейнерного runtime или фоновой индексации.

Сопоставьте имя устройства с точкой монтирования:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Для мониторинга удаленного хранилища добавьте сетевую задержку, ошибки интерфейса, retransmit, загрузку линка и показатели самого NAS, SAN или datastore. Один сервер может показывать низкий utilization локального диска, пока запросы ждут сеть или общий массив.

Шаг 3. Исключите проблемы RAID, ошибок дисков и заполнения файловой системы

Сначала проверьте аварийные признаки. Для программного Linux RAID используют:

cat /proc/mdstat
mdadm --detail /dev/md0

Для ZFS проверяют состояние пула командой:

zpool status

Ищите degraded-состояние, rebuild, resync, resilver, checksum errors, read errors и write errors. Фоновое восстановление может объяснить просадку скорости, но не отменяет проверку причин отказа.

Проверьте системный журнал и SMART конкретного диска. Команда ниже требует прав администратора и корректного имени устройства:

smartctl -a /dev/sdX

Смотрите ошибки интерфейса, переназначенные сектора, признаки деградации SSD, температуру и ресурс записи. Значения SMART нужно трактовать по модели устройства и документации производителя, а не по одному универсальному порогу.

Проверьте свободное место и inode:

df -h
df -i

Почти заполненная файловая система усложняет размещение новых блоков и работу с метаданными. Для thin provisioning отдельно проверяют заполнение физического пула, снапшоты и резерв пространства. Для SSD выясняют, поддерживает ли среда TRIM и не накопилась ли очередь discard. Команду fstrim -av запускают в согласованное окно после проверки политики конкретной системы.

У контроллера проверьте write cache, состояние батареи или supercapacitor, режим write-back/write-through, ошибки PCIe и фоновые задачи. Сначала устраняют аппаратные и аварийные признаки. После этого производительный тест дает более надежный результат.

Шаг 4. Подтвердите гипотезу тестом fio без риска для данных

fio моделирует профиль I/O. Он не выдает одну универсальную скорость диска. Параметры теста должны соответствовать реальному сценарию: block size, read/write, random/sequential, direct I/O, numjobs, iodepth, runtime и размер рабочего набора.

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

Пример безопасного для данных сценария с чтением тестового файла:

fio --name=randread --filename=/var/tmp/fio-testfile --size=4G --rw=randread --bs=4k --direct=1 --ioengine=libaio --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting

Команда моделирует случайное чтение блоками 4 KiB с четырьмя заданиями и глубиной очереди 32. Эти параметры подходят только как пример. Для базы данных, виртуальных машин, backup и файлового сервера нужно собрать отдельные профили.

Фиксируйте полный вывод fio, версию утилиты, ядро, тип устройства, файловую систему, свободное место, температуру и состояние RAID. Повторяйте тест с одинаковыми параметрами после изменения. Сопоставляйте IOPS и latency из fio с телеметрией реального сервиса.

Типичные ошибки, из-за которых падает производительность сервера

RAID 5 или RAID 6 не становятся медленными во всех сценариях. Их ограничения проявляются при конкретном сочетании мелких записей, четности, глубины очереди и состояния массива. Вывод делают по измерениям, а не по названию уровня RAID.

Резервное копирование, журналирование и write cache нельзя менять только ради одной цифры. Перед изменением зафиксируйте модель отказов, требования к целостности, состояние защиты питания и способ восстановления.

План улучшения производительности: от измерений к изменениям

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

Что измерить до и после изменения конфигурации

• время ответа сервиса и долю ошибок;
• latency чтения и записи, включая p95 или p99;
• IOPS, throughput и размер блока;
• queue depth и utilization устройства;
• iowait, swap и загрузку CPU;
• состояние RAID, rebuild/resilver и ошибки дисков;
• свободное место, inode, заполнение thin pool и состояние TRIM;
• сетевую задержку и пропускную способность для удаленного хранилища.

Меняйте одну существенную переменную за раз: уровень RAID, размещение журнала, параметры кеша, размер блока, схему пула или тип носителя. Для каждой операции запишите исходные настройки, ожидаемый эффект, окно работ и план возврата.

Если отдельный тестовый сервер нужен быстро, конфигурацию можно проверить на изолированном облачном экземпляре Timeweb Cloud. Такой стенд не заменяет тестирование на целевом контроллере и дисках, но помогает проверить команды, мониторинг и поведение приложения без риска для рабочей среды.

Когда проблема не в хранилище

Медленный сервис может ждать блокировку в базе данных, выполнять неэффективный запрос, упираться в CPU, использовать swap или достигать лимита памяти контейнера. Причиной бывают перегруженный гипервизор, сетевой линк, DNS, внешний API или ограничение самого приложения.

Проверяйте альтернативные гипотезы по времени. Если latency диска остается стабильной, а время SQL-запроса растет, ищите блокировки и план выполнения. Если диски свободны, но ВМ теряет производительность, проверяйте steal time, datastore и соседние виртуальные машины. Если локальные показатели нормальны, а запрос к NAS медленный, измеряйте сеть и сервер хранения.

Рабочий порядок выглядит так: определить SLA и симптом, снять baseline, подтвердить узкое место, выбрать изменение с минимальным риском, проверить его на репрезентативной нагрузке, задокументировать результат и добавить нужные метрики в постоянный мониторинг. Такой процесс сокращает число случайных настроек и показывает, какой слой действительно ограничивает сервер.