Why is my Node.js app only using one CPU core?

Real runs on the same 4 vCPU / 8 GB server, 2,500 simulated users

The short answer

Node.js runs your JavaScript on one thread per process. However many cores the server has, one node process can only keep one of them busy with your code. On a 4 core server that looks like 25 to 40% CPU in total while the app is completely full and requests are queuing.

Node does use a few helper threads for garbage collection and some I/O, which is why a node process can show a bit more than 100% in top. The thread that runs your request handlers still cannot go past one core.

What it looks like under load

The table above is from real runs, all on the same server size with the same ramp to 2,500 simulated users. The apps do very different work per request, so compare the last two columns, not the requests a second.

Every Node app had the same shape. Requests a second climbed, then stopped growing. Past that point extra users either waited in line, so p95 kept rising, or got turned away (Directus answered 503, Ghost 429). The server as a whole stayed between 35 and 40% busy, and where there was a database, it never used more than half a core. The busiest thread inside the app container was at 100%.

Gitea (written in Go) and WordPress (PHP under Apache) are the contrast. Both spread the work across all four cores and ran out of CPU on every one of them. That is the case where a bigger server actually helps.

How to check your own server

Do not trust a total CPU graph. Most hosting dashboards average all cores, so one full core on a 4 core box shows up as 25%.

On the server, run top and press 1. That shows each core on its own line. If one core is near 100% while the others are mostly idle, and the app is slow at the same moment, this is your problem.

To be sure it is your app, run top -H -p followed by the process id of node. That lists the threads inside the process. One thread near 100% confirms it.

In docker stats, 100% means one full core. A Node container stuck around 100 to 150% on a box with more cores is a strong hint.

Why Node works this way

Node is built around one event loop. While a request waits on the database or another API, the thread moves on to the next one, so a single thread can juggle thousands of slow, waiting requests. That is why it works so well for I/O.

The catch is the work that is not waiting: serializing JSON, rendering React on the server, validating input, turning database rows into objects. All of that runs on the one thread, one request at a time. Once that adds up to a full core, the process cannot go any faster, however idle the rest of the server is.

The fix: one process per core

Run several copies of the app on the same server and spread the requests between them. There are three common ways.

Several containers behind a reverse proxy. Run the app 3 or 4 times (for example with replicas in docker compose) and put nginx, Caddy or Traefik in front. This works for any framework, including Next.js, and is easy to reason about.

PM2 in cluster mode. pm2 start server.js -i max starts one process per core and shares the port between them.

The node:cluster module. A few lines at the top of your server file fork one worker per core. This is what PM2 does for you.

Start with one process per core. If the database runs on the same server, leave it some room. worker_threads is a different tool: it is for moving one heavy job (resizing an image, hashing) off the main thread, not for spreading normal requests across cores.

What to change before running several processes

Each process has its own memory, so anything kept in memory is no longer shared. Sessions, caches, rate limit counters and WebSocket rooms need to move to a shared store such as Redis or the database, or users will see different results depending on which process answers.

Scheduled jobs run once per process. If the app starts a cron job on boot, four processes run it four times. Run it in one place only.

Memory and database connections multiply. Four processes use roughly four times the memory, and each opens its own connection pool. With a pool of 20 and four processes you need 80 connections, and Postgres allows 100 by default.

When it is not one core

If every core is busy, like Gitea and WordPress above, the CPU really is the limit. A bigger server or less work per request will help, and a profiler will show where the time goes.

If nothing on the server is busy and latency still climbs, the limit is outside the app: usually the database, its connection pool, or an external API you call.

Check your own app

Stresix measures CPU per core and per thread inside each container while it ramps up the load, and the report says it plainly when one thread was the limit and whether a bigger server would help. Point it at a GitHub repository or Docker image. Your first run is free (Lite: up to 500 simulated users in a 4 minute window on 2 vCPU / 4 GB, where one full core shows up as about 50%).

Frequently asked questions

Related guides

• we load tested stresix with stresix
• we load tested umami, the whole stack
• wordpress vs ghost vs strapi vs payload vs directus
• self-hosting next.js on one core
• how many users can a 2 vcpu / 4 gb vps handle
• how to size a server before a launch