TechPro
Nos Services

Comment configurer PHP-FPM pour maximiser les performances ?

PHP-FPM : Comment configurer les modes dynamic, static ou ondemand pour maximiser les performances ?

Gestionnaires de processus PHP-FPM : « à la demande », « dynamique » et « statique »Le choix et la configuration du gestionnaire de processus (process manager ou pm) dans votre pool PHP-FPM déterminent la réactivité de vos applications PHP sous forte charge.

Comparatif des 3 modes PHP-FPM

Mode Fonctionnement Cas d’usage idéal Avantages / Inconvénients
static Un nombre fixe de processus (pm.max_children) est lancé au démarrage et reste en mémoire. Serveurs dédiés de production avec un trafic stable et important. Le plus performant (zéro latence de création de processus) mais consomme de la RAM en continu.
dynamic Ajuste le nombre de processus de manière dynamique entre une valeur minimale et maximale. Hébergement mutualisé ou serveurs aux ressources modérées. Équilibré, mais la création/destruction de processus à la volée induit un léger overhead CPU.
ondemand Aucun processus n’est lancé par défaut. Ils sont créés uniquement lorsqu’une requête arrive. Serveurs de dev, petits sites, ou serveurs hébergeant des dizaines de petits pools isolés. Économie maximale de RAM, mais latence perceptible (le temps de spawner le process) sur la première requête.

Comment calculer vos limites de processus (pm.max_children) ?

La mauvaise configuration de cette directive provoque l’erreur classique : [Server deadlocks / Gateway Timeout].

  1. Calculez la mémoire RAM moyenne consommée par un seul de vos processus PHP. Exécutez :

    Bash

    ps -o rss -C php-fpm | tail -n +2 | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'

    (Disons que le résultat est de 50 MB par processus).

  2. Déterminez la RAM maximale que vous souhaitez allouer à PHP-FPM (ex: laissez au moins 1-2 GB pour le système, MySQL et Nginx). Sur un serveur de 8 GB, vous décidez d’allouer 5 GB à PHP.

  3. Calculez pm.max_children : $5000 \text{ MB} / 50 \text{ MB} = 100$.

Exemple de configuration optimale (static pour production)

Modifiez le fichier de configuration de votre pool (ex: /etc/php/8.x/fpm/pool.d/www.conf) :

Ini, TOML

pm = static
pm.max_children = 100
pm.max_requests = 1000 # Évite les fuites de mémoire en recyclant les processus après 1000 requêtes

3. Comment analyser les logs système (journald, syslog, dmesg) pour identifier une panne matérielle ou système imminente ?

Attendre que votre serveur s’éteigne pour agir est une erreur critique. Le noyau Linux et le système d’exploitation envoient des signaux d’alerte bien avant la panne finale. Voici comment les traquer.

dmesg : Le journal du noyau (Kernel)

dmesg affiche les messages du tampon circulaire du noyau. C’est l’outil numéro un pour repérer les défaillances physiques directes.

  • Vérifier les erreurs d’écriture disque / SATA :

    Bash

    dmesg | grep -Ei "ata|scsi|sd|sector|ext4|io error"

    Signe d’alerte : Des erreurs de type I/O error ou Buffer I/O error on dev sda indiquent que votre disque dur ou SSD est en train de rendre l’âme.

  • Traquer l’instabilité de la mémoire RAM :

    Bash

    dmesg | grep -i "MCE"

    Signe d’alerte : Les erreurs MCE (Machine Check Exception) sont générées directement par le processeur lorsqu’il détecte une défaillance matérielle (souvent un problème de RAM ECC ou de surchauffe CPU).

journald et syslog : Les journaux du système

Avec systemd, journalctl centralise la majorité des logs.

  • Lister uniquement les erreurs graves et critiques depuis le dernier démarrage :

    Bash

    journalctl -p 0..3 -b

    (Le paramètre -p 0..3 cible les niveaux Emergency, Alert, Critical et Error).

  • Surveiller les kills par manque de mémoire (Out of Memory) :

    Si votre serveur s’arrête de répondre de façon aléatoire ou si vos services (comme MySQL) coupent tout seuls :

    Bash

    journalctl -ke | grep -i "oom-killer"

    L’OOM-Killer intervient pour tuer les processus gourmands lorsque la RAM est totalement saturée.

Share: