Planification des capacités PHP-FPM : calculer le nombre de workers, la mémoire vive et le nombre de requêtes simultanées

Ce qui limite un worker PHP-FPM

PHP-FPM gère les processus PHP par groupes. Un Travailleur traite une requête à la fois ; le paramètre du pool pm.max_children limite le nombre de workers disponibles simultanément et, par conséquent, le nombre de requêtes PHP traitées simultanément par ce pool. En cas de présence de plusieurs pools, cette limite s'applique au pool concerné et non automatiquement à l'ensemble du serveur.

Ce chiffre ne correspond ni au nombre de visiteurs connectés, ni à une valeur directe exprimant le nombre de requêtes par seconde. Un visiteur peut générer plusieurs requêtes, tandis qu’un utilisateur connecté n’occupe pas de worker entre deux actions. À l’inverse, une seule requête lente peut monopoliser un worker plus longtemps que plusieurs requêtes courtes successives.

De plus, toutes les consultations de pages ne parviennent pas à PHP-FPM. Si le serveur web fournit directement un fichier statique ou si un cache en amont répond intégralement à une requête, aucun worker PHP n'est nécessaire, selon l'architecture. En revanche, les échecs de mise en cache, les utilisateurs connectés et les pages d'administration peuvent continuer à générer des requêtes PHP et augmenter temporairement la charge.

Deux questions distinctes sont donc déterminantes pour la planification des capacités : combien de workers, réserve comprise, la mémoire vive disponible peut-elle accueillir ? Et de combien de workers le trafic effectivement arrivant dans le pool a-t-il besoin pour que les requêtes n'aient pas à attendre trop longtemps ? Une valeur élevée pour pm.max_children ne répond à aucune de ces questions à elle seule.

Même si l'espace de stockage disponible est suffisant, le processeur, la base de données ou des services externes peuvent limiter la capacité effective. L'ajout de workers supplémentaires permet certes d'augmenter le nombre de tâches PHP exécutées en parallèle, mais peut également accroître la charge sur un service déjà lent. La valeur du pool constitue donc une limite opérationnelle et non une garantie de performance.

Comprendre les gestionnaires de processus et les files d'attente

Le Responsable des processus détermine à quel moment PHP-FPM met des workers à disposition. Lorsque static le nombre de processus réservés correspond à la valeur de pm.max_children. Cela permet de bien planifier le nombre de processus, mais mobilise également des ressources, même lorsque la charge de travail est faible. La limite maximale doit quant à elle rester adaptée à l'espace de stockage disponible.

À l'adresse suivante : dynamic FPM ajuste le nombre de processus : le nombre initial ainsi que les nombres minimal et maximal de workers libres sont également définis. Dans le cas de ondemand Les workers ne sont créés qu'en cas de besoin et sont arrêtés après un délai d'inactivité configuré. Cela permet d'économiser des ressources dans le cas de pools rarement utilisés ; toutefois, en cas de pic de charge soudain, une nouvelle capacité de traitement doit d'abord être mise en place.

Si tous les workers sont occupés, les requêtes supplémentaires peuvent être placées dans la File d'attente des écouteurs attendre un processus disponible. Le statut FPM indique notamment la longueur actuelle et maximale de la file d'attente. Une valeur maximale élevée prise isolément ne permet toutefois pas de déterminer si le pool est actuellement surchargé ; pour cela, il faut la replacer dans un contexte temporel.

Une file d'attente plus longue ne crée pas de workers supplémentaires et n'accélère pas une base de données lente. Elle peut absorber temporairement les requêtes, mais ne fait que déplacer le temps d'attente avant le traitement PHP. Pour choisir le gestionnaire de processus, il est donc important de tenir compte à la fois de l'évolution typique de la charge et des conséquences des pics de trafic de courte durée.

Bien classer la mémoire des workers

Il n'est pas possible de déterminer de manière fiable les besoins en mémoire d'un worker uniquement à partir d'une limite de configuration PHP. Pour la planification, les données de processus recueillies dans des conditions de charge appropriées sont plus utiles. À cet égard, il y a une différence entre l'analyse de la mémoire résidente d'un processus individuel et l'estimation de la consommation d'un groupe entier de workers PHP-FPM.

RSS décrit la mémoire résidente d'un processus. Si plusieurs workers utilisent les mêmes pages de mémoire, celles-ci peuvent figurer dans leur RSS respectif. Si l'on additionne les valeurs RSS de tous les workers, les pages partagées peuvent donc apparaître plusieurs fois ; la somme ne donne donc pas une image précise de la mémoire physique partagée.

