Производительность и энергия: powermetrics, диагностика

[Artem_MacAdmin]

Ноутбук греется, кулер воет (если он вообще есть), батарея тает на глазах, бирюзовый Spinning Wheel крутится, а Мониторинг системы показывает абстрактные проценты, которые ничего не объясняют. Знакомо? Activity Monitor - это градусник, он говорит "температура есть", но не говорит "почему". Чтобы разобраться, что реально жрёт CPU, GPU, нейронный движок и батарею, нужны инструменты глубокой диагностики из недр macOS. Они есть прямо в системе, бесплатно, без Xcode (почти все). Этот урок - про то, как снять с Mac рентген: powermetrics для энергии и частот, vm_stat для памяти, fs_usage для файловых операций, spindump и sample для зависаний и утечек. После него абстрактные тормоза превращаются в конкретный процесс с конкретным стеком вызовов.

Важная вводная по железу 2026 года. На Apple Silicon (M-серия) у тебя не классический x86 с одним типом ядер. Там big.LITTLE: производительные ядра (P-cores, кластер обычно зовётся ANE0/P-cluster) и энергоэффективные (E-cores). Плюс GPU и ANE - Apple Neural Engine, отдельный блок для ML. powermetrics видит все три. На macOS 26 Tahoe (последний релиз с поддержкой Intel, дальше только Apple Silicon) часть классических инструментов вроде dtrace зажата SIP, а часть samc-сэмплеров просто исчезла. Учитываем это сразу.

powermetrics - главный инструмент для mac производительности

powermetrics - это утилита Apple, которая читает аппаратные счётчики энергии, частоты P-state, загрузку по кластерам, тепловое давление и состояние сна. Требует root, потому что лезет к защищённым счётчикам ядра. Без sudo получишь отказ.

Базовый запуск - один срез за 5 секунд и выход:

Код: Выделить всё

sudo powermetrics -n 1 -i 5000

Здесь -n 1 - сделать ровно один замер (sample), -i 5000 - интервал окна в миллисекундах. Без -n команда будет лить бесконечно, пока не нажмёшь Ctrl-C. По умолчанию интервал 5000 мс.

Самое полезное - выбирать конкретные сэмплеры через --samplers (короткий ключ -s). Посмотрим энергию CPU и GPU плюс сводку по процессам:

Код: Выделить всё

sudo powermetrics --samplers cpu_power,gpu_power -i 1000 -n 1

Кусок вывода на M-серии и его разбор:

Код: Выделить всё

**** Processor usage ****

E-Cluster Power: 41 mW
E-Cluster HW active frequency: 1024 MHz
E-Cluster HW active residency:  18.43%
P-Cluster Power: 1872 mW
P-Cluster HW active frequency: 3204 MHz
P-Cluster HW active residency:  64.10%

CPU 4 frequency: 3036 MHz
CPU 4 active residency:  52.18% ...

ANE Power: 0 mW
GPU Power: 95 mW
Combined Power (CPU + GPU + ANE): 2008 mW

Что читаем. P-Cluster Power 1872 mW - производительные ядра сейчас сжирают почти 2 ватта, при том что HW active frequency 3204 MHz близко к потолку. Active residency 64% - ядра реально работали две трети окна. Если у тебя браузер в фоне и P-Cluster постоянно на 3+ ГГц - что-то крутит цикл. ANE Power 0 - нейронный движок простаивает (он включится, когда система делает распознавание лиц в Фото, диктовку, Apple Intelligence). Combined Power - суммарный ватт пакета, прямой индикатор того, сколько ты сейчас сливаешь в тепло и батарею.

Тепловое давление - отдельный сэмплер, и это ключ к троттлингу на Apple Silicon:

Код: Выделить всё

sudo powermetrics -s thermal -i 1000 -n 1

Код: Выделить всё

**** SMC sensors ****
Current pressure level: Nominal

Уровни: Nominal (всё спокойно), Fair, Serious, Critical. Когда чип нагревается, macOS поднимает thermal pressure и принудительно снижает частоты - это и есть тепловой троттлинг. На MacBook Air без вентилятора под долгой нагрузкой (экспорт видео, компиляция) ты увидишь, как pressure уезжает в Serious, а P-Cluster frequency в powermetrics падает с 3.2 ГГц до 2 ГГц. Это не поломка - это by design. Тот же сигнал thermal pressure можно ловить программно через notifyd-нотификацию, но для диагностики хватает powermetrics.

Хочешь увидеть, кто именно тратит энергию по процессам - добавь сэмплер tasks:

Код: Выделить всё

sudo powermetrics -s tasks --show-process-energy -i 2000 -n 1

Колонка "Energy Impact" - это та же метрика, что Activity Monitor показывает на вкладке Энергия. Высокий Energy Impact у процесса в фоне = подозреваемый номер один по разряду батареи. Полезные дополнительные ключи: --show-process-gpu (кто грузит GPU), --show-process-netstats (сетевая активность процессов), -o file.txt (писать в файл вместо консоли).

Грабли powermetrics. Сэмплер smc на свежих Mac убрали - не пиши его, получишь "unrecognised sampler". На Intel-машинах набор сэмплеров другой (есть smc, нет E/P-кластеров). Не путай мгновенное значение thermal (срез на конце окна) с усреднёнными по окну энергией и частотами.



Память и своп: vm_stat без иллюзий

vm_stat (через подчёркивание, не vmstat как в Linux - это BSD) показывает виртуальную память в страницах. Размер страницы на Apple Silicon - 16 КБ (на Intel был 4 КБ), и это важно для расчётов.

Код: Выделить всё

vm_stat

Код: Выделить всё

Mach Virtual Memory Statistics: (page size of 16384 bytes)
Pages free:                          45213.
Pages active:                       812904.
Pages inactive:                     798210.
Pages wired down:                   201554.
Pages occupied by compressor:       331290.
Swapins:                           1204553.
Swapouts:                          1840221.

Разбор. Pages wired down - память, которую нельзя выгрузить (ядро, драйверы). Pages occupied by compressor - сжатая память: macOS не сразу пишет в своп, сначала компрессирует страницы в RAM. Растущий compressor - это норма, система экономит. А вот большие Swapins/Swapouts - тревога: данные реально гоняются на SSD и обратно, это и есть тормоза от нехватки памяти. Умножай страницы на 16384, чтобы получить байты: 331290 * 16384 байт это примерно 5 ГБ сжатой памяти.

Для динамики гоняй с интервалом - первый аргумент это секунды:

Код: Выделить всё

vm_stat 2

Тут колонки идут дельтами между замерами, и ты видишь скорость свопинга в реальном времени. Если pageouts/swapouts тикают на каждом замере при открытом проекте - тебе не хватает RAM под эту задачу.

Что делает процесс прямо сейчас: fs_usage, sample

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

Код: Выделить всё

sudo fs_usage -w -f filesys Safari

-w - широкий вывод (не обрезать пути), -f filesys - фильтр на файловую систему (есть ещё network, pathname, exec). Можно указывать имя процесса или PID.

Код: Выделить всё

14:22:09  open      F=23  /Users/u/Library/Caches/...  0.000042   Safari
14:22:09  read      F=23  B=0x4000                     0.000018   Safari
14:22:09  stat64    /Applications/Safari.app/...        0.000009   Safari

Колонки: время, syscall, дескриптор/аргументы, длительность вызова, процесс. Если видишь, что процесс долбит stat64 по одному и тому же пути тысячу раз в секунду - вот твой пожиратель диска и CPU. Реальный сценарий: индексатор или антивирус сканирует папку в цикле, fs_usage это вскрывает за секунды.

Когда процесс не завис намертво, а просто тупит - снимай sample (это "sample mac"-инструмент профайлинга по статистике). Он сэмплирует стеки указанного процесса N секунд и строит дерево вызовов:

