Optimisation des processus worker Nginx pour des performances maximales : Un guide pratique

Nginx est réputé pour ses hautes performances et sa faible empreinte mémoire, en grande partie grâce à son architecture événementielle et asynchrone. Cependant, pour exploiter pleinement sa puissance et gérer efficacement des charges de trafic massives, une configuration correcte de ses paramètres d'utilisation des ressources essentiels – en particulier worker_processes et worker_connections – est indispensable.

Ce guide offre un aperçu complet de la manière dont Nginx utilise les processus worker et les connexions, détaillant les meilleures pratiques pour configurer ces directives afin de maximiser le débit, minimiser la latence et garantir que votre serveur Nginx fonctionne de manière optimale sous des charges de pointe. La compréhension de ces paramètres est la base d'un réglage Nginx haute performance.

Comprendre l'architecture worker de Nginx

Nginx fonctionne selon un modèle maître-worker. Le processus maître est responsable de la lecture et de la validation de la configuration, de la liaison aux ports et de la gestion des processus worker. Il effectue des tâches non critiques comme la surveillance des ressources système et le redémarrage des workers si nécessaire.

Les processus worker sont ceux qui effectuent le gros du travail. Ces processus sont à thread unique (dans une compilation Nginx standard) et utilisent des appels système non bloquants. Chaque worker gère efficacement des milliers de connexions concurrentes à l'aide d'une boucle d'événements, permettant à un processus de gérer plusieurs requêtes sans bloquer, ce qui est la clé des performances de Nginx.

Une optimisation appropriée implique d'équilibrer le nombre de workers (en les liant aux ressources CPU) et de définir le nombre maximal de connexions que chaque worker peut gérer.

Configuration de `worker_processes` : Le facteur cœur CPU

La directive worker_processes détermine le nombre de processus worker que Nginx doit générer. Ce paramètre affecte directement la façon dont Nginx utilise les ressources CPU de votre serveur.

Bonne pratique : Faire correspondre les workers aux cœurs

La meilleure pratique la plus courante et fortement recommandée est de définir le nombre de processus worker égal au nombre de cœurs CPU disponibles sur votre serveur. Cela garantit que chaque cœur est utilisé efficacement sans entraîner de surcharge excessive due au changement de contexte.

Si le nombre de workers dépasse le nombre de cœurs, le système d'exploitation doit fréquemment changer le focus du CPU entre les processus Nginx concurrents (changement de contexte), ce qui introduit de la latence et réduit les performances globales.

Utilisation de la directive `auto`

Pour les versions modernes de Nginx (1.3.8 et ultérieures), la configuration la plus simple et la plus efficace consiste à utiliser le paramètre auto. Nginx détectera automatiquement le nombre de cœurs CPU disponibles et définira les processus worker en conséquence.

# Paramètre recommandé pour la plupart des déploiements
worker_processes auto;

Configuration manuelle

Si vous avez besoin d'un contrôle manuel ou utilisez une version plus ancienne, vous pouvez spécifier le nombre exact de workers. Vous pouvez trouver le nombre de cœurs à l'aide des utilitaires système :

# Trouver le nombre de cœurs CPU
grep processor /proc/cpuinfo | wc -l

Si le système possède 8 cœurs, la configuration ressemblerait à ceci :

# Définition manuelle des processus worker à 8
worker_processes 8;

Conseil : Bien que l'alignement sur le nombre de cœurs soit standard, si votre serveur Nginx sert principalement du contenu statique (tâches liées à l'I/O), vous pourriez occasionnellement observer de légers gains de performance en définissant worker_processes à 1,5x ou 2x le nombre de cœurs. Cependant, pour le service web typique, le proxying et la terminaison SSL (tâches liées au CPU), s'en tenir au nombre de cœurs (auto) est généralement plus sûr et plus stable.

Configuration de `worker_connections` : Le facteur de concurrence

La directive worker_connections est configurée dans le bloc events et définit le nombre maximal de connexions simultanées qu'un seul processus worker peut gérer. Cela inclut les connexions aux clients, les connexions aux serveurs proxy en amont et les connexions internes de vérification de l'état de santé.

Calcul du nombre maximal de clients

Le nombre théorique maximal de connexions client concurrentes que votre serveur Nginx peut gérer est calculé comme suit :

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

Si vous avez 4 processus worker et 10 000 connexions worker par processus, Nginx pourrait théoriquement gérer 40 000 connexions simultanées.

Définition de la limite de connexion

Il est courant de définir worker_connections à une valeur élevée (par exemple, 10240, 20480 ou plus) pour gérer les pics de trafic, en supposant que les ressources de votre système (mémoire, descripteurs de fichiers) peuvent le supporter.

# Exemple de configuration pour le bloc events

events {
    # Connexions concurrentes max par processus worker
    worker_connections 16384;

    # Fortement recommandé : permet à un worker d'accepter toutes les nouvelles connexions
    # simultanément au lieu de les gérer une par une.
    multi_accept on;
}