PSS répartit les pages partagées proportionnellement entre les processus concernés. La somme des valeurs PSS d'un groupe de processus est donc souvent plus utile pour la planification de la mémoire que la somme des valeurs RSS. Elle n'en reste pas moins un instantané : si le nombre de processus partageant ces pages change, leurs parts respectives changent également.

Examinez plusieurs workers dans le cadre de requêtes classiques, mais aussi de requêtes gourmandes en mémoire. Un processus qui vient d'être lancé ou une moyenne isolée peut sous-estimer les besoins ultérieurs. Le PSS total du pool pour différents nombres de workers et différents états de charge permet d'obtenir une estimation prudente ; une extrapolation à un plus grand nombre de workers reste incertaine en raison de la variabilité des parts communes et privées.

Le PHP-memory_limit ne constitue pas une indication fiable de la mémoire totale du système d'exploitation d'un processus FPM et ne remplace pas cette observation. Tu ne dois pas déduire systématiquement une deuxième fois de la mémoire allouée la mémoire partagée, par exemple par l'OPcache, si celle-ci est déjà prise en compte proportionnellement dans le pool PSS utilisé. Les autres services et une réserve doivent néanmoins être pris en compte.

Calculer le budget RAM et le nombre de workers

Le point de départ est la mémoire vive (RAM) réellement disponible : sur un hôte, il s'agit de la mémoire utilisable pour les services ; dans le conteneur, il s'agit de la limite de mémoire effective. Déduisez de ce montant les besoins du système d'exploitation, du serveur web, d'une éventuelle base de données locale et d'autres services. Il faut également tenir compte des autres pools FPM et d'une réserve pour les fluctuations de consommation.

La part restante correspond à Budget commun. Pour estimer la valeur du worker, observez la somme PSS des workers du pool en fonction de différents nombres de processus et de différents états de charge. Tenez compte aussi bien des requêtes typiques que des points de terminaison gourmands en mémoire. Divisez la somme correspondante par le nombre de workers considéré et déduisez une valeur approximative prudente à partir de plusieurs observations.

Le calcul suivant est un exemple illustratif et non une mesure. Les valeurs utilisées ne servent qu'à montrer le raisonnement ; elles ne constituent en aucun cas une recommandation pour une application spécifique. Le résultat est arrondi à un nombre entier de workers.

Les 25 workers ne constituent pas une garantie de sécurité. PSS répartit les pages partagées au prorata et cette répartition varie en fonction du nombre de processus qui partagent ces pages. Une composition différente des requêtes peut également modifier les besoins en mémoire privée ; l'estimation doit donc être vérifiée par rapport à la consommation totale observée et à la limite disponible.

Si la mémoire partagée, comme l'OPcache, est déjà prise en compte au prorata dans le total PSS utilisé, tu ne la déduis pas à nouveau de manière forfaitaire en tant que poste supplémentaire complet. Prévoyez néanmoins une réserve pour les parts de mémoire qui ne sont pas prises en compte dans votre analyse. En particulier dans le cas d’une limite de conteneurs, c’est finalement la consommation de tous les processus à l’intérieur de cette limite qui compte, et pas seulement la somme estimée des workers.

Un worker qui vient d'être lancé ne constitue pas à lui seul une base suffisamment significative : il se peut qu'il n'ait encore traité aucune requête complexe. Comparez donc plusieurs moments et notez quels points de terminaison et combien de workers étaient impliqués à chaque fois. Cela permet de déterminer si l’estimation choisie reste valable même dans des conditions d’exploitation moins favorables, mais réalistes.

Estimer le nombre de travailleurs nécessaires à partir des demandes

Le calcul de la mémoire vive (RAM) indique le nombre de workers que le système devrait pouvoir accueillir. En revanche, pour déterminer les besoins, il faut tenir compte du nombre réel de requêtes PHP arrivant dans le pool considéré et de la durée pendant laquelle elles mobilisent un worker. En première approximation, on peut considérer que le nombre moyen de workers occupés simultanément est égal au nombre de requêtes PHP par seconde multiplié par la durée moyenne d'occupation d'un worker en secondes.

Exemple de calcul à titre indicatif, et non une mesure : en supposant 20 requêtes PHP par seconde et un temps de traitement moyen de 0,25 seconde, cinq workers sont en moyenne occupés. Il s'agit d'une moyenne sur la période considérée. Cela ne signifie ni qu’il y a toujours exactement cinq processus en cours d’exécution, ni que cinq suffisent comme limite du pool pour les pics de charge de courte durée.

Pour le nombre de requêtes, tu ne dois pas prendre en compte toutes les pages consultées sans vérification. Lorsqu'un cache fournit de nombreuses réponses sans faire appel à PHP, ces résultats ne pèsent pas sur le pool. À l'inverse, les échecs de mise en cache, les visiteurs connectés et les accès administratifs peuvent parfois générer davantage de travail PHP que ne le laisse supposer une moyenne calculée sur l'ensemble de la journée.

