# Why Your Mac Is Slow and How to Diagnose It

> Measure CPU, memory pressure, storage capacity, disk I/O, thermal state, and network latency while the slowdown occurs.

Published: 2026-07-04 | Updated: 2026-07-25

A slow Mac is a latency problem, and several bottlenecks can produce the same feeling:
CPU contention, memory pressure, storage capacity, disk I/O, thermal limits, or a slow
network service. The goal is to identify which resource is saturated while the
slowdown is happening. A snapshot taken after the problem ends proves little.

Here is how the pieces work, and the commands to see them.

## The RAM myth: free memory is not the goal

The most common wrong instinct is to look at "free memory" and panic when it is
low. On macOS, low free memory is normal and healthy. Unused RAM is wasted RAM,
so the kernel deliberately keeps it full: recently used files stay cached in
memory so the next read is instant, and that cache is released the moment a
program needs the space.

macOS also compresses memory. Since OS X Mavericks, when RAM fills, the system
compresses inactive pages in place rather than immediately writing them to disk,
so some data that would otherwise move to slower swap can stay in RAM. You can watch
the counters directly:

```
vm_stat
```

The numbers are in pages, with the page size printed near the top. What matters is not
`Pages free` but memory pressure and the rate of change. `Swapins` and `Swapouts` are
cumulative since boot, so one large number does not prove a current problem. Run the
command twice during the slowdown or use Activity Monitor to see whether swap and
pressure keep rising.

