Optimizing Nginx: Configure worker_processes and worker_cpu_affinity for Maximum Performance

Editing the Nginx configuration

Open the main configuration file, typically /nginx/conf/nginx.conf or /usr/local/nginx/conf/nginx.conf, and modify the worker_processes directive.

vi /nginx/conf/nginx.conf

1. worker_processes – number of worker processes

The default is one worker process, each capable of handling up to 1024 connections. Because each worker is single‑threaded, you should run as many workers as there are CPU cores if the modules used are non‑blocking; otherwise, add a few extra workers to absorb occasional blocking I/O.

Each worker runs in a single thread and loads modules to provide various functions.

If modules are non‑blocking, match the worker count to the number of CPU cores.

If blocking I/O (e.g., heavy disk reads) may occur, increase the worker count slightly.

Example scenario: a server with limited memory serves many static files from disk, causing disk‑I/O blocking that can temporarily stall a worker process and degrade overall performance.

Typical rule of thumb: set the number of workers to the number of CPU cores or to cores × 2 for high‑concurrency workloads.

You can view the core count with top -1 (press 1 inside top).

# Edit Nginx configuration
vi /usr/local/nginx/conf/nginx.conf
worker_processes 4;
# Save and exit
# Reload configuration
/usr/local/nginx/sbin/nginx -s reload
# Verify processes
ps -aux | grep nginx | grep -v grep

2. worker_cpu_affinity – binding workers to CPU cores

Binding each worker to a specific CPU core eliminates contention for the same core, achieving true parallelism on Linux systems (the directive is ignored on non‑Linux OSes).

Example configurations:

# For 2 CPU cores
worker_processes 2;
worker_cpu_affinity 10 01;

# For 4 CPU cores
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;

# For 8 CPU cores
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

These settings ensure each worker runs on its own core, reducing context switches and improving request handling efficiency.