Nginx + php-fpm - Chaque processus php-fpm 70-100% cpu lors de l'exécution

J'ai une situation dans laquelle se produit ce qui suit:

• Nous sommes sur linode avec 8 cœurs, 8 Go de RAM, 2,6 GHz - en utilisant nginx + php-fpm - nous obtenons des graphiques extrêmement élevés d'utilisation du processeur (que nous ne voulons pas être un si mauvais voisin VPS) ...

• Nous avons environ moins de 100 utilisateurs sur le site à la fois - donc cette situation est également incroyablement embarrassante - que notre utilisation du processeur est très élevée.

• Nous utilisons un Framework très inconnu, peut-être intensif en php, douteusement horrible au lieu d'autres frameworks bien connus, bien documentés et bien conçus comme wordpress ou drupal dans lesquels il y a BEAUCOUP de documentation sur la mise en cache (ainsi que des plugins) qui gèrent la mise en cache) php sur une plateforme nginx + php_fpm.

• Ainsi, nous avons environ 6 processus php-fpm ouverts qui, en RUNNING, consomment individuellement de GRANDES quantités (30+ et souvent près de 99%) de cpu - et je n'ai pas vraiment la moindre idée de comment les empêcher d'utiliser autant de cpu . Je ne peux pas dire quels scripts php sont à l'origine de ces pics car ils se produisent tout le temps ... généralement seulement 1 ou 2 sont en cours d'exécution - mais lorsque tous les 6 s'exécutent, nous maximisons les 8 cpus.

• Mon fichier pool.d / www.conf a les paramètres suivants:

  pm = dynamic
  pm.max_children = 10
  pm.start_servers = 4
  pm.min_spare_servers = 2
  pm.max_spare_servers = 6
  

• Nous avons fait cette ^ configuration parce que, dans la façon dont je l'interprète, notre mémoire est en fait incroyable (htop montrant 472/7000 + mb utilisés, pas de swapping, etc.) et nous pourrions gérer beaucoup plus de processus et couper la ligne en attendant d'obtenir traité - MAIS malheureusement, puisque chaque processus est trop intense sur notre processeur lors de l'exécution - nous finissons par conduire notre CPU à travers le toit - donc nous ne pouvons pas gérer suffisamment de processus.

• La question - que diable pouvons-nous faire pour réduire l'utilisation du processeur php-fpm pour que nous puissions augmenter les paramètres dans ce fichier de conf de pool pour php-fpm - et aussi oui, le /var/log/php5-fpm.log nous crie dessus pour augmenter nos enfants et ajuster / augmenter nos serveurs min / max / start. Mais cela rend notre moyenne de charge folle, comme indiqué précédemment. Comment pouvons-nous le faire sans nécessairement utiliser un cache ou quelles sont nos options?

• Mon idée? J'ai lu des choses sur l'utilisation de cpulimit pour garantir qu'aucun processus ne prend plus qu'une quantité allouée de cpu - mais cela ralentira-t-il pour être inutilisable? Ou, ce faisant, nous pourrions augmenter notre capacité à exécuter plusieurs processus - je pensais également exécuter deux pools - un pour notre site Web orienté vers l'avant (ce que les clients ressentent) et un autre pour un backend (qui affecte notre site orienté vers l'avant lorsque le temps -des rapports de consommation sont en cours d'exécution).

• J'ai passé quelques jours à faire des recherches, à googler, etc. sur ce sujet - et c'est difficile parce que la situation de chacun est si unique à son système - le problème réside dans un cadre aussi inouï, peut-être mal écrit - difficile de trouver une solution. Nous ne pouvons pas simplement supprimer ce cadre pour l'instant non plus - je dois trouver une solution quelconque.

MISE À JOUR: J'ai implémenté memcache pour stocker les sessions php - parce que le cadre repose fortement sur les sessions utilisateur et la nature de notre système est que les employés utilisent souvent plusieurs onglets à la fois - chacun revenant aux sessions pour confirmer les capacités / données utilisateur / etc. ... j'espère donc voir une augmentation des performances de cela - bienvenue à commenter cela si vous le souhaitez - je verrai comment cela se passera demain lorsque nous traverserons nos heures de pointe de volume plus élevé.

Quelques points à considérer (excuses à l'avance si vous les avez déjà considérées): Tout d'abord, assurez-vous d'optimiser votre configuration nginx et d'appeler php-fpm uniquement lorsque cela est absolument nécessaire. La dernière chose que vous voulez faire est de laisser php gérer des choses comme les pages HTML statiques (ce qu'il fera avec plaisir).

Deuxièmement, puisque vous utilisez php-fpm, je suggère d'être plus agressif avec la durée de vie des enfants de php-fpm. Vous devez trouver le juste milieu entre les fils / enfants de courte durée et la stabilité. Les valeurs par défaut de php-fpm sont bien trop généreuses pour tout système de production, à mon humble avis. Plus un travailleur est autorisé à répondre aux demandes, plus il sera instable. Il y a également un risque plus élevé de fuites de mémoire, et si ce cadre auquel vous faites référence a des bogues comme des boucles infinies, ce qui peut vous causer des ennuis avec la charge du processeur, cela ne devrait pas faire de mal.

Je réduirais le nombre pm.max_requestsde vos pools de production. Je pense que la valeur par défaut est 200. Je commencerais à partir de 50 et verrais où cela vous mène.

A défaut / complémentaire à cela, vous pouvez également essayer ces options globales (AFAIK elles sont toutes désactivées par défaut):

emergency_restart_threshold 3
emergency_restart_interval 1m
process_control_timeout 5s

Qu'est-ce que ça veut dire? Si 3 processus enfants PHP-FPM se terminent avec SIGSEGV ou SIGBUS (c'est-à-dire un crash) en 1 minute, alors PHP-FPM est censé redémarrer automatiquement. Le processus enfant attend 5 secondes une réaction sur les signaux du maître.

Voici un bon aperçu de toutes les options de configuration que j'ai mentionnées ici, ainsi que d'autres: http://myjeeva.com/php-fpm-configuration-101.html

J'espère que ces conseils vous aideront! N'oubliez pas de modifier et d'observer, malheureusement, il ne semble pas y avoir de règle générale pour tout cela, comme vous l'avez observé, il y a trop de variables qui affectent le comportement et la stabilité de PHP.

Enfin, la fonctionnalité de limitation du processeur que vous avez demandée est documentée ici , mais je n'y recourrais que si vous épuisez toutes les autres options. Si vous choisissez ce chemin, je ferais certainement attention aux interactions possibles entre les ajustements PHP-FPM et votre configuration limits.conf. À ce stade, etckeeper peut être une bouée de sauvetage! :)

Bonne chance!

Rouben

Vous exécutez la mise en cache d'opcode, non?

C'était APC qui était le go-to ici, mais cela a été un buggy pendant un bon moment, et a été remplacé par Zend Opcache , qui fait maintenant partie de PHP depuis 5.5, et a un backport en PECL pour 5.3 et 5.4.