web-dev-qa-db-fra.com

bien comprendre pm.max_children tuning

J'ai fait quelques recherches et je l'ai trouvé pour calculer et ajuster pm.max_children value

https://myshell.co.uk/blog/2012/07/adjusting-child-processes-for-php-fpm-nginx/

mais par exemple:

  • J'ai 8 Go sur mon serveur
  • J'héberge 30 sites Web
  • php-fpm taille moyenne du processus d'environ 40 Mo
  • php-fpm taille maximale du processus d'environ 80 Mo
  • Je veux allouer 5 Go max de ma mémoire aux processus php-fpm

Si j'applique ceci:

pm.max_children = Total RAM dédiée au serveur Web/Taille maximale du processus enfant

Donc dans mon cas:

pm.max_children = 5120/80 = 64

Mais si j'ajoute pm.max_children = 64 sur chaque fichier de configuration de site Web php-fpm, cela signifie que chaque site Web peut utiliser 64 processus enfants X taille de 1 processus (ex 40mb) = 2560 Mo

Et si nous imaginons, en même temps, que les 30 sites Web ont tous atteint la valeur pm.max_children, nous aurons: 2560 Mo (max par site Web) x 30 sites Web = 76 800 Mb

Ai-je raison?

Si oui, cela signifie que lorsque de nombreux sites Web sont hébergés sur le même serveur, nous devons diviser le résultat du calcul pm.max_children = 5120/80 = 64 par le nombre de sites Web hébergés (ici 30).

Donc 64/30 = 2,1 et pm.max_children = 2 par site Web

Est-ce correct ou pas?

Merci

nginxweb-servermemoryphp-fpmphp7
5
TooNetCreation

Votre calcul est correct d'après ce que je comprends.

Avoir plusieurs sites Web sur le même serveur ne fonctionne que tant que tous les sites Web n'utilisent pas toutes les ressources disponibles en même temps. C'est ce que les gens appellent généralement le surprovisionnement.

Cependant, je suggère de ne pas simplement calculer pm.max_children autour de la RAM disponible, mais du nombre de travailleurs réellement nécessaires au bon fonctionnement des sites Web. Commencez par quelque chose de plus bas et surveillez le php-fpm.log. Si la max_children le paramètre est atteint, vous le trouverez dans le journal et vous pouvez l'augmenter.

Assurez-vous également que les travailleurs PHP ne vivent que le temps nécessaire. Par exemple, la configuration suivante permettra à un pool d'utiliser jusqu'à 32 PHP travailleurs si il y a une rafale de demandes, mais chaque travailleur quitte après 3 secondes d'inactivité et libère de la précieuse RAM:

pm = ondemand
pm.max_children = 32
pm.process_idle_timeout = 3s

Utilisez le gestionnaire de processus ondemand si vous manquez de RAM. Il est un peu plus lent que le dynamic pm, mais ne gaspille pas RAM pour les sites Web inactifs).

Si vous souhaitez contrôler le nombre total de processus PHP, il existe un paramètre appelé process.max dans php-fpm.conf. Je ne l'ai jamais utilisé, mais il me semble que vous pouvez l'utiliser pour vous assurer qu'il n'y a jamais plus d'un certain nombre de travailleurs, quelle que soit la configuration des pools.

Soit dit en passant, c'est une très bonne idée d'utiliser des pools distincts pour des sites Web distincts appartenant à des utilisateurs distincts. De cette façon, vous n'aurez aucun problème avec les autorisations utilisateur ou avec les données mises en cache à partir d'autres sites Web.

5
Oliver

Je ne peux que vous conseiller sur la base de nos expériences.

Nous n'avons qu'un seul pool PHP-FPM en cours d'exécution pour partager les ressources (CPU et RAM).

Plusieurs pools permettent différents comptes d'utilisateurs (par exemple www-data1, www-data2 ...) et peuvent aider à restreindre l'accès. De plus, vous pouvez attribuer différentes valeurs pour le CPU et RAM consommation si nécessaire).

Cependant, l'exemple suivant utilise un seul pool:

; www.conf
;
; set pool management to have a fixed number of php workers
pm = static
; number of php processes (6 processes per CPU core)
pm.max_children = 48

Je recommande d'utiliser la gestion statique du pool. Cela signifie qu'il y a toujours un nombre fixe de travailleurs PHP.

; www.conf
;
; redirect worker stdout and stderr into main error log
catch_workers_output = yes

Cela peut être utile si votre application rencontre des erreurs.

; php-fpm.conf
;
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10s

Ceci est une surveillance de base de la vie de vos employés en cours d'exécution PHP.

N'oubliez pas de redémarrer votre service PHP-FPM après ces modifications.

1
Jens Bradler