Ottimizzazione dei Processi Worker di Nginx per le Massime Prestazioni: Una Guida Pratica

Nginx può gestire molte connessioni concorrenti con un'impronta di processo ridotta, ma solo se i suoi limiti dei worker sono allineati con la macchina sottostante. Le due impostazioni a cui le persone ricorrono per prime sono worker_processes e worker_connections. Sono utili, ma sono anche facili da sovra-ottimizzare. Impostare entrambi a numeri enormi non crea capacità gratuita. Può semplicemente spostare il collo di bottiglia sui descrittori di file, la memoria, i server upstream o lo stack di rete.

L'obiettivo pratico è dare a Nginx abbastanza worker per utilizzare i core della CPU che ha, abbastanza slot di connessione per il traffico reale e abbastanza limiti del sistema operativo per evitare di raggiungere il soffitto durante i picchi normali.

Comprensione dell'Architettura dei Worker di Nginx

Nginx opera utilizzando un modello master-worker. Il Processo Master è responsabile della lettura e della convalida della configurazione, del binding alle porte e della gestione dei processi worker. Esegue compiti non critici come il monitoraggio delle risorse di sistema e il riavvio dei worker se necessario.

I Processi Worker sono dove avviene il lavoro pesante. Questi processi sono single-threaded (nella compilazione standard di Nginx) e utilizzano chiamate di sistema non bloccanti. Ogni worker gestisce migliaia di connessioni concorrenti in modo efficiente utilizzando un ciclo di eventi, consentendo a un processo di gestire più richieste senza bloccarsi, il che è fondamentale per le prestazioni di Nginx.

Una corretta ottimizzazione comporta il bilanciamento del numero di worker (collegandoli alle risorse della CPU) e l'impostazione del numero massimo di connessioni che ogni worker può gestire.

Configurazione di `worker_processes`: Il Fattore dei Core della CPU

La direttiva worker_processes determina quanti processi worker Nginx dovrebbe generare. Questa impostazione influisce direttamente su come Nginx utilizza le risorse della CPU del tuo server.

Migliore Pratica: Abbinare i Worker ai Core

La pratica migliore più comune e altamente raccomandata è impostare il numero di processi worker uguale al numero di core della CPU disponibili sul tuo server. Ciò garantisce che ogni core sia utilizzato in modo efficiente senza incorrere in un overhead eccessivo dovuto al context switching.

Se il numero di worker supera il numero di core, il sistema operativo deve cambiare frequentemente il focus della CPU tra i processi Nginx in competizione (context switching), il che introduce latenza e riduce le prestazioni complessive.

Utilizzo della Direttiva `auto`

Per le versioni moderne di Nginx (1.3.8 e successive), il parametro più semplice ed efficace è l'uso del parametro auto. Nginx rileverà automaticamente il numero di core della CPU disponibili e imposterà i processi worker di conseguenza.

# Impostazione consigliata per la maggior parte delle distribuzioni
worker_processes auto;

Configurazione Manuale

Se hai bisogno di controllo manuale o stai utilizzando una versione precedente, puoi specificare il numero esatto di worker. Puoi trovare il numero di core utilizzando utilità di sistema:

# Trova il numero di core della CPU
grep processor /proc/cpuinfo | wc -l

Se il sistema ha 8 core, la configurazione sarebbe simile a questa:

# Impostazione manuale dei processi worker a 8
worker_processes 8;

Suggerimento: Abbinare il numero di core disponibili è il punto di partenza più sicuro. In carichi di lavoro insolitamente intensivi di I/O potresti testare un valore diverso, ma confrontalo con il traffico realistico prima di mantenerlo. Per il servizio statico tipico, il proxy e la terminazione TLS, auto è di solito la scelta meno sorprendente.

Configurazione di `worker_connections`: Il Fattore di Concorrenza

La direttiva worker_connections è configurata all'interno del blocco events e definisce il numero massimo di connessioni simultanee che un singolo processo worker può gestire. Questo include connessioni ai client, connessioni ai server proxy upstream e connessioni interne di health check.

Calcolo dei Client Massimi

Il numero massimo teorico di connessioni client concorrenti che il tuo server Nginx può gestire è calcolato come segue:

$$\text{Max Clients} = \text{worker_processes} \times \text{worker_connections}$$

Se hai 4 processi worker e 10.000 connessioni worker per processo, Nginx potrebbe teoricamente gestire 40.000 connessioni simultanee.

Questo numero è solo un limite superiore approssimativo. Una richiesta proxy può utilizzare una connessione client e una connessione upstream contemporaneamente. Il traffico WebSocket e long-polling può mantenere gli slot per molto più tempo di una normale richiesta di pagina. Le connessioni keep-alive possono anche rimanere aperte mentre fanno molto poco lavoro. Se Nginx serve principalmente file statici, il calcolo è più vicino alla formula semplice. Se funge da proxy inverso, lascia margine.

Impostazione del Limite di Connessione

