Почему бенчмаркинг на Linux — это не про числа, а про вопросы
Сравнивать сервера, видеокарты и ноутбуки только по одной цифре бессмысленно. Производительность — это рассказ о сценариях: какой latency важен, какие данные и в каком режиме обрабатываются, как влияет энергопотребление и стабильность в долгих нагрузках. На Linux этот рассказ часто становится сложнее: драйверы, ядро, компилятор, настройки энергопотребления и виртуализация — всё влияет.
Ключевые принципы зрелого бенчмаркинга
- Репродуцируемость: как минимум — фиксировать версии ПО, конфиги, температуру и частоты CPU/GPU.
- Контекст: указывать рабочие сценарии — игровой тест, рендер, ML‑инференс, базовая нагрузка I/O.
- Многофакторность: измерять не только среднее — смотреть медиану, перцентили (p95/p99), variance и деградации во времени.
- Автоматизация: CI для перформанс‑регрессий, чтобы заметить падения раньше, чем о них сообщат пользователи.
Инструменты, которые действительно помогают
Список инструментов огромен, но важно понимать назначение каждого уровня:
- Пакетные фреймворки — Phoronix Test Suite, OpenBenchmarking.org. Хороши для стандартизации тестов и отчетности.
- Низкоуровневые счётчики — perf, oprofile, perf stat: дают счётчики CPU, кэш‑промахи, ветвления.
- Трассировка — ftrace, BPF/eBPF, tracepoints: помогают найти узкие места в ядре и драйверах.
- Графика — apitrace, glxinfo, vkcube, профайлеры GPU (Intel VTune, AMD Radeon‑tools, NVIDIA Nsight).
- ML‑бенчмарки — MLPerf (Inference/Training): стандартизованные метрики для нейронных сетей.
- Энергопотребление — RAPL, IPMI, внешние ваттметры: важны при оценке производительности на ватт.
Phoronix Test Suite заслуженно популярен: он покрывает множество рабочих нагрузок, умеет автоматизировать запуск, собирать лог и интегрироваться с OpenBenchmarking. Для тех, кто использует виртуальные среды и Proxmox, есть дистрибутивы, оптимизированные под соответствующие сценарии (например, доступные варианты на базе Proxmox упоминаются в отечественных решениях виртуализации).
Метрики: не только FPS и GHz
Типичный набор метрик для разных задач:
- Игры и визуализация: FPS, frame time percentiles (p50/p90/p99), стабильность кадра.
- Серверы и базы данных: latency распределение, tail latency (p99.9), throughput, QPS.
- ML‑инференс: latency per sample, throughput (inferences/sec), accuracy, memory footprint.
- Общие: потребление энергии, температура, частоты CPU/GPU, пропускная способность диска/сети.
Особое внимание — на перцентили латентности: средний FPS может выглядеть хорошо, но хвостовые задержки (p99) создавать плохой UX — баги, подвисания, фризы. Для серверов p99.9 или даже p99.99 определяют реальный отклик под нагрузкой.
Частые ошибки и как их избежать
- Играть в «улучшение по синтетике»: оптимизация под тесты даёт выигрыш только в бенчмарках, но не для реальных задач. Решение — использовать смешанные рабочие нагрузки и реальные сценарии.
- Игнорирование температур и троттлинга: ноутбуки и встраиваемые устройства снижают частоты под нагрузкой. Нужно мониторить температуру и поведение в долгих тестах.
- Неправильный контроль окружения: фоновые сервисы, некорректные governor'ы, автообновления и сетевой трафик искажают результаты. Изолировать тестовый стенд.
- Малая выборка: один запуск — это случайность. Делать серию прогонов и статистический анализ.
Драйверы и ядро: почему десятки строк changelog'а могут убить производительность
Драйвер — это мост между железом и ОС. Обновление Mesa, изменение поведения Vulkan или патч в драйвере GPU нередко влияют на FPS и стабильность. Аналогично, патчи в scheduler или power management могут изменить поведение CPU (частотная политика, энергосбережение) и, следовательно, результаты тестов.
Практический сценарий: после апдейта Mesa на Linux‑машине наблюдается падение p99 времени кадра в игре. Типичный цикл расследования:
- Сравнить версию драйвера и ядра.
- Запустить трассировку (ftrace, eBPF) для поиска задержек в пользовательском/ядровом пространстве.
- Проверить изменения в графической подсистеме (компиляция шейдеров, API‑эмуляции).
- При необходимости — откатить версию или создать репорт с минимальным воспроизводимым кейсом.
Виртуализация и контейнеры: где теряется производительность
Виртуализация добавляет оверхед, но современный стек делает его приемлемым при правильной настройке. Важно понимать источники потерь:
- CPU: контекст‑свичи, подкачка, тайминги вперемешку с host‑scheduler.
- Память: hugepages помогают для больших рабочих нагрузок (БД, VMs), NUMA‑привязка критична для многосокетных машин.
- Сеть и диски: VirtIO, SR‑IOV, PCIe‑pass‑through уменьшают Latency и увеличивают throughput.
Примеры практических настроек: закрепление vCPU на pCPU (CPU pinning), отключение таймеров, выделение hugepages и настройка NUMA affinity. Для CI и облачных сценариев это превращается в тонкую настройку: для веб‑сервисов часто важнее хвостовая латентность, для HPC — throughput.
Если инфраструктура опирается на Proxmox/виртуализационные решения, их параметры (disk cache, I/O scheduler, ballooning) нужно контролировать и документировать при тестировании. (Существует также отечественный дистрибутив, ориентированный на виртуализацию и Proxmox‑базу.)
ML и новые требования к бенчмаркингу
ML привносит свои правила: вместо FPS часто смотрят throughput при заданном SLA по latency. Тут важны не только «сырые» FLOPs, но и память, пропускная способность шины, эффективность драйверов (cuDNN, oneDNN), и поддержка низкой точности (INT8, BF16).
Стандартизированные подходы вроде MLPerf помогают, но даже они не покрывают всех нюансов: дата‑пойнты, пре‑ и пост‑обработка, batching, динамическая квантизация влияют на результат. Поэтому при сравнении важно фиксировать pipeline целиком.
Как построить CI для контроля перформанса
- Автоматизировать тесты в контейнерах/VM, сохранять артефакты и логи.
- Использовать контроль версий для конфигураций и сравнивать результаты по коммитам.
- Настроить пороги оповещений (регрессия > X% по p95).
- Интегрировать трассировку для возможности быстрого роутинга инцидентов к ответственным командам.
Phoromatic и OpenBenchmarking отлично подходят для таких задач: позволяют централизованно собирать результаты, визуализировать тренды и уведомлять о регрессах.
Статистика и анализ: как не обмануть себя
Основные рекомендации:
- Делать минимум 5–10 прогонов при изменчивых нагрузках.
- Не полагаться на среднее, смотреть медиану и перцентили.
- Фильтровать выбросы, но документировать, что было отброшено и почему.
- Проводить t‑тест или непараметрические тесты для подтверждения значимости изменений.
Тренды и прогнозы
- Рост важности энергоэффективности: метрики performance‑per‑watt станут первыми в закупочных спецификациях для ЦОДов и edge.
- ML‑переход: новые аппаратные ускорители (TPU‑стиль, IPU, NPU) потребуют новых бенчмарков и инструментов для анализа.
- RISC‑V и гетерогенные SoC: появление новых ISA приведёт к всплеску инструментов и необходимости портирования бенчмарков.
- Виртуализация и серверлес‑модели: тонкая настройка hypervisor и контейнерных слоёв останется ключом к производительности в облаке.
Практические кейсы
1. Падение FPS после обновления драйвера
Сценарий: обновили Mesa, упал p99. Проверки: сравнение версий, трассировка рендер‑путей, отключение компиляции шейдеров в runtime. Решение: репорт в багтрекер с минимальным тестом и откат до стабильной версии, параллельно — тест с патчами и бенчмарк в Phoronix для подтверждения регрессии.
2. Нестабильная латентность в базе данных в VM
Сценарий: p99 вырос после миграции на VM. Диагностика: NUMA‑ошибка, ballooning, плохие disk cache настройки. Правки: выставить strict NUMA pinning, выделить hugepages, использовать VirtIO‑SCSI с правильным кэшем и disable‑ить ballooning.
3. ML‑инференс: разница между dev и prod
Сценарий: в лаборатории модель показывает 1000 inf/s, в проде — 300. Причины: разный batch size, различная библиотека драйвера (cuDNN vs custom), недостаток GPU памяти, разная верcия CUDA. Решение — синхронизировать стек, зафиксировать pipeline и проводить тесты с теми же данными и batching.
Риски и этика — когда метрики вводят в заблуждение
Производительность может быть «подогнана» под бенчмарки: тайминги, предварительная компиляция, отключение проверок безопасности для ускорения. Это даст картинку, но обманет конечного пользователя. Этический подход — снабжать тесты полным контекстом и публиковать методики воспроизводимости.
Короткие практические рекомендации
- Документировать окружение: kernel, драйверы, BIOS/firmware, компилятор.
- Использовать реальные сценарии параллельно с синтетикой.
- Автоматизировать и версионировать конфигурации.
- Интегрировать энергомониторинг в тесты.
- Проверять tail latency, а не только throughput или средние значения.
Вывод
Бенчмаркинг — это инженерия. Это не просто запуск очередного теста, а организация процесса: воспроизводимость, мониторинг, трассировка и анализ. Инструменты вроде Phoronix Test Suite или специализированных ML‑бенчмарков упрощают жизнь, но ответственность за корректность выводов остаётся за инженером. Будущее за комплексными метриками: энергия, стабильность, латентность и реальная нагрузка станут важнее абстрактных гигафлопсов.
Вопросы к читателям
Какая самая большая проблема в ваших бенчмарках: шум измерений, несоответствие тестов реальным нагрузкам или трудности с репродуктивностью? Какие инструменты и практики помогли именно вам обнаружить и закрепить перформанс‑регрессию?
Комментарии