Something’s clearly not right. Maybe your Mac has slowed to a crawl with frequent spinning beachballs and a juddery interface. You reach for Activity Monitor, and at the top of the list of processes in the CPU view there’s a process stealing 100% or even more. What do you do next? Select that process and click on the Stop button? This article explains.

The first problem you may need to grapple with is that percentage. If you thought that meant something out of hundred, then suspend your rational thought for a moment, as Apple uses it to refer to CPU “capability”. On any system with more than one core, this seems to represent the total across all available cores, and thus can readily exceed 100%. My iMac Pro has managed just over 1,000% on occasion.

Next, look carefully at the process which is hogging that high percentage. Is it an app displayed with its icon and you as its user, an app helper or similar, or part of macOS? If you don’t recognise it with confidence, tread carefully as there are some pitfalls with processes which are special. Many have giveaway names which relate them to apps and services, such as anything containing the letters Safari. Note the following in particular:

• cfprefsd, which is responsible for managing preference settings across most apps.
• distnoted, which is a background service handling distributed notification for many processes.
• kernel_task, which always has a PID of 0. This is the kernel, which busies itself to block other processes when your Mac is getting hot, and is discussed more below.
• launchd, which always has a PID of 1. This is the master launcher of other processes, second in importance to the kernel itself.
• logd, which is the unified log housekeeper, and essential for keeping your logs up to date and maintained.
• mdworker and mdworker_shared processes, which are multiple. These are the macOS metadata services which compile and maintain Spotlight indexes, and are discussed more below.
• WindowServer, which should have a PID of around 332, but varies with macOS version and configuration. This is WindowServer, responsible for compositing individual windows into the display image, and routing events such as clicks/taps to the correct app. Without it, there’s no GUI and no control over it, and it’s discussed more below.

If the process with the high CPU percentage is one of your currently running apps, and it appears to have become unresponsive, then rather than using the Stop button here, press Command-Option-Escape to see the Force Quit dialog, select it there, and force it to quit. This should ensure that all related processes are also shut down properly. Bear in mind that seizing the CPU in this way might actually be correct behaviour if you’ve given that app something computationally intensive to do.

Most services provided by macOS will be relaunched automatically if you decide to Stop them. However, that might not solve the problem, as that process may already be crashing repeatedly and being restarted. If you’ve done nothing to address the underlying problem of why they’re taking so much CPU, you may find that they soon return to the same state. Activity Monitor provides good tools for exploring what’s going on in more detail: check how much memory that process is using, whether it’s also using the GPU heavily, how many threads it has, and so on. Many of these are available using the Inspect button.

You can also get a much better idea of what’s going on by looking at the log. This is one of the few times that you could justifiably use Console rather than Ulbow or Consolation, as its live stream can give you a good idea of what the busy process is writing to the log. For example, mdworker and mdworker_shared processes can choke over indexing specific files or other metadata tasks, and may be reporting that error hundreds of times each second in the log. If you can identify the file which is causing that problem, you may be able to remove it and let the processes get back on with their work.

Although WindowServer is seldom a major CPU hog, when it is, it’s difficult to know what to do. If you’ve still got control of your Mac, try shutting down apps and any screen-sharing which might be exerting too heavy demand on it. You might be able to log out and log back in again to clear the problem, but restarting may be the only solution.

If it’s kernel_task, there are several potential causes, including:

• the kernel is overloaded, and liable to panic;
• the kernel is blocking other runaway processes as part of your Mac’s strategy to control internal temperature;
• there’s a faulty temperature sensor in your Mac, which is misleading its temperature control system into believing that it’s overheating, which is causing kernel_task to try to block other processes and allow the CPU to stay cool;
• the kernel is just heavily loaded at present, and will return to normal in due course.

Distinguishing these isn’t easy, and the last thing you want to do is interfere with your Mac’s normal response to rising internal temperatures. However, if it has only just started up, that should make you suspect other causes.

When you’ve coped with the immediate problem, consider what you can do to prevent it from occurring again. Some high CPU loads can result from incorrect permissions in your ~/Library folder: this is particularly true of those with Safari in their name. Check the list of symptoms given here. At present, Apple has removed its article detailing this and its recommended solution, suggesting that doesn’t work after all.

If you’re left unsure as to what happened, make a detailed note of the circumstances in which this occurred. If it happens again, you’ll then be in a much better position to reach a diagnosis, or at least point a finger. Be careful, though, when searching on the Internet for solutions: many only apply to older versions of macOS, or may be ill-informed.

I wish you success!

Thanks to John for pointing out the current variability in the PID of WindowServer. It once used to be a sentinel PID.