È comune impostare worker_connections a poche migliaia o più su server occupati, supponendo che i limiti di memoria e descrittori di file possano supportarlo. Non copiare un valore grande alla cieca; scegli un valore che corrisponda alla concorrenza prevista più spazio per i picchi.

# Esempio di configurazione per il blocco events

events {
    # Connessioni concorrenti massime per processo worker
    worker_connections 16384;

    # Può aiutare durante i picchi, ma testa l'equità sotto carico.
    multi_accept on;
}

Vincolo dei Limiti di Sistema (`ulimit`)

Fondamentalmente, l'impostazione worker_connections è vincolata dal limite del sistema operativo sul numero di descrittori di file (FD) aperti consentiti per processo, spesso controllato dall'impostazione ulimit -n.

Nginx non può aprire più connessioni di quante il sistema operativo consenta descrittori di file. Poiché ogni connessione (socket client, file di log, socket proxy) richiede un descrittore di file, è fondamentale che il limite di sistema sia impostato abbastanza alto.

Controllo e Aumento dei Limiti dei Descrittori di File

Controlla il limite corrente:
```
ulimit -n
```
Aumenta temporaneamente il limite (per la sessione corrente):
```
ulimit -n 65536
```
Aumenta permanentemente il limite (tramite /etc/security/limits.conf):

Aggiungi le seguenti righe, sostituendo nginx_user con l'utente con cui Nginx viene eseguito (spesso www-data o nginx):
```
# /etc/security/limits.conf
nginx_user soft nofile 65536
nginx_user hard nofile 65536
```

Attenzione: Assicurati che il limite dei descrittori di file per processo per l'utente worker di Nginx sia superiore a worker_connections, con spazio extra per log, socket upstream, file cache e altri file aperti. Anche i limiti a livello di sistema contano, ma il limite per processo è quello che più spesso sorprende le persone.

Se Nginx è gestito da systemd, /etc/security/limits.conf potrebbe non essere sufficiente. Molte distribuzioni avviano i servizi con limiti dal file unit. Controlla il limite attivo con:

cat /proc/$(pgrep -o nginx)/limits | grep "open files"

Per un override di systemd, usa:

sudo systemctl edit nginx

Poi aggiungi:

[Service]
LimitNOFILE=65536

Ricarica systemd e riavvia Nginx durante una finestra di manutenzione:

sudo systemctl daemon-reload
sudo systemctl restart nginx

Ottimizzazione e Monitoraggio Avanzati

Oltre alle direttive principali, alcune considerazioni aggiuntive possono aiutare a mettere a punto le prestazioni:

1. Pinning dei Processi Worker

In ambienti ad alte prestazioni, specialmente su sistemi con più socket CPU (architetture NUMA), potresti voler utilizzare la direttiva worker_cpu_affinity. Questo dice al sistema operativo di limitare processi worker specifici a CPU specifiche, il che può migliorare le prestazioni assicurando che le cache della CPU rimangano calde ed evitando problemi di località della memoria.

Esempio per un sistema a 8 core:

worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

Questa impostazione è complessa e di solito utile solo per situazioni di carico estremo; worker_processes auto è sufficiente per la maggior parte delle distribuzioni.

2. Monitoraggio delle Metriche di Prestazione

Dopo aver applicato le ottimizzazioni, è fondamentale monitorare l'impatto. Utilizza il modulo Nginx Stub Status (o uno strumento come Prometheus/Grafana) per tracciare le metriche chiave:

Metrica	Descrizione	Controllo Ottimizzazione
Connessioni Attive	Connessioni totali attualmente gestite.	Dovrebbe essere inferiore al massimo teorico.
Lettura/Scrittura/Attesa	Connessioni in diversi stati.	Conteggi elevati di Attesa spesso indicano Keep-Alive HTTP di lunga durata (buono) o risorse di elaborazione insufficienti (cattivo).
Tasso di Richieste	Richieste al secondo.	Utilizzato per misurare il miglioramento effettivo delle prestazioni dopo le modifiche alla configurazione.

Se osservi un utilizzo elevato della CPU su tutti i core e tassi di richiesta elevati, i tuoi worker_processes sono probabilmente configurati correttamente. Se hai core della CPU inattivi durante il traffico di punta, considera di rivedere la tua configurazione o di verificare la presenza di operazioni di I/O bloccanti al di fuori di Nginx.

3. Strategia di Overflow delle Connessioni

Se il server raggiunge il limite massimo di connessioni (worker_processes * worker_connections), nuove connessioni potrebbero fallire o rimanere in coda fino al timeout. Aumentare worker_connections può aiutare solo quando Nginx è il vero collo di bottiglia. Se i server applicativi upstream sono saturi, aumentare il limite può peggiorare la situazione perché più richieste si accumulano dietro backend lenti.

Usa il log degli errori come segnale. Messaggi come worker_connections are not enough puntano direttamente ai limiti di Nginx. Un aumento di upstream timed out, connect() failed o risposte 502/504 punta più verso la capacità del backend, problemi di rete o impostazioni di timeout.

Una Configurazione Iniziale Ragionevole