The best overview is **memory pressure** in Activity Monitor's Memory tab. Apple's
[memory guide](https://support.apple.com/guide/activity-monitor/actmntr34865/mac)
defines green as efficient use, yellow as possible pressure, and red as needing more
RAM. Read that graph with the swap trend and the app list, not the free-memory figure
alone.

## Find the real bottleneck

<figure class="blog-diagram">
  <img src="https://mole.fit/img/en/status.webp" width="2584" height="1741" loading="lazy" alt="A system dashboard with tiles for CPU at 6 percent and 44 degrees, GPU at 1 percent, memory at 55 percent with pressure 18 percent, disk, network, and fan, above a list of the top processes sorted by CPU and memory.">
  <figcaption>The numbers that explain a slow Mac on one screen: CPU load and temperature, memory pressure, and the processes using the most resources. This is Mole's Status view.</figcaption>
</figure>

Open Activity Monitor and read its tabs in order, or use the command line:

- **CPU:** sort by usage with `top -o cpu` in Terminal, or the Activity Monitor
  CPU tab. Note that %CPU is per core, so a value above 100% is one process using
  several cores, which is normal for a build or an export and suspicious for an
  idle app.
- **Memory:** the pressure graph, as above.
- **Disk capacity:** run `df -h /`. APFS uses free space for swap and temporary
  files, and a nearly full drive can block updates or leave a workload without
  temporary room. There is no universal safe percentage, so compare available
  capacity with the task that is failing. If this is your problem,
  [find what is filling the disk](https://mole.fit/blog/how-to-find-large-files-on-mac) and
  [free up space](https://mole.fit/blog/how-to-free-up-space-on-mac).
- **Disk I/O:** in Activity Monitor's Disk tab, sort by Bytes Written or Bytes Read and
  watch the graph while the pause occurs. `iostat -w 1` provides a live command-line
  view. A sync, backup, build, or failing external drive can cause latency even when
  plenty of capacity remains.
- **Heat:** covered below.
- **Network or service latency:** if only one cloud-backed app is slow while local apps
  remain responsive, check its network activity and service status before changing the
  Mac. Not every slow interaction is a hardware bottleneck.

These readings separate a system-wide bottleneck from one slow app. Guessing with a
generic cleanup can change several variables and hide the actual cause.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/performance-bottlenecks.webp" width="1360" height="454" loading="lazy" alt="A workload branching into CPU saturation, memory pressure, disk input and output, and thermal throttling before converging as latency">
  <figcaption>CPU contention, memory pressure, disk I/O, and thermal limits all surface as latency, but each requires a different fix.</figcaption>
</figure>

## A runaway process

If the CPU is pinned, `top -o cpu` shows the culprit at the top. A stuck app, a
sync client re-scanning, or a background helper caught in a loop are the usual
cases. If you recognise it as safe to end, quit it. If it relaunches itself
within seconds, it has a launchd job behind it (see the last section), and
quitting the process alone will not hold.

Be careful with system processes. `kernel_task` climbing is often the system
deliberately using CPU time to slow the chip down when it is hot, not a bug to
kill. That is a thermal symptom, not a memory or app one.

## Thermal throttling

When a Mac runs hot, the chip lowers its clock speed to cool down, and heavy work
feels sluggish. You can confirm it rather than guess:

```
pmset -g therm
```

This reports recorded thermal and performance warning state when macOS exposes it.
For one detailed sample of power and thermal pressure, use:

```
sudo powermetrics --samplers thermal,cpu_power -n 1
```

Interpret trends under the same workload rather than treating one temperature as a
universal limit. If throttling is the bottleneck, the fix is workload, airflow, or
service, not cache cleaning. A loud fan can be supporting evidence, but fanless Macs
can throttle too, and
[why your MacBook fan is loud](https://mole.fit/blog/macbook-fan-loud-overheating) covers what to
do about it.

## Spotlight and login items

Two background causes are worth ruling out. After a macOS update, migration, or large
file move, Spotlight may rebuild parts of its index. `mdutil -s /` reports whether
indexing is enabled, not whether a rebuild is currently active. Sustained `mds` or
`mdworker` CPU plus disk I/O and Spotlight's progress UI provide the context. Duration
depends on data volume, storage speed, permissions, and repeated file churn, so there
is no reliable one-hour promise.

The other is startup load. **System Settings > General > Login Items & Extensions**
separates apps opened at login from software allowed to run in the background. Those
may use Service Management, launchd, extensions, or app helpers. Disable one known item
at a time and confirm the owning app still works.

## Under the hood: how a monitor reads this without adding to it

You can skip this part, but it explains why the memory advice above is right, and
why a live monitor does not itself become one of your slow processes. Mole's
[open-source CLI](https://github.com/tw93/Mole) (`cmd/status`) and native Mac app
use separate collectors, but both split fast readings from slow enrichment.

The CLI fills the cached-memory value that its cross-platform metrics library
cannot provide on macOS by parsing file-backed pages from `vm_stat` and multiplying
by the reported page size. It reads the system pressure state from
`memory_pressure` instead of deriving it from free bytes. The native app reaches
the same answer without shelling out: it reads VM counters with `host_statistics64`
and the pressure level through `kern.memorystatus_vm_pressure_level`.

Staying light is the other half. A monitor that re-measured everything on every
tick would be its own performance problem, so the collector samples in tiers:

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/tiered-metrics-sampling.webp" width="1360" height="454" loading="lazy" alt="Fast, slow, and one-time system metrics pass through concurrent collectors or caches, merge into one snapshot, enter a ring buffer, and render in the status view and menu bar HUD">
  <figcaption>The implementations are separate, but the scheduling pattern is the same: fast metrics refresh live, slow probes reuse cached results, and one merged snapshot feeds current readings plus bounded history.</figcaption>
</figure>

The cheap numbers (CPU, memory, and network) refresh about once a second. Process,
GPU, and disk enrichment run on heavier ticks, while hardware and device probes
reuse longer-lived caches. Fixed-size histories hold only the recent samples that
draw the sparklines. That is how a menu bar HUD can update live without turning the
monitor into the workload you are trying to diagnose.

## Where a tool helps

Everything above is readable with built-in commands, which is the point: you do
not need an app to diagnose a slow Mac. What an app saves you is the assembly.
[Mole](https://mole.fit/)'s Status view shows CPU, memory pressure, disk, temperature, and the
top processes on one screen with a live menu bar readout, and clicking a process
explains what launched it, whether it is holding the Mac awake, and what it is
reading and writing, which is the same launchd and I/O detail you would otherwise
gather by hand. It is a convenience over the commands, not a substitute for
understanding them.

Whatever you use, avoid one-click "speed up" sweeps that change unrelated state. You
cannot create a durable performance gain by forcing useful file cache out of RAM.
Restarting can be a useful diagnostic for a stuck process and is required by some
updates, but macOS already manages memory and swap continuously.

## A repeatable diagnosis

Reproduce the slowdown, watch CPU, memory pressure, disk capacity, disk I/O, thermal
state, and network activity, then change one variable. Measure again under the same
workload. This turns "the Mac feels slow" into a falsifiable cause and prevents a
temporary restart or cleanup from being mistaken for a permanent fix.

---

Canonical HTML page: https://mole.fit/blog/why-is-my-mac-so-slow
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt