Configuration PHP-FPM : utilisez pm static pour des performances maximales

Une version non éditée de cet article a été initialement publiée sur haydenjames.io et publié ici avec sa permission l'auteur.

Je vais vous expliquer en un mot comment configurer au mieux PHP-FPM pour augmenter le débit, réduire la latence et utiliser le processeur et la mémoire de manière plus cohérente. Par défaut, la ligne PM (gestionnaire de processus) dans PHP-FPM est Dynamic, et si vous n'avez pas assez de mémoire, alors il vaut mieux installer à la demande. Comparons 2 options de contrôle basées sur la documentation php.net et voyons en quoi ma préférée en diffère statique pm pour un trafic important :

pm = dynamique — le nombre de processus enfants est configuré dynamiquement en fonction des directives suivantes : pm.max_children, pm.start_servers,pm.min_spare_servers, pm.max_spare_servers.
pm = sur demande - les processus sont créés à la demande (par opposition à la création dynamique, lorsque pm.start_servers est lancé au démarrage du service).
pm = statique — le nombre de processus enfants est fixe et est indiqué par le paramètre pm.max_enfants.

Pour plus de détails, voir liste complète des directives globales php-fpm.conf.

Similitudes entre le gestionnaire de processus PHP-FPM et le contrôleur de fréquence CPU

Cela peut sembler hors sujet, mais je vais lier cela au sujet de la configuration PHP-FPM. Qui n’a pas connu au moins une fois un ralentissement du processeur – sur un ordinateur portable, une machine virtuelle ou un serveur dédié ? Vous vous souvenez de la mise à l'échelle de la fréquence du processeur ? Ces options sont disponibles pour nix et Windows peuvent améliorer les performances et la réactivité du système en modifiant le paramètre de limitation du processeur de à la demande sur performance*. Cette fois, comparons les descriptions et regardons les similitudes :

gouverneur = sur demande — mise à l'échelle dynamique de la fréquence du processeur en fonction de la charge actuelle. Passe rapidement à la fréquence maximale, puis la réduit à mesure que les périodes d'inactivité augmentent.
gouverneur=conservateur= mise à l'échelle dynamique de la fréquence en fonction de la charge actuelle. Augmente et diminue la fréquence plus facilement qu'à la demande.
Gouverneur = performance — la fréquence est toujours maximale.

Pour plus de détails, voir liste complète des paramètres du régulateur de fréquence du processeur.

Vous voyez les similitudes ? Je voulais montrer cette comparaison pour vous convaincre qu'il est préférable d'utiliser pm statique pour PHP-FPM.

Pour le paramètre régulateur du processeur performant permet d'augmenter les performances en toute sécurité car cela dépend presque entièrement de la limite du processeur du serveur. En plus de cela, bien sûr, il existe également des facteurs tels que la température, la charge de la batterie (dans un ordinateur portable) et d'autres effets secondaires liés au fonctionnement constant du processeur à 100 %. Le paramètre de performances garantit les performances du processeur les plus rapides. Lisez par exemple sur paramètre force_turbo dans Raspberry Pi, avec lequel le panneau RPi utilisera le régulateur performant, où l'amélioration des performances sera plus visible en raison de la faible vitesse d'horloge du processeur.

Utiliser pm static pour obtenir des performances maximales du serveur

Option PHP-FPM pm statique dépend en grande partie de la mémoire libre sur le serveur. Si la mémoire est faible, il vaut mieux choisir à la demande ou Dynamic. D'un autre côté, si vous avez de la mémoire, vous pouvez éviter la surcharge du gestionnaire de processus PHP en définissant pm statique à la capacité maximale du serveur. Autrement dit, si tout est bien calculé, il faut établir pm.statique au volume maximum de processus PHP-FPM exécutables, sans créer de problèmes de mémoire ou de cache faible. Mais pas au point de submerger les processeurs et d'accumuler un tas d'opérations PHP-FPM en attente d'exécution..

