Le retour d'expérience de Cloudflare sur son cache DNS rappelle l'intérêt de mesurer la mémoire réellement occupée. Pour WordPress, une décision concrète consiste à limiter le nombre de processus PHP-FPM : trop de concurrence peut épuiser le VPS.
1. Mesurer les travailleurs du bon pool
Ce guide utilise Ubuntu 24.04, PHP 8.3 et le pool www. Adaptez chemins et service si votre version diffère. Dans PHP-FPM, pm.max_children limite les requêtes simultanément traitées par le pool ; ce n'est pas le nombre de visiteurs autorisés.
Avant toute modification, sauvegardez le fichier :
sudo cp /etc/php/8.3/fpm/pool.d/www.conf \ /root/www.conf.before-sizingfree -mps -eo rss=,args= | \ awk '/php-fpm: pool www/ && !/awk/ {print $1}' \ | sort -nLes nombres issus de ps sont des Kio de RSS. Divisez-les par 1024 pour obtenir des Mio. Faites plusieurs relevés pendant des parcours représentatifs : pages non cachées, administration, panier si votre site en possède un.
Ne dimensionnez pas avec les seuls processus au repos. Le RSS compte aussi de la mémoire partagée : sa somme peut surestimer le total, mais donne une première estimation prudente. Une mesure PSS peut affiner le calcul. N'utilisez pas memory_limit comme si c'était la consommation complète d'un travailleur.
2. Construire un budget avec une marge
Réservez d'abord de la RAM pour le système, MariaDB, Nginx, les caches partagés, les autres services et leurs pointes. S'il existe plusieurs pools, ils doivent se partager le même budget, pas chacun toute la mémoire du VPS.
Exemple illustratif, à remplacer par vos mesures :
| Poste | Budget |
|---|---|
| RAM totale | 4096 Mio |
| Réserve hors travailleurs PHP | 2048 Mio |
| Budget restant pour les travailleurs | 2048 Mio |
| RSS de dimensionnement par travailleur | 160 Mio |
Le plafond arithmétique est floor(2048 / 160) = 12. Commencer à 10 laisse 448 Mio de marge dans ce budget. Ce résultat n'est ni une mesure de votre site ni une garantie contre les pointes.
Ouvrez le pool et remplacez les directives correspondantes, sans les dupliquer :
sudoedit /etc/php/8.3/fpm/pool.d/www.confpm = dynamicpm.max_children = 10pm.start_servers = 2pm.min_spare_servers = 2pm.max_spare_servers = 4Ces valeurs forment un exemple cohérent avec le calcul. Si vos mesures imposent un autre plafond, adaptez aussi les valeurs de démarrage et de réserve.
3. Valider sous charge puis ajuster
sudo php-fpm8.3 -tsudo systemctl reload php8.3-fpmsudo journalctl -u php8.3-fpm \ --since "15 minutes ago" --no-pagersudo tail -n 50 /var/log/php8.3-fpm.logfree -mvmstat 1 10Rechargez seulement si le test réussit. Rejouez les parcours mesurés et comparez temps de réponse, erreurs, mémoire disponible et activité swap. Consultez les deux destinations de journaux : leur usage dépend de la configuration.
Erreurs courantes : augmenter le plafond dès qu'un message max_children apparaît, oublier MariaDB ou mesurer uniquement des pages servies par le cache. Une saturation du pool peut traduire des requêtes lentes : cherchez leur cause avant d'ajouter des processus. La RAM n'est pas le seul plafond ; CPU et base peuvent saturer avant elle.
Validez après plusieurs pointes représentatives, avec des opérations WordPress réussies et une marge mémoire conservée. En cas de régression, restaurez le fichier sauvegardé, testez sa syntaxe et rechargez le service.
Sources : Cloudflare, PHP, configuration FPM.