Код: Выделить всё

sample Safari 5 -file /tmp/safari.txt

Первый аргумент - имя или PID, второй - длительность в секундах (по умолчанию 10). sample без sudo берёт свои процессы, для чужих нужен root. В отчёте - "heavy" дерево: функции, отсортированные по числу попаданий сэмпла. Топ-функция с большим числом - это горячая точка, где процесс проводит время. Так ловят бесконечные циклы и зависания в конкретной библиотеке.

Зависшее приложение: spindump и поиск утечек

Если sample - про один процесс, то spindump - тяжёлая артиллерия для системных зависаний. Когда приложение не отвечает (beachball), macOS сама делает spindump и кладёт отчёт в /Library/Logs/DiagnosticReports/. Запустить вручную:

Код: Выделить всё

sudo spindump Final\ Cut\ Pro 10 -file /tmp/fcp.spindump

Первый аргумент - процесс (имя или PID), второй - длительность в секундах (по умолчанию 10). spindump сэмплирует пользовательские и ядерные стеки всех процессов или указанного, и показывает, кто и на каком вызове застрял. В отчёте ищи строки вроде:

Код: Выделить всё

Thread 0x... DispatchQueue 1   Thread name "main"
1000 ??? (in AppKit) ...
1000 -[NSApplication run] ...
1000 mach_msg_trap ...  (blocked)

Число слева - сколько сэмплов поток провёл в этом стеке. Если главный поток (main) застрял в синхронном вызове, ожидая семафор или сетевой ответ, - вот причина beachball. spindump поддерживает два формата стеков, heavy и timeline (ключ -timeline), и хранит бинарный слепок в конце отчёта, чтобы переотчитать с другими опциями.

Связка инструментов под задачу:

• Activity Monitor показал высокий CPU у процесса -> sample на этот процесс, смотрим горячую функцию.
• Приложение крутит beachball -> spindump, смотрим где застрял main-поток.
• Процесс молотит диск -> fs_usage -f filesys, смотрим повторяющиеся syscall.
• Батарея садится в простое -> powermetrics -s tasks --show-process-energy, ищем Energy Impact.
• Тормоза при свопе -> vm_stat 2, смотрим swapouts.

Для трассировки системных вызовов как strace в Linux есть dtruss (обёртка над DTrace):

Код: Выделить всё

sudo dtruss -p 1234

И тут важная правда про DTrace в 2026. SIP (System Integrity Protection) серьёзно урезает DTrace: он не может инструментировать системные процессы и многие защищённые бинарники. Полноценно работать dtrace и dtruss начнут только с частично отключённым SIP (csrutil enable --without dtrace), а это компромисс по безопасности, на проде так делать не стоит. Хуже того, на Apple Silicon под некоторыми версиями macOS DTrace ловит баг: после сна память, защита которой снималась под DTrace, может переинициализироваться, и трассировка вешает систему до перезагрузки. Вывод: на Apple Silicon для трассировки сначала пробуй fs_usage, sample, spindump - они работают под SIP и почти всегда дают ответ. dtruss держи как крайнее средство.

Энергия, батарея и тяжёлая артиллерия Instruments

Что грузит батарею, помимо powermetrics, показывает pmset - менеджер питания:

Код: Выделить всё

pmset -g
pmset -g assertions
pmset -g log | grep -i wake

pmset -g - текущие настройки энергосбережения. pmset -g assertions - кто держит систему бодрствующей: процесс, поставивший PreventUserIdleSystemSleep, не даёт Mac уснуть и сажает батарею (типичный виновник - незакрытая видеоконференция или загрузка). pmset -g log - журнал событий сна и пробуждений, по нему ловят "почему ноутбук не спит в сумке". Учти: pmset -g thermlog на Apple Silicon обычно пуст и отвечает "No thermal warning level has been recorded" - тепло там смотрим через powermetrics, не через pmset.