Dans la capture d'écran ci-dessus, le serveur a pm = statique et pm.max_children = 100, et cela occupe environ 10 Go sur les 32 disponibles. Faites attention aux colonnes en surbrillance, tout est clair ici. Dans cette capture d'écran, il y avait environ 200 utilisateurs actifs (plus de 60 secondes) dans Google Analytics. À ce niveau, environ 70 % des processus enfants PHP-FPM sont encore inactifs. Cela signifie que PHP-FPM est toujours défini sur la quantité maximale de ressources du serveur, quel que soit le trafic actuel. Un processus inactif attend les pics de trafic et répond instantanément. Vous n'avez pas besoin d'attendre pm créera des processus enfants, puis les terminera à l'expiration de la période pm.process_idle_timeout. J'ai mis la valeur à très haut pm.max_requestscar il s'agit d'un serveur fonctionnel sans fuite de mémoire en PHP. Vous pouvez installer pm.max_requests = 0 avec static si vous avez totalement confiance dans les scripts PHP existants et futurs. Mais il vaut mieux réexécuter les scripts au fil du temps. Définissez un grand nombre de demandes, car nous voulons éviter des coûts inutiles en MP. Par exemple, au moins pm.max_requests = 1000 - selon la quantité pm.max_enfants et le nombre de requêtes par seconde.

La capture d'écran montre la commande Linux haut, filtré par u (utilisateur) et nom d'utilisateur PHP-FPM. Seuls les 50 premiers processus environ sont affichés (je n'ai pas compté exactement), mais essentiellement top affiche les principales statistiques qui tiennent dans la fenêtre du terminal. Dans ce cas, trié par% CPU. Pour voir les 100 processus PHP-FPM, exécutez la commande :

top -bn1 | grep php-fpm

Quand utiliser pm ondemand et dynamique

Si tu utilises MP Dynamic, des erreurs comme celle-ci se produisent :

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Essayez de changer le paramètre, l'erreur ne disparaîtra pas, comme décrit dans cet article sur Serverfault. Dans ce cas, la valeur pm.min était trop petite et, comme le trafic Web varie énormément et présente des pics élevés et des vallées profondes, il est difficile d'ajuster correctement pm.min. Dynamic. Habituellement, pm est utilisé à la demande, comme conseillé dans le même post. Mais c'est encore pire, car à la demande met fin aux processus inactifs à zéro lorsqu'il y a peu ou pas de trafic, et vous vous retrouverez toujours avec la surcharge liée à la modification du trafic. À moins, bien sûr, que vous fixiez un temps d’attente énorme. Et puis il vaut mieux utiliser pm.statique + nombre élevé pm.max_requests.

PM Dynamic et surtout à la demande peut être utile si vous disposez de plusieurs pools PHP-FPM. Par exemple, vous hébergez plusieurs comptes cPanel ou plusieurs sites Web dans différents pools. J'ai un serveur avec, disons, plus de 100 comptes cPanel et environ 200 domaines, et pm.static ou même dynamique ne me sauverait pas. Tout ce dont vous avez besoin ici est à la demande, après tout, plus des deux tiers des sites Web reçoivent peu ou pas de trafic, et avec à la demande tous les processus enfants tomberont, ce qui nous fera économiser beaucoup de mémoire ! Heureusement, les développeurs de cPanel l'ont remarqué et ont défini la valeur par défaut. à la demande. Auparavant, lorsque la valeur par défaut était Dynamic, PHP-FPM ne convenait pas du tout aux serveurs partagés très occupés. Beaucoup ont utilisé supPHP, parce que pm Dynamic mémoire consommée même avec des pools inactifs et des comptes cPanel PHP-FPM. Très probablement, si le trafic est bon, vous ne serez pas hébergé sur un serveur avec un grand nombre de pools PHP-FPM (hébergement mutualisé).

Conclusion

Si vous utilisez PHP-FPM et que votre trafic est important, les gestionnaires de processus à la demande и Dynamic pour PHP-FPM, le débit sera limité en raison de leur surcharge inhérente. Comprenez votre système et configurez les processus PHP-FPM en fonction de la capacité maximale du serveur. Premier set pm.max_enfants en fonction de l'utilisation maximale en pm Dynamic ou à la demande, puis augmentez cette valeur jusqu'à un niveau où la mémoire et le processeur fonctionneront sans être surchargés. Vous remarquerez qu'avec pm statique, puisque vous avez tout en mémoire, les pics de trafic entraîneront moins de pics de processeur au fil du temps, et les moyennes de charge du serveur et du processeur se stabiliseront. La taille moyenne du processus PHP-FPM dépend du serveur Web et nécessite une configuration manuelle. Il existe donc davantage de gestionnaires de processus automatisés. Dynamic и à la demande - plus populaire. J'espère que l'article a été utile.

UPD Graphique de référence ajouté ab. Si les processus PHP-FPM sont en mémoire, les performances augmentent au détriment de la consommation de mémoire là où ils attendent. Trouvez la meilleure option pour vous-même.

Source: habr.com