DEV Community: Thomas Shafer

How to see which app is using the most memory on a Mac

Thomas Shafer — Fri, 06 Nov 2026 16:03:41 +0000

The quickest answer is to sort Activity Monitor by Memory and read the top rows. The catch is that one app often shows up as dozens of rows, so the biggest single row is rarely the biggest app. The fix is to add the rows up per app. Here is how I do it in Terminal, and how to tell whether the number is a problem at all.

How do I see memory use per app instead of per process?

Browsers and Electron apps run many helper processes. Activity Monitor shows each helper on its own line, with names like Google Chrome Helper (Renderer). This one-liner groups every process by the .app it lives in and adds up resident memory:

ps -axo rss=,command= | awk '{ if (match($0, /[^\/]+\.app/)) { a=substr($0,RSTART,RLENGTH); m[a]+=$1 } } END { for (k in m) printf "%8.0f MB  %s\n", m[k]/1024, k }' | sort -rn | head

It prints something like this, with your own apps and numbers:

    4210 MB  Google Chrome.app
    1650 MB  Slack.app
     980 MB  Xcode.app

Two caveats. rss is resident memory, and shared pages get counted once per process that maps them, so the totals run a little high. And anything that isn't inside a .app bundle, like node or docker, is skipped by this command. For those, use the next section.

How do I find the biggest single processes?

top can do it without leaving the terminal:

top -o mem -l 1 -n 10 -stats pid,command,mem

-l 1 takes one sample and exits, -o mem sorts by memory, and -n 10 limits it to ten rows. This is where command-line tools like node, python or java show up, which the .app grouping above misses.

If you have a pile of node processes, add them up by name:

ps -axo rss=,comm= | awk '{ n=$2; sub(/.*\//,"",n); m[n]+=$1 } END { for (k in m) printf "%8.0f MB  %s\n", m[k]/1024, k }' | sort -rn | head

That is the command that first showed me how much a few forgotten dev servers were holding.

Is high memory use actually a problem on a Mac?

Not by itself. macOS uses spare RAM for file caches on purpose, so "almost all of it is used" is normal. What matters is pressure: whether the system is having to compress memory or swap to disk to keep up.

memory_pressure | tail -n 1

The last line reports the percentage of memory free, and the output above it says whether the system is under pressure. Activity Monitor's Memory tab shows the same thing as the green, yellow or red Memory Pressure graph. As a rule of thumb:

Green: nothing to do, even if the used number looks scary.
Yellow: the system is compressing memory. Worth finding the biggest app.
Red: it is swapping heavily. Quit something now.

You can also look at swap directly:

sysctl vm.swapusage

Swap that keeps growing while you work is a better sign of a leak than a high used-memory number is.

How do I tell a leak from normal use?

A single reading can't tell you. A leak is memory that keeps climbing in one app while you do the same thing. Run the per-app command twice, thirty minutes apart, and compare. If one app gained a couple of gigabytes and the rest are flat, that is your culprit.

On the Mac I work on, that app was usually a long-running dev server or an Electron app I had left open for days. Quitting and reopening it gave the memory back.

Can I quit the app safely?

Use the normal quit first, with Cmd-Q, and give it a few seconds. Only use force quit if it hangs, because you can lose unsaved work. From the terminal:

osascript -e 'quit app "Slack"'

That asks the app to quit the same way Cmd-Q does, so it gets a chance to save. kill -9 does not, so keep it for last.

Is there a way to not do this by hand?

I got tired of pasting that awk line, so I built the answer into Binnacle, the Mac menu bar monitor I make. Its Memory page lists memory by app with helpers folded in, so Chrome is one row. It keeps 30 days of per-app history, so you can look back at what grew yesterday. It has an alert that fires when an app's memory has grown by 2 GB in 30 minutes, at most once an hour per app. Quitting asks you to confirm first. It is free for 14 days and $9 once after that, and the menu bar readouts stay free after the trial: https://binnacle.shafer.llc?utm_source=blog

You don't need it for this, though. The three commands above answer the question on any Mac:

ps with awk to total memory per app.
top -o mem for the biggest single processes.
memory_pressure to decide whether any of it matters.

If pressure is green, close the terminal and get on with your day. If it is yellow or red, the first line of the per-app list is where to start.

Port 3000 is already in use: find and stop what holds it

Thomas Shafer — Wed, 04 Nov 2026 17:03:50 +0000

