# fio: buffered и direct read измеряют разные пути

Как сравнивать buffered и direct чтение fio с историей кеша, защитой от записи и проверкой поддержки, сохраняя границы файловой системы и устройства.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/fio-buffered-direct-read/
Language: ru

## Назовите путь до сравнения результатов

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

В [справочнике fio](https://fio.readthedocs.io/en/latest/fio_doc.html) определены настройки buffered и direct I/O и ограничения платформ. Параметр direct не удаляет все уровни хранения и не превращает тест файловой системы в измерение чистой флеш-памяти. Указывайте запрошенный путь и его поддержку в конкретной среде исполнения.

## Используйте ограниченный существующий файл

Выберите известный файл с записанными содержимым и размером и разрешением на нагрузку. Явно задайте чтение и защитный режим fio read-only. Запись, trim и автоматическое создание не должны участвовать в исследовании чтения. Не подставляйте целое сырое устройство только потому, что его использовал пример для другой системы.

Записывайте установленный выпуск fio, движок, диапазон файла, размер блока, очередь и длительность. Полное задание должно сохраняться вместе с результатом. Подписи «тест SSD» недостаточно, чтобы восстановить, читался ли маленький закешированный диапазон многократно или исследовался значительно больший рабочий набор данных.

## Документируйте подготовку кеша

[Документация Linux по виртуальной памяти](https://docs.kernel.org/admin-guide/sysctl/vm.html) объясняет освобождение кешей и расходы намеренного удаления. Не делайте общесистемный сброс кеша штатным шагом занятого сервера. Он меняет соседние нагрузки и способен сделать среду менее похожей на исследуемую работу приложения.

Вместо этого определите изолированные условия теста и известную историю кеша. Повторный buffered-прогон может намеренно измерять тёплый путь. Direct-чтение при поддержке даёт другую исходную точку. Ни один режим нельзя переименовывать в холодное хранилище без сведений об оставшихся кешах файловой системы, устройства и платформы.

## Осторожно трактуйте различие

Предположим, условный тёплый buffered-прогон завершается существенно быстрее direct. Это согласуется с обслуживанием из кеша и не доказывает изменение физической скорости SSD. Если direct-задание не выполнилось, сохраняйте ошибку и условия поддержки вместо превращения отказа в бенчмарк с нулевой производительностью.

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

## Свяжите измерение с приложением

Загрузчик модели может выигрывать от тёплого page cache в обычной эксплуатации. Это допустимое условие приложения, если оно явно названо. Публикуйте раздельные результаты buffered и direct с историей подготовки и областью измерения. Полезное решение показывает, какой путь соответствует развёртыванию и какой вопрос требует другого теста, вместо выбора самого большого неподписанного числа.

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

## Связанные материалы

- [Бенчмарк GPU для инференса, которому можно доверять](/ru/journal/inference-benchmark-method/)
- [NVMe для размещения моделей: где быстрый диск меняет результат](/ru/journal/nvme-for-model-serving/)