Activity Monitor, ps and top: probing processes

After you have browsed the logs, one of the most popular tools for investigating performance issues in OS X is Activity Monitor. It should not, though, be used if you can possibly help it.

One of the most widely-applicable results from quantum physics is that whenever you try to measure a system, making those measurements also alters that system. This is particularly true of attempts to measure computer performance: any tool which can provide information about performance is inevitably going to change what it is measuring.

The greater the footprint of the tool that you use, the greater will its effects be in terms of changing the performance which you are trying to measure. Use a tool such as Activity Monitor, with its deceptively simple human interface, and it can distort performance so much that it may obscure the effects which you are looking for.


The two leading process and performance tools, both of which are invoked by the all-dancing sysdiagnose, are ps and top.

Process Status

When you run sysdiagnose, output from ps, the shell tool to monitor process status, is delivered in the file ps.txt. This lists, for each process which has a controlling terminal, basic information, arranged in order of process ID. As process IDs are assigned in the order in which the processes are started, these normally start with those owned by root and run early after startup, and end up with user processes for apps which you have most recently been running.

For each process, you are given

  • the user name, typically root or your user name
  • the user number, e.g. 0 for root, 501 for the first user, and so on
  • the process ID
  • % CPU time, % memory
  • priority, nice value
  • virtual size (Kbytes), resident set size
  • symbolic name of wait channel, the control terminal name, the symbolic process state
  • the time that the process was started
  • CPU time
  • the command used to start that process.

These allow you to identify rogue processes which are taking excessive resources such as CPU, for example.

Thread-Aware Process Status

sysdiagnose also runs a thread-aware version of ps, which examines individual threads within each process in the file ps_thread.txt. Its output is similar to that of vanilla ps, but for each process ID it gives information about individual threads within that overall process. This allows even finer-grade assessment to guide you to diagnosis.


Saved in the file top.txt is the output of a series of top snapshots taken in quick succession while running sysdiagnose. top also looks at processes, but provides more extensive information. Each snapshot starts with a summary of the period monitored, and provides basic information of the kind reported by Activity Monitor, but without as much overhead, and collected in the file top.txt.

top‘s output is sorted in descending (highest to lowest) order of process ID, and does not look inside processes at threads. For each process, it gives:

  • the command name for that process
  • CPU usage as % and execution time
  • the number of threads, and Mach ports
  • internal memory size, purgeable memory size, and compressed memory
  • the process group ID, and its parent process ID
  • the process state, such as whether it is sleeping
  • the number of boosts held, and number of times it has boosted
  • CPU time charged to the process by others, and that charged to other processes by the process
  • the user ID
  • the number of page faults, copy-on-write faults, Mach messages sent, and those received
  • the total number of BSD system calls, and Mach system calls
  • the number of context switches, and total pageins
  • the number of memory regions, resident private address space size, private address space size, total memory size, private kernel memory size, and shared kernel memory size.

These provide deep insights into matters such as process memory handling, far beyond the information available in Activity Monitor, and without the overhead of a windowed human interface.