Dimensionner PHP-FPM dans WHM MultiPHP Manager sans saturer le serveur

Un domaine peut produire des erreurs 503 alors que le serveur semble peu chargé : son pool PHP est peut-être plein, arrêté ou inaccessible. La documentation MultiPHP Manager distingue les réglages globaux des réglages par domaine ; cette séparation permet d’intervenir sur un site pilote avant de toucher tous les clients.

Intention de recherche : dimensionner PHP-FPM sur un serveur cPanel/WHM Apache, avec un budget mémoire partagé entre comptes. Avec LiteSpeed actif, le gestionnaire PHP est lsphp : ce guide n’est pas une procédure de réglage LSAPI.

1. Mesurer le pool et préparer son budget

Diagnostic avant correction

Dans WHM, Software, MultiPHP Manager, User Domain Settings, relevez version PHP, état PHP-FPM et options du domaine. Un pool regroupe des workers affectés à un site ; Max Children, soit pm.max_children, plafonne leur nombre. Il ne limite pas à lui seul la mémoire totale du serveur.

Sur le serveur, remplacez account par le compte réel :

RSS est exprimé en KiB ; divisez par 1024 pour obtenir des MiB. Échantillonnez les workers actifs pendant plusieurs requêtes lourdes, pas seulement au repos. Le RSS inclut des pages partagées : sa somme est une estimation prudente, pas une mesure exacte de mémoire privée.

Consultez le journal FPM de la version, par exemple /opt/cpanel/ea-php83/root/usr/var/log/php-fpm/error.log, et les erreurs du domaine sous /home/cpuser/logs/. Cherchez limite atteinte, crash, erreur de socket ou manque de mémoire. Un 504 peut provenir d’un proxy ou d’une dépendance lente ; son code seul ne justifie pas une hausse du timeout.

Sauvegarde et calcul

Notez les valeurs WHM et sauvegardez les métadonnées du compte avant modification :

La configuration du domaine se trouve dans /var/cpanel/userdata/cpuser/example.com.php-fpm.yaml. Les valeurs globales peuvent provenir de /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml : conservez ce fichier s’il existe et si vous envisagez une modification globale. Préférez ici l’interface.

Réservez d’abord de la RAM au système, à MySQL, Apache, aux autres services et aux pointes. Exemple hypothétique : un budget de 1 200 MiB pour un pool et 100 MiB par worker donnent un plafond théorique de 12 workers. Commencer à 8 laisse une marge ; ce n’est pas un réglage universel. Additionnez les budgets de tous les pools et versions actives, puis vérifiez que CPU et base acceptent la concurrence.

2. Régler progressivement dans WHM

1. Installez via EasyApache 4 une version PHP maintenue avec les extensions requises. Affectez explicitement cette version au domaine pilote dans MultiPHP Manager ; le mode Inherit ne permet pas ce réglage FPM.
2. Activez PHP-FPM pour ce domaine, puis ouvrez PHP-FPM Settings. Ajustez Max Children à votre point de départ, utilisez Validate Settings, puis Update. Conservez Max Requests et Process Idle Timeout au départ pour isoler l’effet.
3. Dans MultiPHP INI Editor, vérifiez memory_limit et les limites d’exécution utiles à l’application. memory_limit n’est ni une réservation de RAM ni la mesure complète d’un worker. Augmenter simultanément cette limite et Max Children multiplie le risque.
4. Vérifiez OPcache pour la version et le contexte Web utilisés. Une commande CLI ne prouve pas les valeurs du pool Web. Contrôlez via un diagnostic applicatif réservé aux administrateurs, puis retirez-le ; ne laissez pas un phpinfo public. OPcache réduit les compilations répétées mais ne corrige ni verrou SQL ni appel externe bloqué.
5. Rejouez une charge représentative et augmentez par petits paliers seulement si une file PHP demeure, sans pression mémoire ni dégradation SQL.

Retour arrière

Si erreurs ou swap augmentent, remettez les valeurs relevées dans WHM et validez. Si un changement de version casse le site, réaffectez la version précédente encore disponible. Ne restaurez pas aveuglément un répertoire complet : la copie sert à retrouver les valeurs et comparer les fichiers gérés.

3. Vérification finale

Comparez latence, erreurs 503/504, mémoire disponible et messages FPM avant/après, puis contrôlez les autres domaines. Testez une opération coûteuse et le prochain cron du site.

Erreurs courantes

Éditer uniquement un fichier FPM généré peut perdre le changement lors d’une reconstruction. Copier une valeur globale sur tous les comptes oublie leur consommation cumulée. Allonger les timeouts peut simplement immobiliser les workers plus longtemps.

Recommandations en production

Documentez un budget par domaine, une réserve commune et un seuil de rollback. Réévaluez après changement de plugin ou de version PHP. N’exposez pas les pages de statut FPM à Internet.

Sources : cPanel, MultiPHP Manager, réglages par domaine, configuration PHP-FPM.