Per un proxy inverso piccolo o medio, questa è una base di partenza sensata:

worker_processes auto;
worker_rlimit_nofile 65536;

events {
    worker_connections 8192;
    multi_accept off;
}

Perché multi_accept off qui? È l'impostazione predefinita conservativa su molti sistemi. Attivarlo può aiutare un worker a svuotare rapidamente una coda di accept in sospeso, ma sotto alcuni modelli di traffico potrebbe far sì che un worker prenda un grosso lotto mentre altri rimangono inattivi. Se hai traffico a raffiche e un motivo testato per abilitarlo, fallo. Se stai ottimizzando un server web generico, mantieni la base semplice e misura prima.

Se il server gestisce molte connessioni WebSocket, Server-Sent Events o flussi API di lunga durata, aumenta il limite di connessione in modo più aggressivo e presta molta attenzione alla memoria. Un server con 20.000 client WebSocket per lo più inattivi ha un profilo diverso da un server che esegue 20.000 brevi richieste di file statici.

Come Convalidare la Modifica

Prima di modificare la produzione, cattura una piccola baseline:

nginx -T | grep -E 'worker_processes|worker_connections|worker_rlimit_nofile'
ss -s
ulimit -n

Dopo la modifica, verifica che Nginx l'abbia effettivamente caricata:

sudo nginx -t
sudo systemctl reload nginx
ps -o pid,comm,nlwp,pcpu,pmem -C nginx
cat /proc/$(pgrep -n nginx)/limits | grep "open files"

Poi osserva il comportamento durante il traffico reale. Se tutti i core della CPU sono occupati e la latenza aumenta, Nginx potrebbe star facendo lavoro utile e raggiungendo la capacità della CPU. Se la CPU è bassa ma le connessioni sono in coda o vanno in timeout, controlla i descrittori di file, la saturazione upstream, la risoluzione DNS, l'I/O del disco o i limiti del firewall. La messa a punto dei worker è una leva, non l'intera storia delle prestazioni.

Leggere i Numeri nel Contesto

Un errore comune è trattare le "connessioni attive" come la stessa cosa degli "utenti attivi". Non lo è. Un browser può aprire diverse connessioni per le risorse. Un client API può mantenere una connessione attiva tra le richieste. Un client WebSocket può mantenere una connessione per ore mentre invia quasi nessun traffico. Quando dimensioni worker_connections, pensa in termini di socket concorrenti, non di persone.

Per un proxy inverso, ricorda anche il lato upstream. Se 4.000 client sono in attesa di risposte proxy, Nginx potrebbe anche tenere migliaia di socket upstream. Ecco perché un server può esaurire i descrittori di file prima di quanto il semplice calcolo lato client dica. Questo è particolarmente visibile quando l'applicazione upstream rallenta: le richieste rimangono aperte più a lungo, la concorrenza aumenta e Nginx inizia a consumare più socket anche se il tasso di richieste in arrivo non è cambiato.

Anche le impostazioni keep-alive influenzano questo. Timeout keep-alive lunghi riducono il ricambio di connessioni, il che può aiutare i siti occupati, ma mantengono anche i socket inattivi più a lungo. Timeout keep-alive molto brevi liberano i socket più velocemente ma possono aumentare gli handshake TLS e l'overhead di configurazione della connessione. Non esiste un valore perfetto; usa la forma del traffico come guida. Un sito web pubblico con molte visite brevi potrebbe aver bisogno di un equilibrio diverso da un'API interna con un piccolo numero di client persistenti.

Se stai ottimizzando all'interno di un container, verifica i limiti all'interno del container e a livello di host o orchestratore. Un pod Kubernetes, un container Docker o un servizio systemd possono avere un limite nofile inferiore rispetto alla shell host che hai usato per testare. Controlla sempre il processo Nginx in esecuzione, non solo la tua sessione di login.

Riepilogo delle Migliori Pratiche

Direttiva	Valore Consigliato	Motivazione
`worker_processes`	`auto` (o conteggio core)	Garantisce un utilizzo ottimale della CPU e minimizza l'overhead del context switching.
`worker_connections`	Inizia con poche migliaia; aumenta in base alla concorrenza misurata	Fornisce margine di connessione senza nascondere altri colli di bottiglia.
Limite OS (`ulimit -n`)	Superiore alle esigenze di connessione per worker, con spazio extra	Fornisce descrittori di file per socket client, socket upstream, log e file cache.
`multi_accept`	Testa prima di abilitare	Può aiutare con i picchi, ma non è automaticamente migliore per ogni carico di lavoro.

La migliore configurazione dei worker di Nginx è di solito semplice: worker_processes auto, un limite di connessione che riflette la concorrenza reale e limiti dei descrittori di file sufficientemente alti per il carico di lavoro. Ottimizzala, verifica i limiti del processo attivo e continua a guardare il log degli errori. Se i sintomi puntano upstream, correggi l'upstream invece di far accettare a Nginx più lavoro di quanto l'applicazione possa completare.