Мониторинг производительности
Тема дорожной карты · Linux & Unix Fundamentals
Мониторинг производительности в Linux — это процесс сужения области поиска проблемных областей (CPU, память, I/O, сеть) с помощью различных слоёв инструментов. Эта практика имеет важное значение для поддержания стабильной и эффективной работы системы. Она позволяет оперативно выявлять и устранять проблемы, что в конечном итоге приводит к повышению производительности и устойчивости системы.
Как это работает
Мониторинг производительности использует методологию USE (Utilisation, Saturation, Errors) и четыре золотых сигнала (latency, traffic, errors, saturation). Инструменты для мониторинга включают top/htop/atop (для отслеживания процессов), vmstat 1 (для анализа использования ЦПУ и памяти), iostat -x 1 (для мониторинга дисковых операций), mpstat -P ALL 1 (для анализа использования ЦПУ по каждому процессору), pidstat 1 (для мониторинга ввода-вывода и использования ЦПУ для каждого процесса), free -h (для анализа использования памяти), dstat (для мониторинга нескольких метрик одновременно), perf (для профилирования ядра), bpftrace/bcc-tools (для трассировки событий с использованием eBPF).
Когда применять
Сначала создайте базовый профиль системы, чтобы иметь возможность сравнивать его с состоянием системы во время инцидента. После этого можно переходить к оптимизации. Догадки обычно неверны, поэтому лучше всего начать с базовых инструментов, таких как htop и iostat -x 1, чтобы заметить очевидную CPU/IO-сатурацию. Затем можно углубиться с использованием более специализированных инструментов, таких как perf top или eBPF. Для HTTP-сервисов важно смотреть на upstream-метрики (latency p95/p99, error rate) — иногда боттлнеком может быть downstream-БД, а не сама система Linux.
Типичные ошибки
Типичные ошибки при мониторинге производительности включают следующие:
- Сбор данных только по среднему load (
uptime) вместо более точных процентилей. - Неправильное понимание того, что высокая загрузка ЦПУ (
topD-state) может быть связана с uninterruptible-IO wait, а не с активной работой процессора. - Изменение настроек ядра (
sysctl) на основе информации из блог-постов без глубокого понимания последствий таких изменений. - Оставление активного
tracing/ftraceв production-среде, что может привести к нежелательным последствиям для производительности.