Dimensionnement PHP-FPM pm.max_children sous Debian 12 / Ubuntu 24.04

L’erreur suivante dans les journaux d’erreurs PHP-FPM (/var/log/php8.3-fpm.log) est le symptôme numéro un d’un serveur web sous-dimensionné lors des pics de fréquentation :

[01-Mar-2026 14:22:10] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Lorsque cette limite est atteinte, toutes les nouvelles connexions HTTP entrantes sont mises en file d’attente (ou rejetées avec des erreurs HTTP 502 Bad Gateway et 504 Gateway Timeout). Les visiteurs attendent jusqu’à ce qu’un worker se libère, faisant s’effondrer le taux de conversion de la boutique.

Pourtant, augmenter pm.max_children aveuglément sans calcul mathématique précis expose le serveur au risque létal du Linux OOM Killer (Out Of Memory Killer), qui mettra fin brutalement au processus MySQL ou Nginx pour sauver le système d’exploitation.

---

1. Méthode Empirique de Calcul de la Mémoire par Worker

Chaque application PHP a une empreinte mémoire moyenne distincte : un site WordPress avec WooCommerce consomme généralement entre 60 Mo et 110 Mo par worker actif, tandis qu’une API Laravel ou Symfony légère tourne autour de 35 Mo.

Exécutez cette commande pour mesurer l’empreinte réelle de vos processus PHP-FPM en production :

# Calcul de la mémoire moyenne (RSS) par processus PHP-FPM en Mégaoctets
ps --no-headers -o "rss,cmd" -C php-fpm8.3 | awk '{ sum+=$1; count++ } END { if (count > 0) print "Workers actifs:", count, "| Mémoire moyenne:", (sum/count)/1024, "Mo"; else print "Aucun worker actif"; }'

Supposons une valeur moyenne constatée de 85 Mo par processus.

---

2. La Formule Mathématique d’Allocation

Pour calculer la valeur exacte de pm.max_children :

$$\text{Mémoire Allouable} = \text{RAM Totale} - (\text{OS} + \text{MySQL/MariaDB} + \text{Redis} + \text{Nginx} + \text{Marge Sécurité})$$

$$\text{pm.max_children} = \frac{\text{Mémoire Allouable}}{\text{Empreinte Moyenne Worker}}$$

Exemple Réel sur un VPS 16 Go de RAM :

• RAM Totale : 16 384 Mo
• Système Debian 12 + Daemons : 1 500 Mo
• MariaDB (innodb_buffer_pool dimensionné à 6 Go) : 6 144 Mo
• Redis Cache : 1 024 Mo
• Marge de sécurité Linux (I/O Buffers) : 1 500 Mo
• RAM disponible pour PHP-FPM = $16 384 - 10 168 = \mathbf{6 216\text{ Mo}}$

$$\text{pm.max_children} = \frac{6216}{85} \approx \mathbf{73}$$

---

3. Choix du Gestionnaire de Processus : static vs dynamic

Pour les environnements de production stables à trafic soutenu, le mode static est nettement supérieur : il évite le coût CPU récurrent de création et destruction continuelle de processus Linux (fork()).

Modifiez votre pool (/etc/php/8.3/fpm/pool.d/www.conf) :

; /etc/php/8.3/fpm/pool.d/www.conf
[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Configuration du Process Manager en mode STATIQUE
pm = static
pm.max_children = 70

; Recyclage périodique pour éliminer les fuites de mémoire lentes
pm.max_requests = 1000

; En-tête de surveillance des processus
pm.status_path = /fpm-status
ping.path = /fpm-ping

Si le serveur partage ses ressources avec d’autres services intermittents, conservez le mode dynamic :

pm = dynamic
pm.max_children = 70
pm.start_servers = 18
pm.min_spare_servers = 12
pm.max_spare_servers = 25
pm.max_requests = 1000

---

4. Réglages des Seuils d’Urgence Globaux

Dans /etc/php/8.3/fpm/php-fpm.conf, activez le mécanisme de redémarrage d’urgence automatique pour parer aux corruptions occasionnelles d’OPcache :

; /etc/php/8.3/fpm/php-fpm.conf
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10s

Testez la syntaxe et rechargez le service sans interruption :

sudo php-fpm8.3 -t
sudo systemctl reload php8.3-fpm

---

5. Surveillance en Temps Réel avec l’Endpoint de Statut

Vous pouvez surveiller la charge de vos workers en direct via l’utilitaire en ligne de commande :

# Vérifier l'utilisation du pool FPM en direct
SCRIPT_NAME=/fpm-status SCRIPT_FILENAME=/fpm-status QUERY_STRING=full cgi-fcgi -bind -connect /run/php/php8.3-fpm.sock

Le rapport indique les requêtes actives, les processus en attente et le nombre de fois où max_children reached a été déclenché. Le compteur restera désormais à 0, garantissant un écoulement parfait de votre trafic sans ralentissement applicatif.

---

🔗 Diagnostics Techniques & Maillage d’Architecture :

Les goulots d’étranglement d’infrastructure ne sont jamais isolés. La latence serveur, les requêtes SQL et le rendu DOM interagissent en continu :

• Cache d’Objets Redis Persistant pour WordPress & WooCommerce: Soulager le serveur SQL des requêtes de sessions et métadonnées répétitives.
• Correction des Sauts de Mise en Page (CLS) Colissimo & Mondial Relay: Stabiliser le rendu visuel des widgets de points relais dans le tunnel d’achat.
• Schéma JSON-LD SIREN / SIRET pour le Knowledge Graph: Ancrer l’entité légale de l’entreprise dans l’index sémantique de Google.