Le Temps de travail des employés comprend également les temps d'attente au cours du traitement, par exemple en attendant une réponse d'une base de données ou d'un service externe. Elle ne correspond pas automatiquement au temps de réponse visible dans le navigateur. Selon fastcgi_finish_request() PHP peut avoir déjà terminé la réponse envoyée au client tout en continuant à exécuter d'autres tâches dans le worker.

Pour garantir des temps d'attente acceptables, vous devez disposer d'une marge au-delà du taux d'occupation moyen. L'ampleur de cette marge dépend notamment des fluctuations de charge, de la lenteur des points d'extrémité et de l'objectif de temps de réponse souhaité. La multiplication du nombre de requêtes de pointe par seconde par un centile de latence élevé peut constituer une vérification prudente du scénario, mais ne constitue pas une prévision précise des files d'attente.

Il convient donc d'examiner plusieurs périodes séparément : un bref pic d'activité et un trafic nocturne plus calme peuvent donner la même moyenne journalière qu'un trafic plus régulier, mais posent des exigences différentes. Si le temps de traitement augmente en raison d’un backend lent, le nombre moyen de travailleurs occupés augmente également, même si le taux d’arrivée reste identique. Les besoins ne dépendent donc pas uniquement du flux de visiteurs.

Déterminer les paramètres du pool à partir de la planification

Compare maintenant la limite maximale basée sur la RAM aux besoins estimés, en tenant compte d'une marge de manœuvre. Si les besoins sont inférieurs à cette limite, choisis une valeur de départ prudente pour pm.max_children, qui n'est pas obligé d'utiliser la totalité du budget. Dans l'exemple donné, 25 correspondrait à la limite théorique de la mémoire vive (RAM), mais pas nécessairement au réglage approprié ; le processeur et le backend peuvent déjà imposer des limites avant d'atteindre cette valeur.

Si les besoins estimés dépassent la limite de RAM, augmenter cette limite ne résoudra pas le problème : cela risque de mettre l'hôte ou le conteneur sous pression en termes de mémoire. À l’inverse, une limite trop basse peut entraîner des retards dans le traitement des requêtes. Dans ce cas, améliorez par exemple le temps d’exécution ou l’utilisation du cache, et vérifiez si des ressources supplémentaires ou une limitation de la charge entrante sont nécessaires.

À l'adresse suivante : dynamique Vous définissez, outre la limite supérieure, le nombre initial ainsi que les nombres minimum et maximum de workers disponibles. Les valeurs de démarrage et de réserve doivent être adaptées à la charge prévue et rester dans les limites fixées. Une capacité de réserve insuffisante peut entraîner un besoin supplémentaire de démarrage en cas de charge soudaine ; à l'inverse, un nombre élevé de processus libres en permanence consomme des ressources.

À l'adresse suivante : ondemand Les workers ne sont créés qu'en cas de besoin ; le délai d'inactivité jusqu'à leur fermeture est défini séparément. Cela peut s'avérer utile pour les pools rarement utilisés, mais nécessite une attention particulière en cas d'augmentation rapide de la charge. Là encore, cela limite pm.max_children le nombre de workers du pool disponibles simultanément.

Plusieurs sites web hébergés sur le même serveur ne disposent pas chacun, indépendamment les uns des autres, de la totalité de la mémoire RAM libre. Définissez leurs limites maximales de pool en tenant compte des autres services et de la réserve. Une limite globale de processus FPM, si elle est configurée, peut s'appliquer en complément, mais elle ne remplace ni les budgets individuels des pools, ni la vérification de la capacité du processeur et de la base de données.

Après chaque modification, vérifie la charge réelle et les temps d'attente sur des périodes appropriées, au lieu de considérer la valeur initiale comme définitive. Dans le cas d'un hébergement géré, les données de processus ou les paramètres de pool peuvent ne pas être directement accessibles ; dans ce cas, utilisez les métriques et les options mises à disposition par le fournisseur. Les paramètres disponibles dépendent également de la version de PHP et de l'environnement d'exploitation.

Surveiller l'état du FPM et l'espace disque

La page d'état FPM indique si les workers prévus sont suffisants compte tenu de la charge réelle. Protéger le point de terminaison d'état hors de portée du public : il peut divulguer des informations sensibles concernant les requêtes et les ressources. Un écouteur d'état configuré séparément peut rester accessible même lorsque le pool principal est saturé ; vérifie sa disponibilité et sa configuration pour ta version de PHP et la configuration de ton serveur web.

