event-loopAnswer last reviewed July 2026

Tell me what actually runs on the libuv thread pool in Node. And once you know that, how do you decide what UV_THREADPOOL_SIZE should be?

Knows which operations hit the libuv pool, which ride the kernel, and which run on the calling thread, and sizes it by physical cores and measured concurrency

What an AI-prepared candidate might say

So the thread pool is for the operations the OS can't do asynchronously on its own. The main ones are the file system calls like fs.readFile, DNS lookups through dns.lookup, and I believe some of the crypto functions. Network sockets don't use the pool at all, they ride the OS async notification mechanisms, like epoll. The pool has four threads by default, so only four of these operations can run at once and the rest wait in a queue. You can raise that with the UV_THREADPOOL_SIZE environment variable, up to 1024 threads I think, which helps for services doing heavy file or crypto work. The rule of thumb I've seen is set it to the number of CPU cores. So fs.readFile looks non-blocking from your code's point of view, but the actual read is happening on a pool thread.

Senior
Locked

The full pool roster, fs, dns.lookup, pbkdf2/scrypt/randomBytes, async zlib, plus the three lookalikes that never touch it and why the env var only matters before first use.

Unlock the depth
Staff
Locked

An incident pattern where DNS queues up behind file reads, a way to prove pool saturation from latency histograms alone, and the sizing arithmetic against physical cores.

Unlock the depth
Follow-up chain
Tell me what actually runs on the libuv thread pool in Node. And once you know that, how do you decide what UV_THREADPOOL_SIZE should be? | NodeBook