You run npm run dev and get EADDRINUSE: address already in use :::3000. Something is holding the port, and it's usually a dev server you forgot about. Maybe it's from a terminal tab you closed yesterday, or a script that spawned a child and then died.

This is how I find and stop it, first with the tools that ship with the Mac, then with the way I do it now.

The terminal way

Ask which process is listening on the port:

lsof -nP -iTCP:3000 -sTCP:LISTEN

The flags matter. -n and -P skip DNS and service-name lookups, which makes it fast. -iTCP:3000 -sTCP:LISTEN keeps only the listening socket, so you don't get every client connected to it.

You'll get a table. The PID column is what you want:

COMMAND   PID  USER   FD   TYPE  NODE NAME
node    48213  tom    23u  IPv6  TCP  *:3000 (LISTEN)

Then stop it:

kill 48213

Plain kill sends SIGTERM, which lets the process clean up. Give it a second and run the lsof line again. If it's still there, kill -9 48213 ends it without asking, so use it second, not first.

Where this goes wrong

The two-step routine works, but I kept running into the same few problems:

The PID tells you nothing. node is not an answer. Which project is that? I have several. Killing the wrong one means losing a running server in another window.
A single node can be a tree. Dev tools spawn workers, watchers and helper processes. You kill the parent and a child keeps the port. You kill the child and the parent starts another.
IPv4 and IPv6 are separate listeners. localhost:3000 can be bound on ::1 and 127.0.0.1 by different processes. Checking only one hides the other.
It's not always yours. On macOS, AirPlay Receiver has used port 5000 and 7000, and I've seen people blame their own code for hours before finding that out. Check the process name before you kill anything.

To get the project, you can look up the process's working directory:

lsof -a -p 48213 -d cwd

That prints the folder the process was started from, which is usually enough to recognise the project. It's a third command, and I never remembered the flags.

How I do it in Binnacle

I built Binnacle partly because I was tired of this routine. It's a Mac activity monitor that lives in the menu bar and opens into a full-window console I call the Command Deck. It has two ways to deal with a stuck port.

The ⌘K command line. Open the Deck, press ⌘K and type:

port 3000

It shows the process holding the port. If that's the one you want gone:

kill port 3000

It asks you to confirm before it does anything. That confirmation is deliberate: every quit in Binnacle asks first, because I've closed the wrong thing too many times.

The Projects page. If you don't know which port you're after, this page lists your dev servers grouped by project folder. Each row shows the ports it's listening on, its memory use and how long it has been idle, with a Stop button. The folder grouping answers the "which project is that?" question without a cwd lookup. The idle time helps with the forgotten ones. A server that has been idle since yesterday morning is probably not one you need.

One implementation detail, in case you care: Binnacle reads ports through libproc, a macOS system library, so it doesn't shell out to lsof and parse the text.

A short checklist

Whichever tool you use, this order saves me time:

Find the listener on the port, not just any socket that mentions it.
Work out which project it belongs to before you stop it.
Try a normal stop (SIGTERM) first. Escalate only if it stays.
Run the check again to confirm the port is actually free.
If the same port is busy again a minute later, something is restarting it. Look at the parent process, a file watcher or a process manager, instead of killing it over and over.

Is it worth paying for?

If you hit this once a month, the lsof and kill pair is fine, and you shouldn't install anything. Save the one-liner as a shell alias and move on.

Binnacle makes more sense if you run several dev servers at once, or if the port is only one of the questions you ask. The same Deck covers things like which app is behind a spinning fan, or what's using the memory. It has a 14-day trial with everything unlocked. After that it's $9 once, and the menu bar readouts stay free. The Deck, including the Projects page and ⌘K, needs the license.

It needs macOS 14 or later. It collects no telemetry, and its only network calls are license activation and update checks.

If you try the port commands and one of them gets it wrong on your machine, tell me which setup you were running. Those reports are the most useful thing I get.

Why is my Mac's fan so loud? How to find the app causing it

Thomas Shafer — Mon, 02 Nov 2026 17:04:41 +0000

A loud fan almost always means one thing: some app is keeping the CPU busy, and the chip is getting hot. Open Activity Monitor, click the % CPU column to sort, and watch the top rows for 30 seconds. Whatever stays near the top is your answer, or at least your first suspect.

That's the short version. The rest of this post covers where it goes wrong, the Terminal version, and what I do now.

How do I see what is using the CPU?

