Jamf Blog
May 20, 2021 by Dan Griggs

macOS Performance Monitoring: Collection

Performance monitoring can be tricky, but incredibly useful for IT. By obtaining real-time metrics and endpoint health data, this position allows for decisions to be made timely, based on the latest and most accurate information available.

Performance monitoring can be tricky. Does constant, but lower CPU usage slow down a Mac more than intermittent, high CPU usage? Does either of those affect the battery life more than the “feel” or speed of macOS?

How can you even track CPU usage over time without starring at the Activity Monitor or Console apps all day?

Luckily, Apple has provided a handy tool called powermetrics to help obtain baseline statistics about just how much a process or group of processes are affecting the performance of your Mac.

This command collects a lot of information about each process running on your Mac. But the most important metric in this instance will be the “energy impact” score macOS assigns to each process.

What does the energy impact score mean and how is it calculated?

Per Apple’s Activity Monitor User Guide, energy impact is defined as:

Energy Impact: A relative measure of the current energy consumption of the app. Lower numbers are better.

The additional research I have done determined that energy impact is calculated on CPU %, CPU power draw, GPU usage, whether or not an app has any power assertions (pmset -g assertions) to keep the computer or screen active, memory usage and network usage.

True to its name, energy impact seems to be an accurate measure of the impact an app or process has on the computer in both the “feel” and battery usage rates.

How do I collect energy impact information via the command line?

Below is a sample command that will collect statistics for all processes running on your machine every 15 seconds and write the output to a file in the /tmp/ directory.

While we have since moved to more advanced ways to collect energy impact and performance telemetry for cmdReporter’s internal testing, I have run the above command as a LaunchDaemon on my own machine for months at a time without noticing any additional overhead.

Notes for Analyzing Data

  1. If the application you are testing uses a kernel extension be sure to chart kernel_task with that KEXT loaded and without that KEXT loaded.
  2. Use some analysis tool like Splunk, Kibana, or event Excel instead of trying to read the logs manually.
  3. Create a repeatable testing plan so you can change variables and maintain data integrity. A simple example would be: “reboot, immediately run target application, perform X task in target application, stop log collection”
  4. Compare native processes like WindowServer, Safari, and Mail to the target application. This will give you relative performance statistics to help determine the qualitative “feel” and “slowness” an application may be causing.

Powermetrics as a LaunchDaemon

Here is the LaunchDaemon plist that I have been using to collect this information in the background on my test machines.

Splunk regex for parsing powermetrics logs

This regex sample code can be ported to other log analysis tools - so long as they conform to the PCRE regex standard - but for the purposes of this article has only been tested on Splunk. Once all the data is broken out into fields, you can easily chart CPU and energy impact further broken down by individual processes.

Gain deeper insight into Mac while simultaneously securing them with Jamf Protect.

Browse Blog
by Category:
Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.