Considère ces valeurs comme séries chronologiques ainsi que le volume de requêtes et les temps de réponse. Un ancien pic de la file d’attente ne prouve pas une surcharge actuelle ; de même, pour les compteurs, leur augmentation depuis la dernière observation est plus significative que la simple valeur totale. Tenez compte à cet égard du démarrage ou des redémarrages du pool, qui modifient la période de référence.

Pour un worker FPM connu, vous pouvez récupérer en lecture les valeurs de mémoire agrégées sur un système Linux disposant d'une interface proc. Remplacez PID à l'aide de l'ID de processus réel ; tu dois disposer des droits d'accès nécessaires. Répète cette observation pour plusieurs workers et différents états de charge, plutôt que de déduire une taille de pool fixe à partir d'un seul processus.

cat /proc/PID/smaps_rollup

Analyser les requêtes lentes et les files d'attente

Une boutique en ligne peut afficher un grand nombre de workers actifs, même si l'exécution PHP elle-même n'est pas le goulot d'étranglement initial. Si des requêtes sont mises en attente en raison de requêtes de base de données lentes, les workers restent bloqués pendant ce temps. Si d'autres requêtes arrivent, la file d'attente du listener peut s'allonger et le temps de réponse augmenter, même si le processeur dispose encore de capacités inutilisées.

Dans cette situation, une limite de workers plus élevée pourrait permettre à davantage de requêtes d'atteindre simultanément la base de données. Cela peut Impression côté serveur et allonger encore les temps d'attente. Compare donc l'évolution dans le temps de l'utilisation du FPM et de la file d'attente avec la charge de la base de données, les requêtes lentes et les appels de services externes avant d'augmenter la limite.

Le « Slowlog » de FPM permet d'identifier les appels PHP longs : pour les requêtes dépassant un seuil configuré, FPM peut enregistrer une trace de retour. Celle-ci indique un point d'exécution et ne constitue pas un profil complet de l'ensemble de la requête. Les points récurrents peuvent être recoupés avec la durée de la requête et les métriques du backend ; les Guide d'analyse du slowlog de PHP-FPM est expliquée dans la suite de l'analyse.

Le délai d'expiration doit également être distingué de la capacité réelle. Sous nginx, on désigne fastcgi_read_timeout l'intervalle autorisé entre deux lectures successives effectuées par le serveur FastCGI, et non pas la durée totale de la requête. Une valeur plus élevée peut permettre un temps d'attente plus long, mais elle ne crée pas de workers supplémentaires et n'accélère pas non plus la base de données.

Limites de capacité et prochaines étapes

Si le budget de mémoire vive n'est pas suffisant pour couvrir les besoins estimés, un réglage plus élevé pour pm.max_children ne pas créer de conflit d'objectifs : les processus supplémentaires nécessitent eux aussi de la mémoire. Vérifie plutôt s'il est possible de réduire le nombre de requêtes PHP ou la durée d'occupation de leurs workers. La mesure à prendre dépend de l'origine de la charge observée.

Une mémoire cache mieux exploitée peut prendre en charge les requêtes répétitives, tandis qu’une exécution PHP plus rapide et des accès plus rapides à la base de données libèrent plus tôt les workers. Les tâches d’arrière-plan appropriées peuvent être déchargées du chemin de requête immédiat ; toutefois, ces tâches nécessitent elles aussi leurs propres ressources. Une limitation de charge protège le backend en cas de pics, mais peut entraîner la mise en attente ou le rejet de requêtes.

Une mémoire vive supplémentaire peut permettre d'augmenter le nombre de workers si la mémoire constitue effectivement la limite déterminante. Si le processeur, la base de données ou un service externe sont déjà saturés, leur capacité doit également être prise en compte. À elle seule, une mémoire vive plus importante ne garantit donc ni des temps de réponse plus courts, ni un débit plus élevé.

Si les besoins en mémoire de certains workers augmentent au cours de leur cycle de vie, il est possible de pm.max_requests veiller à leur remplacement régulier. Cela peut aider à gérer les fuites de mémoire dans les bibliothèques tierces, mais ne résout pas leur cause. Après une modification, continuez à surveiller la mémoire du pool et le comportement des requêtes, au lieu de considérer le mécanisme de redémarrage comme un substitut au dépannage.

Pour une décision architecturale plus globale, le Comparaison entre NGINX Unit et PHP-FPM Contexte : NGINX Unit est archivé et n'est plus mis à jour. Quelle que soit l'architecture choisie, tu devrais apporter les modifications en te basant sur séries chronologiques Vérifier : pour un volume de requêtes similaire, comparez la file d'attente, la charge des workers, la mémoire et les temps de réponse. Cela permet de déterminer si un ajustement a réellement résolu le goulot d'étranglement ou s'il l'a simplement déplacé.