In Activity Monitor (Applications > Utilities), select the CPU tab and click % CPU until the arrow points down. Don't trust a single glance. CPU use jumps around, so watch for half a minute and note which names keep coming back.

In Terminal, the same thing:

top -o cpu -n 10 -l 2

-o cpu sorts by CPU, -n 10 shows 10 processes, and -l 2 takes two samples. Read the second one. The first sample reports CPU use since the process started, which is why a one-shot top often shows nonsense.

For a quick snapshot without the live display:

ps -Ao pid,pcpu,comm -r | head -n 11

-r sorts by CPU on macOS. The first line is the header, so head -n 11 gives you the top 10.

Why does the list not make sense?

Because modern apps are not one process. Chrome, Slack, VS Code and most Electron apps run a main process plus a pile of helpers, renderers and GPU processes. In Activity Monitor, they show up under names like Google Chrome Helper (Renderer), a dozen times each.

Two things follow from that:

No single row looks guilty. Ten helpers at 8% each is 80% of a core, but nothing in the list looks alarming.
Some names don't point to an app. node, python3 and WindowServer tell you what ran, not who asked for it.

So after sorting, I add up the rows by app in my head, which is tedious. If you do it by hand, add the %CPU of every helper whose name starts with the same app and compare the totals.

What if the CPU looks fine?

Sometimes the fan is loud and no single app is high. Check these:

Is the Mac thermally constrained? Running in a closed clamshell, on a soft surface, or on a charging dock with a hot charger all reduce cooling. Fix the situation first.
Is it the GPU or media? Video calls, external displays and screen sharing load the GPU and media engines, which don't show up as CPU.
Is it the disk or network? A big sync or backup can keep several subsystems busy at once. Check the Disk and Network tabs.
Is it a short spike? Spotlight indexing after an update, or Photos analysing a library, can run hot for an hour and then stop. If it settles by itself, leave it alone.

To see the thermal state macOS itself reports:

pmset -g thermlog

If it prints nothing about CPU limits, the system isn't throttling you.

How do I stop it?

Once you know the app:

Quit it normally (⌘Q). Wait ten seconds.
If it doesn't quit, select it in Activity Monitor and use Force Quit (the stop button). Save your work first.
If it comes back on its own, something is relaunching it. Check Login Items in System Settings > General.
If the same app does it every day, look for an update, or a specific tab, extension or project that triggers it. In a browser, I find the heavy tab by opening the browser's own task manager instead of guessing.

Don't force quit a process whose name you don't recognise without searching for it first. Quitting WindowServer logs you out, and kernel_task going high is usually the system protecting itself from heat, not the cause of it.

How I do it now

I got tired of adding up helper rows, so I built Binnacle, a Mac activity monitor for the menu bar. It groups processes by app, so Chrome is one row with its CPU, memory, disk, network, GPU and energy summed. The CPU page shows temperatures, fans and the top apps in one place. In the ⌘K command line, why chrome explains what that app is doing, and quit chrome closes it after a confirmation.

On Apple silicon Macs, Binnacle can also set a fan to a fixed speed, within the fan's own minimum and maximum, and it goes back to automatic when the app quits. I mostly use it to check that a fan is doing its job, not to run it hard.

It has a 14-day trial with everything unlocked. After that it's $9 once, and the menu bar readouts keep working for free. The Deck, the console where all of this lives, needs the license. It requires macOS 14 or later.

If Activity Monitor and the Terminal lines above answer your question, you don't need it. They answer it for most people most of the time. I built Binnacle for the days when I'd rather not do arithmetic across 30 helper processes to find out which app is hot.

How to ask Claude what's eating your Mac's CPU (MCP setup)

Thomas Shafer — Sat, 31 Oct 2026 17:04:41 +0000

You can ask Claude, Codex or Cursor what is slowing your Mac down, and get an answer from live data instead of generic advice. You need an MCP server on your Mac that reports what is running. Register it once, and the assistant can call it whenever you ask.

I built one into Binnacle, my menu bar monitor, called binnacle-mcp. Here is how the setup works and what it can and can't do.

Why can't an assistant just answer this itself?

Because it can't see your machine. Ask "why is my fan loud?" in a plain chat and you get a list of guesses: close tabs, check Activity Monitor, reset the SMC. Nothing in that answer comes from your Mac.

An assistant that can run top in a terminal gets closer, but top lists processes. Chrome alone shows up as dozens of helper rows, and Electron apps and node do the same. In one of my screenshots, node is 134 processes and 9.06 GB. That's a lot of rows for an assistant to add up itself.

