Кратко и по делу — что собирать, в чём разница между wall‑clock и CPU‑профилем, как интерпретировать результаты и принимать решения.
Что собирать (ключевые метрики)
- Время: latency (P50/P95/P99), среднее, tail.
- Пропускная способность: RPS/ops/sec, throughput.
- CPU: загрузка (user/system), CPU‑время по потокам/процессам.
- Время ожидания: I/O wait, sleep, syscalls.
- Память: текущий RSS/heap, аллокации/sec, peak, rate of allocations, размера объектов.
- GC: паузы, частота, пропускная потеря из‑за GC.
- Синхронизация: время ожидания мьютексов/локов, contention, контекстные переключения.
- Кэш/микроархитектурные счётчики: L1/L2/L3 misses, TLB, branch mispredictions (по необходимости).
- Системные метрики: дисковая и сетевая задержка/полоса, I/O queue, CPU stealing (виртуализация).
- Количество вызовов функций/маршрутов; распределение времени по стеку вызовов (inclusive/exclusive).
Методы профилирования
- Сэмплинг (sampling): низкий overhead, хорош в production, даёт статистику по частоте попаданий в стек. Инструменты: perf, async-profiler, pprof (sampling), eBPF.
- Инструментация/трейсинг (instrumentation/tracing): точные времена и counts, высокий overhead, полезно для функций малого времени и детальных трасс. Инструменты: gprof (instrumenting), DTrace, SystemTap, OpenTelemetry traces.
- Трассы событий (distributed tracing): latency по запросам, span‑time, useful для микросервисов.
- Специализированные: cachegrind (кеши), massif (память), VTune (HW counters), Instruments, Windows ETW.
Wall‑clock vs CPU‑профиль — в чём разница
- Wall‑clock (реальное время): измеряет реальное прошедшее время в стеке/функции, включает время ожидания I/O, sleep, блокировки, планировщик. Полезен для latency и user‑facing задержек.
- CPU‑time (user+system): суммарное процессорное время, исключает время, когда поток простаивал; полезен когда нужно оптимизировать вычисления/алгоритмы.
- Важное соотношение: суммарное CPU‑время по всем потокам может превышать wall‑clock. Пример идеальной параллельности: $T_{cpu\_total}=N\cdot T_{wall}$, где $N$ — число полностью загруженных потоков, $T_{wall}$ — wall‑clock.
- Когда использовать: если проблема — блокировки/IO/GC — смотрите wall‑clock и ожидания; если код чисто CPU‑bound — смотрите CPU‑профиль.
Как интерпретировать результаты
- Inclusive vs exclusive time: inclusive — время функции + вызовов; exclusive — только собственная работа. Hotspot с большим inclusive означает, что оптимизация этой ветви может ускорить всю систему. Если exclusive велико — оптимизируйте саму функцию; если small exclusive but large inclusive — оптимизируйте дети/алгоритмы.
- Частота вызовов vs время вызова: функция, быстро выполняющаяся но вызываемая миллионы раз, может давать большой вклад; см. total_time = calls × time_per_call. (Формально — анализируйте оба показателя.)
- Блокировки/контеншн: если профайлер показывает много времени в wait/park/mutex, оптимизируйте синхронизацию, уменьшите критические секции, примените lock‑free или sharding.
- Аллокации и GC: высокий rate аллокаций ведёт к частым GC — уменьшите аллокации, используйте пулы объектов, рециклирование, уменьшите жизненный цикл объектов.
- I/O/системные вызовы: если большая часть wall‑clock уходит в read/write, сетевые ожидания — менять асинхронность, батчинг, кэширование.
- HW counters: много cache misses/branch mispredictions → думайте о расположении данных, выравнивании, предсказуемых ветвлениях, уменьшении working set.
Принятие решений об оптимизациях — практическая процедура
1. Базлайн: замерить текущие метрики на representative workload (latency P95/P99, throughput, CPU, memory).
2. Снять профили: sampling CPU и wall‑clock, аллокации, блокировки, трассировки по медленным запросам.
3. Выявить реальные «горячие точки»: сортировать по inclusive time, allocation rate, lock wait. Проверить reproducibility.
4. Гипотезы: для каждой горячей точки сформулировать причину (CPU, IO, GC, contention) и ожидаемый эффект оптимизации.
5. Оценка выгоды: использовать правило приоритетов — большой потребляющий ресурс + низкая сложность изменений = первоочередной. Ориентируйтесь на влияние на целевые метрики (P95, throughput).
6. Минимизировать риск: сначала простые/алгоритмические улучшения (низкий риск, большой эффект), затем микрооптимизации.
7. Измерять после каждой правки на том же workload. Оценивать статистическую значимость (несколько прогонов).
8. Рефакторинг/профит‑контроль: регресс‑тесты, покрытие, поддерживаемость.
9. Отказаться, если сложность/поддержка не оправдывает выигрыш.
Практические подсказки и анти‑паттерны
- Не оптимизируйте «по профайлеру» без проверки влияния на конечную метрику (latency/throughput).
- Sampling в production — предпочтительно; instrumentation часто искажает поведение (Heisenberg effect).
- Для параллельных программ всегда смотреть и CPU и wall‑clock; большая разница → параллельность/контеншн/IO.
- Flamegraphs отлично показывают стек и доли времени — сначала смотрите их.
- Для микрооптимизаций сначала убедитесь, что улучшаемый участок действительно лимитирует систему (Amdahl): максимальное ускорение ограничено долей времени, которую занимает оптимизируемая часть. Формула Amdahl: $S_{max}=\frac{1}{(1-p)+\frac{p}{N}}$, где $p$ — параллельная доля работы, $N$ — число процессов/потоков.
- Всегда иметь статистику по 95/99‑му перцентилю для latency — среднее малоинформативно для tail.
Инструменты (кратко)
- Linux: perf, eBPF/BCC, async-profiler, perf + Brendan Gregg flamegraphs, pprof.
- Java: async-profiler, JFR, VisualVM, YourKit.
- macOS: Instruments.
- Windows: ETW, Intel VTune.
- Memory: massif, valgrind, jemalloc/hoard профайлеры.
- Распределённые: OpenTelemetry, Jaeger, Zipkin.
Короткий чеклист действий при обнаружении «горячей точки»
- Проверить inclusive/exclusive times.
- Определить природу (CPU/IO/GC/lock).
- Если CPU: профилировать микроархитектурно (cache misses), рассмотреть алгоритм/векторизацию.
- Если IO: батчить/кэшировать/асинхронить.
- Если GC/аллоки: уменьшить аллокации, пулы.
- Если lock contention: уменьшить область критической секции, sharding, lock‑free.
- Всегда повторно измерить и оценить влияние на целевые метрики.
Если нужно, могу прислать компактный чеклист команд/инструментов для конкретного стека (Go/Java/C++/Python).