Hardware counters, профили холодного старта и безопасность профилей

JSON-парсер занимает 30% CPU сервиса на флейм-графе. Команда переходит на более быстрый парсер — экономит 10%. Инженер запускает perf с счётчиками cache-miss: IPC = 0.4, процент cache-miss = 12%. Парсер memory-stalled, а не compute-bound. Реструктуризация layout’а входных данных экономит 50%.

Hardware performance counters (HPC)

Флейм-граф называет функцию. Он не говорит, что именно CPU делает внутри неё. Hardware performance counters открывают цену на уровне кремния.

Ключевые счётчики:

• cycles — потреблённые сырые такты CPU
• instructions — завершённые инструкции. IPC = instructions / cycles.
• cache-misses — количество промахов кэша L3 (каждый промах = ~100 нс задержки)
• branch-misses — количество неверных предсказаний ветвлений (каждое = ~15 тактов штрафа)
• page-faults — количество page fault’ов OS
• dTLB-load-misses — количество промахов data TLB (Translation Lookaside Buffer)

Интерпретация IPC:

• IPC < 1.0 — memory-bound. CPU заторможен в ожидании данных из кэша или RAM. Алгоритмические переписывания не помогут; рычаги — исправления layout’а данных (struct-of-arrays, cache-friendly обход, prefetching).
• IPC 1.0–2.5 — смешанный. Исследуй конкретные промахи.
• IPC > 2.5 — compute-bound. Алгоритм выполняет полезную работу; рычаги — векторизация или более умная математика.

Использование на Linux:

# Профилировать cycles, instructions, cache-misses, branch-misses вместе
perf record -e cycles,instructions,cache-references,cache-misses,branch-misses \
    -g ./myapp workload
perf report  # показывает разбивку счётчиков по функциям

Профили холодного старта vs установившегося режима

Профиль первых 60 секунд после запуска процесса абсолютно не похож на профиль после часа трафика.

Фаза холодного старта:

• JIT-рантаймы компилируют горячие пути кода (HotSpot, V8, .NET CLR) — компиляция проявляется как CPU-цена.
• Кэши холодные: пулы соединений устанавливаются, лениво загружаемые модули загружаются, L3-кэш пуст.
• Оптимизации: AOT-компиляция (GraalVM native-image, .NET ReadyToRun), нетерпеливая загрузка модулей, предварительное прогревание соединений.

Фаза установившегося режима:

• JIT полностью оптимизирован; кэши тёплые.
• Оптимизации: алгоритмические фиксы, изменения layout’а данных, снижение конкуренции за локи.

Путаница между ними — частая ошибка: команда оптимизирует hotspot установившегося режима и удивляется, что события scale-out автоскейлера всё ещё деградируют tail latency — путь холодного старта никогда не измерялся.

Production-grade профилирование захватывает оба: профиль холодного старта (первые 30-60 секунд после запуска) и профиль установившегося режима (после прогрева под репрезентативной нагрузкой). Поддерживай отдельные дашборды для обеих фаз.

Безопасность профилей

Профиль содержит имена функций — нередко включающие приватные внутренние API, недокументированные эндпоинты и пути сборки, раскрывающие среду деплоя. Memory-профили при плохой конфигурации могут включать аргументы аллокации (строковые содержимое, JSON-тела).

Реальные инциденты: pprof-эндпоинты случайно открыты через /debug/pprof на публичном порту, раскрывая пути исходников и имена feature-флагов. Профайлеры аллокаций, утекающие session-токены из строк запросов.

Production-дисциплина:

• pprof-эндпоинты привязаны только к localhost или аутентифицированному admin-only пути.
• eBPF-профайлеры запускаются с минимальными capabilities (CAP_PERFMON на Linux 5.8+, не CAP_SYS_ADMIN).
• Бэкенды непрерывного профилирования защищены RBAC по командам.
• Экспорт профилей требует согласования с менеджером.

Профили — операционные данные с последствиями для безопасности, а не «только для ops артефакты, которыми безопасно делиться».