{"id":602720,"date":"2023-11-20T03:49:09","date_gmt":"2023-11-20T11:49:09","guid":{"rendered":"https:\/\/dreness.com\/blog\/?p=602720"},"modified":"2024-06-07T11:25:19","modified_gmt":"2024-06-07T18:25:19","slug":"a-better-activity-metric","status":"publish","type":"post","link":"https:\/\/dreness.com\/blog\/archives\/602720","title":{"rendered":"A Better Activity Metric"},"content":{"rendered":"\n

Measuring system-wide activity on a computer usually begins by measuring the aggregate utilization of key hardware components like CPU, storage, and network. These kinds of metrics generally come in two different forms: counters<\/em> and snapshots<\/em>. Understanding the difference is important, because they are not always equally useful.<\/p>\n\n\n\n

A counter keeps track of the total number of ‘units’ processed by the resource, like octets across a network device or blocks read or written on a storage device. (I am specifically avoiding the word ‘work’, because that’s a whole can of worms.) Counters usually start at zero (boot time) and increment forever until they roll over. Assuming a counter’s value is maintained by the sole arbiter of the hardware resource (i.e. the kernel), you can be confident that all the activity of that resource is represented in the counter’s value.<\/p>\n\n\n\n

A snapshot, on the other hand, is basically a way to answer a question like “how much is happening right now” – the important part being “right now”. <\/em>Computers are very fast, so any kind of instantaneous measurement often describes a very small time quantum – which is a very different scope compared to a counter’s reference point (“since boot”). Any sort of rate is a snapshot.<\/p>\n\n\n\n

Let’s proceed to the thrust of this post with an automobile analogy: using CPU utilization to measure overall CPU activity is like trying to infer how far a car has traveled by looking at the speedometer instead of the odometer. To demonstrate, open Activity Monitor (or top<\/code>, htop<\/code>, etc), wait a few seconds to get a ‘baseline’, then run the following small shell script:<\/p>\n\n\n\n

while true ; do \/bin\/echo zoop > \/dev\/null ; done<\/pre>\n\n\n\n
While that script is running, you should see an uptick in activity, but you may never see echo<\/code> in the process list. That’s because the amount of time required by echo<\/code> to zoop to \/dev\/null<\/code> is small compared to the amount of time it takes to start any new process (on Darwin-based systems like macOS, iOS, etc). For that reason, any instantaneous snapshot of active processes is statistically unlikely to include very short-lived processes – even if there are thousands of such processes being spawned every second. You can see where some<\/em> of that ‘startup time’ is going in the form of work done by long-lived processes like kernel_task<\/code> or dznd<\/code>.<\/p>\n\n\n\n
As it happens, macOS does provide a way to poll usage counters for (recently) deceased processes. The CLI tool powermetrics<\/code> can fetch it for you. Let’s ask for the tasks<\/code> category of data and pull just the cputime_ms_per_s<\/code> value from the all_tasks<\/code> dictionary. Something in this data isn’t json-compatible so no svelte jq one-liners – let’s use Python.<\/p>\n\n\n\n
#!python -u\n\nimport subprocess\nimport plistlib\nimport sys\n\n\"\"\"\nPrint selected power metrics from \/usr\/bin\/powermetrics at intervals, suitable for graphing.\n\"\"\"\n\ninterval = sys.argv[1] if len(sys.argv) > 1 else 1000\ncmd = f\"sudo powermetrics -i {interval} -s tasks --format plist\"\n\n# Execute the long-running command, which produces one plist to stdout every\n# interval, spread across multiple lines.\n# For each line of output from `powermetrics`:\n#   - accumulate lines into a bytearray\n#   When \"<\/plist>\" is seen:\n#    - parse the accumulated bytearray into a plist\n#    - print the metric of interest\n#    - clear the bytearray\npl = bytearray()\n# using shell mode here because we need sudo for powermetrics\nfor line in subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout:\n    pl.extend(line)\n    # look for the plist close tag\n    if \"<\/plist>\" in str(line):\n        # powermetrics adds a null byte at the start of each plist after the\n        # first, which breaks the plist parser.  Remove it.\n        if pl[0] == 0:\n            pl = pl[1:]\n        d = plistlib.loads(pl[0:])\n        print(d.get('all_tasks').get('cputime_ms_per_s'))\n        pl = bytearray()<\/pre>\n\n\n\n
Make sure you have sudo<\/code> rigged up to work without a password, or if you don’t, just run sudo whoami<\/code> no more than 5 minutes before running the above in the same terminal. Instead of just reading lines of numbers, let’s pipe to ttyplot<\/code>. Here’s a picture of a ttyplot<\/code> showing what happens when I run the echo<\/code> loop from earlier:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
The big chunk there is when I was running the loop, but the first little chunk was ‘something else’. If this feels unsatisfying, you’re thinking correctly :) The difference between the low point and the high point in this graph feels around the same as the difference you can see in Activity Monitor or htop<\/code> when running the echo<\/code> loop. If your intuition suggests there’s more going on that we’re not yet seeing, that’s also correct! <\/p>\n\n\n\n
Let’s stop beating around the bush: by far the best metric for measuring overall system activity level is power consumed<\/em>. As the name suggests, powermetrics has that for us also. This time let’s ask for the cpu_power<\/code> category, and fetch the value at processor.combined_power<\/code>.<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
In the above graph, I ran the shell loop for two bursts that are clearly visible and substantially above the noise floor.<\/p>\n\n\n\n
Here’s a gist of the python script<\/a>.<\/p>\n\n\n\n
As a bonus, here’s a little program that prints out the number of new processes created every interval (without burning a PID in the process… heyo), which I will call pidpersec.c<\/a>, as a nod to the script it’s replacing: pidpersec.d. Running the shell loop with that program’s output piped to ttyplot looks like this:<\/p>\n\n\n\n
\"\"<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"
Using CPU utilization to measure overall CPU activity is like trying to infer how far a car has traveled by looking at the speedometer instead of the odometer. Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[36,6,13],"tags":[],"class_list":["post-602720","post","type-post","status-publish","format-standard","hentry","category-quiesce","category-scripts","category-the-more-you-know"],"_links":{"self":[{"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/posts\/602720","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/comments?post=602720"}],"version-history":[{"count":5,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/posts\/602720\/revisions"}],"predecessor-version":[{"id":602729,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/posts\/602720\/revisions\/602729"}],"wp:attachment":[{"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/media?parent=602720"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/categories?post=602720"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dreness.com\/blog\/wp-json\/wp\/v2\/tags?post=602720"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}