Contrainte des limites système (`ulimit`)

De manière cruciale, le paramètre worker_connections est contraint par la limite du système d'exploitation sur le nombre de descripteurs de fichiers ouverts (FDs) autorisés par processus, souvent contrôlée par le paramètre ulimit -n.

Nginx ne peut pas ouvrir plus de connexions que ce que le système d'exploitation autorise comme descripteurs de fichiers. Puisque chaque connexion (socket client, fichier journal, socket proxy) nécessite un descripteur de fichier, il est vital que la limite du système soit suffisamment élevée.

Vérifier et augmenter les limites de descripteurs de fichiers

Vérifier la limite actuelle :

bash ulimit -n

Augmenter temporairement la limite (pour la session actuelle) :

bash ulimit -n 65536

Augmenter la limite de manière permanente (via /etc/security/limits.conf) :

Ajoutez les lignes suivantes, en remplaçant nginx_user par l'utilisateur sous lequel Nginx s'exécute (souvent www-data ou nginx) :

bash # /etc/security/limits.conf nginx_user soft nofile 65536 nginx_user hard nofile 65536

Avertissement : Assurez-vous toujours que la valeur worker_connections dans votre configuration Nginx est significativement inférieure à la limite de descripteurs de fichiers à l'échelle du système (ulimit -n). Une recommandation courante est de s'assurer que worker_connections * worker_processes est inférieur à la limite du système d'exploitation pour la sécurité, bien que Nginx n'exige que la limite par processus (ulimit -n) soit supérieure à worker_connections.

Réglage et surveillance avancés

Au-delà des directives principales, quelques considérations supplémentaires peuvent aider à affiner les performances :

1. Épinglage des processus worker (Pinning)

Dans les environnements haute performance, en particulier sur les systèmes dotés de plusieurs sockets CPU (architectures NUMA), vous pourriez vouloir utiliser la directive worker_cpu_affinity. Cela indique au système d'exploitation de restreindre des processus worker spécifiques à des CPU spécifiques, ce qui peut améliorer les performances en garantissant que les caches CPU restent « chauds » et en évitant les problèmes de localité de la mémoire.

Exemple pour un système à 8 cœurs :

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

Ce paramètre est complexe et généralement bénéfique uniquement pour les situations de charge extrêmement élevée ; worker_processes auto est suffisant pour la plupart des déploiements.

2. Surveillance des métriques de performance

Après avoir appliqué les optimisations, il est crucial de surveiller l'impact. Utilisez le module Nginx Stub Status (ou un outil comme Prometheus/Grafana) pour suivre les métriques clés :

Métrique	Description	Vérification d'optimisation
Connexions actives	Nombre total de connexions actuellement gérées.	Devrait être inférieur au maximum théorique.
Lecture/Écriture/Attente	Connexions dans différents états.	Un nombre élevé de connexions en attente indique souvent des connexions HTTP Keep-Alives de longue durée (bon) ou des ressources de traitement insuffisantes (mauvais).
Taux de requêtes	Requêtes par seconde.	Utilisé pour mesurer l'amélioration réelle des performances après les modifications de configuration.

Si vous observez une utilisation élevée du CPU sur tous les cœurs et des taux de requêtes élevés, vos worker_processes sont probablement configurés correctement. Si vous avez des cœurs CPU inactifs pendant le pic de trafic, envisagez de revoir votre configuration ou de vérifier les opérations d'E/S bloquantes en dehors de Nginx.

3. Stratégie de débordement de connexion

Si le serveur atteint la limite maximale de connexions (worker_processes * worker_connections), les nouvelles requêtes seront abandonnées. Bien qu'augmenter worker_connections aide, le combiner avec une utilisation attentive de multi_accept (comme montré ci-dessus) garantit que les workers sont toujours prêts à accepter de nouvelles connexions pendant les périodes de forte charge.

Résumé des bonnes pratiques

Directive	Valeur recommandée	Justification
`worker_processes`	`auto` (ou nombre de cœurs)	Assure une utilisation optimale du CPU et minimise la surcharge due au changement de contexte.
`worker_connections`	10240 ou plus	Maximise la concurrence par worker, permettant au serveur de gérer les pics de trafic élevés.
Limite OS (`ulimit -n`)	Significativement supérieure à `worker_connections`	Fournit les descripteurs de fichiers nécessaires pour toutes les connexions actives et les ressources internes.
`multi_accept`	`on`	Permet aux workers de vider rapidement la file d'attente des connexions lors des pics de charge.

En équilibrant soigneusement le nombre de processus worker pour correspondre aux ressources CPU et en maximisant le nombre de connexions que chaque worker peut gérer dans les limites du système, vous pouvez vous assurer que votre déploiement Nginx est optimisé pour une stabilité et des performances maximales, gérant efficacement des milliers d'utilisateurs concurrents.