Когда нужен графический профайлер с микросекундной точностью - это Instruments из состава Xcode (instruments mac - стандартный поисковый запрос разработчиков). Это GUI поверх движка DTrace и собственных трасс. Ключевые инструменты:

• Time Profiler - сэмплирует стеки во времени, тот же принцип что sample, но с временной шкалой и фильтрами по потокам. Главный инструмент против тормозов CPU.
• Allocations - все аллокации памяти, размеры, кто и где выделил. Ловит раздувание памяти.
• Leaks - детектор настоящих утечек: объекты, на которые потеряны все ссылки. Идёт в паре с Allocations.
• Energy Log / CPU Counters - энергопрофиль, привязанный к коду, по тем же принципам что powermetrics, но с привязкой к функциям.

Запустить можно из Xcode (Product -> Profile) или из терминала: open -a Instruments. Для своего бинарника есть и консольный xctrace (xcrun xctrace record). Instruments нужен, когда CLI-инструменты показали где горячо, а ты хочешь увидеть точную строку кода и историю аллокаций.

Мини-лаба: снимаем рентген за пять минут

Сделай руками, по шагам:

• Запусти sudo powermetrics --samplers cpu_power,gpu_power -i 1000 -n 3 и найди P-Cluster Power и frequency. Открой тяжёлую вкладку в браузере, повтори - увидь, как выросла мощность и частота.
• В одном окне запусти sudo powermetrics -s thermal -i 1000, в другом запусти стресс: yes > /dev/null & (несколько раз, по числу ядер). Смотри, как pressure уходит от Nominal. Потом убей нагрузку: killall yes.
• Сделай vm_stat, запиши Swapouts. Открой пару тяжёлых приложений, повтори. Посчитай дельту в страницах и переведи в мегабайты (страница 16384 байт).
• Выбери любое работающее приложение и сними sample ИмяПриложения 5 -file /tmp/s.txt. Открой файл, найди heavy-дерево и топовую функцию.
• Запусти sudo fs_usage -w -f filesys ИмяПриложения и поработай в приложении - поймай его реальные файловые вызовы. Останови по Ctrl-C.
• Глянь pmset -g assertions - кто сейчас мешает Mac уснуть.

Контрольные вопросы

• Чем отличается мгновенное значение thermal pressure от значений энергии и частоты в выводе powermetrics, и почему это важно при диагностике троттлинга?
• Ты видишь в vm_stat большой и растущий compressor, но swapouts почти не меняются. Это проблема нехватки памяти или нет? Обоснуй.
• Приложение крутит beachball. Какой инструмент возьмёшь - sample или spindump - и что конкретно будешь искать в отчёте?
• Почему на Apple Silicon под SIP dtruss часто бесполезен, и чем его заменить для большинства задач трассировки?

Итог

Глубокая диагностика Mac - это не магия, а конкретный набор: powermetrics для энергии, частот, ANE и теплового давления (всегда sudo, выбирай сэмплеры); vm_stat для памяти и свопа (страница 16 КБ, следи за swapouts); fs_usage для файловых вызовов процесса; sample для горячих функций одного процесса; spindump для системных зависаний и застрявшего main-потока; pmset для батареи и сна; Instruments, когда нужен GUI-профайлер с привязкой к коду. dtrace и dtruss держи в уме, но помни про SIP. Эти инструменты превращают расплывчатое "тормозит и греется" в точный диагноз - процесс, стек, syscall, ватт.

[silentpanic]

Спасибо, наконец дошло чем sample от spindump отличается. Раньше тыкал spindump на всё подряд и тонул в стенах текста, а оказалось для одного процесса sample гораздо понятнее.

[golang_guru]

А правда что на M4 Air под долгой компиляцией частота сама падает? Запустил powermetrics -s thermal во время сборки проекта - реально уехало в Serious и P-Cluster просел с 3.2 до 2.1 ГГц. Думал брак, а это троттлинг штатный.