MCP (Model Context Protocol) fixes this by giving the assistant a few named tools it can call. The tools do the measuring. The assistant only has to ask.

How do I add it to Claude Code?

In Binnacle, open Settings › Assistants. It shows a ready-made line with the right path for your install. It looks like this:

claude mcp add binnacle -- "/Applications/Binnacle.app/Contents/MacOS/binnacle-mcp"

The path in your copy depends on where you put the app, so copy the line from Settings rather than typing it. Run it in a terminal, then check that it registered:

claude mcp list

The server talks to the assistant over stdio, so there is nothing to host and no port to open. Codex and Cursor can use the same binary. They each have their own way of registering an MCP server, so check their docs for the config format.

The server is off by default. You switch it on in Binnacle first. Until you do, the tools reply that it's disabled.

What can the assistant ask for?

There are six tools:

Tool	What it returns
`system_status`	Whole-Mac snapshot: process count, load, temperatures, fans, GPU, battery, disk space, Bluetooth batteries
`top_apps`	Busiest apps, with helper processes folded into their app. CPU is percent of one core
`app_details`	One app by name: CPU, memory, processes, listening ports
`who_uses_port`	Which process is listening on a TCP port, and the folder it was started in
`dev_servers`	Servers running inside project folders, with their ports and memory
`request_quit`	Asks you, in Binnacle's own window, whether to quit an app

One detail matters for CPU questions: top_apps reports percent of one core. On a multi-core Mac, an app at 250% is using two and a half cores, not breaking the scale. If the assistant says "Chrome is at 180%", that is the number it means.

What does a real question look like?

Try these in Claude Code once the server is registered:

What's using the most CPU on my Mac right now?
Why is my fan running? Check temperatures and the busiest apps.
What is listening on port 3000, and which project started it?
Which dev servers are running, and how much memory are they using?

The fan question is a good example of why tools beat guesses. The assistant can call system_status for temperatures and fans, then top_apps for the culprit, and answer in one reply with the app's name attached.

The port question is the one I use most. who_uses_port returns the process and the folder it was started in, so the assistant can tell you "that's the Vite server from ~/Projects/shop" rather than a bare PID.

Can the assistant kill things on its own?

No, and that was a deliberate limit. Five of the six tools only read. The sixth, request_quit, doesn't quit anything. It opens a confirmation dialog in Binnacle, and you decide there. If you ignore it, nothing happens.

I wanted it this way because an assistant that acts on a wrong guess about a process is a bad trade for the convenience. A confirmation dialog costs one click.

Binnacle has no telemetry. Its only network calls are license activation and update checks.

What does it cost?

Binnacle has a 14-day trial with everything unlocked, then it's $9 once. binnacle-mcp is part of what the license unlocks after the trial. The menu bar readouts stay free after the trial, but the MCP server doesn't.

If you'd rather not install anything, the same questions work from a terminal with top -o cpu and lsof -i :3000. You'll do the adding up yourself, and the assistant won't see any of it.

If you want the version where the assistant does the adding up, Binnacle is at https://binnacle.shafer.llc?utm_source=blog. It needs macOS 14 or later.

What I'd check if it doesn't work

The assistant says the tools are disabled. Turn the server on in Settings › Assistants.
claude mcp list doesn't show binnacle. Re-run the copied line and check the quotes around the path.
It worked, then stopped after a trial ended. The MCP server needs a license after the 14 days.

EADDRINUSE on macOS: find what holds the port, and stop it safely

Thomas Shafer — Sun, 18 Oct 2026 17:03:06 +0000

You run npm run dev and get this:

Error: listen EADDRINUSE: address already in use :::3000

Something is already listening on port 3000. Usually it's a dev server you forgot about: a terminal tab you closed, an editor task that never exited, or a watcher that outlived its parent. This post covers how to find the owner on macOS, how to stop it without guessing, and a pair of shell functions so you only have to work it out once.

Step 1: ask the kernel who is listening

lsof is already on your Mac. This is the form worth memorising:

lsof -nP -iTCP:3000 -sTCP:LISTEN

What each flag does:

-n skips DNS lookups, so it returns instantly.
-P shows 3000 instead of a service name.
-iTCP:3000 limits it to TCP port 3000.
-sTCP:LISTEN hides client connections, so you only see the process that owns the port.

Example output:

COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
node    48213 tom    23u  IPv6  0x1234      0t0  TCP *:3000 (LISTEN)

The -sTCP:LISTEN filter matters more than it looks. Without it, lsof -i :3000 also lists your browser's open connections to the server, and you can end up killing Chrome instead.

If you only want the PID, -t prints just that:

lsof -nP -tiTCP:3000 -sTCP:LISTEN

Step 2: check what it is before you kill it

A PID tells you very little. Before you stop it, look at two things: the full command line and the working directory.

ps -o pid,etime,command -p 48213
lsof -a -p 48213 -d cwd -Fn | sed -n 's/^n//p'

etime shows how long it has been running, and the cwd line shows which project folder it was started from. Together they usually settle it. A node process that has been up for three days, started from ~/old-prototype, is safe to stop. One that started two minutes ago from the project you're working on is probably your own server, running in another tab.

Step 3: ask nicely first

kill with no signal sends SIGTERM, which lets the process close its sockets and clean up. Use kill -9 only if that doesn't work.

kill 48213
sleep 1
lsof -nP -tiTCP:3000 -sTCP:LISTEN || echo "port 3000 is free"

Reaching for kill -9 first is a common habit and it costs you something real. A process killed that way can't remove its lock files, flush its logs or shut down its child processes, and you can end up with a half-written database or a leaked worker.

Step 4: put it in your dotfiles

Here are two functions for ~/.zshrc. port shows who holds a port. killport stops it with SIGTERM, waits, and only then falls back to SIGKILL.

port() {
  lsof -nP -iTCP:"${1:?usage: port N}" -sTCP:LISTEN
}

killport() {
  local pids
  pids=$(lsof -nP -tiTCP:"${1:?usage: killport N}" -sTCP:LISTEN)
  [ -z "$pids" ] && { echo "nothing is listening on $1"; return 0; }
  echo "$pids" | xargs kill
  sleep 1
  pids=$(lsof -nP -tiTCP:"$1" -sTCP:LISTEN)
  [ -n "$pids" ] && echo "$pids" | xargs kill -9
  lsof -nP -tiTCP:"$1" -sTCP:LISTEN >/dev/null || echo "port $1 is free"
}

Open a new terminal and run port 3000 or killport 3000.

One limit: this only sees processes you own. If the listener belongs to root or another user, lsof without sudo may show nothing at all. In that case you'll get "nothing is listening" even though the port really is taken, so try sudo lsof ... before concluding it's free.

When killing the process isn't the answer

Some holders come back, or aren't what they look like.

Port 5000 or 7000 on a recent Mac. macOS's AirPlay Receiver listens on both. The owner shows up as ControlCe (Control Center). Turn it off in System Settings > General > AirDrop & Handoff > AirPlay Receiver, or move your dev server to another port. Killing it just makes macOS start it again.

The owner is Docker. If lsof shows com.docker.backend or similar, a container has published the port. Use docker ps --format '{{.Names}}\t{{.Ports}}' to find the container, then docker stop it. Killing the backend process takes down every container.

The process has a parent that restarts it. nodemon, next dev, a docker compose restart policy and some editor tasks will respawn what you kill. Check the parent with ps -o ppid= -p PID, then look at what that parent is.

Nothing is listening, but the bind still fails. This is rare. It can happen when a server binds the same address and port twice, such as localhost resolving to both ::1 and 127.0.0.1, or two copies of a framework starting in one process. lsof will show one listener for each address family, so read the NAME column carefully.

A small habit that prevents most of this

Most EADDRINUSE errors come from servers that were started and then abandoned. Two habits cut them down:

Run dev servers in the foreground in a terminal you can see. Don't background them with &.
Let your tooling pick a free port where it supports that. Many frameworks will move to the next port if you tell them to, instead of failing.

Full disclosure: I made a tool for this

I built Binnacle, a native Mac menu bar monitor, partly because I got tired of typing the commands above. In its ⌘K command line, port 3000 shows the process, and kill port 3000 stops it after a confirmation. Its Projects page groups dev servers by project folder and shows their ports, memory and how long they've been idle, with a Stop button. The menu bar readouts are free. The rest of the app is free for 14 days, then $9 once. It needs macOS 14 or later. It's at https://binnacle.shafer.llc?utm_source=devto.

You don't need it for any of the above. The two functions in your .zshrc will cover most days.

What's the strangest thing you've found sitting on a port? I'm curious what other surprise listeners are out there.