Il faut constamment recharger PHP-FPM

Nous avons un serveur assez chargé exécutant nginx et PHP-FPM. Nous avons 6 sites Web sur ce serveur, exécutant PHP-FPM et nginx. Le logiciel est tout vBulletin 3.8 et WordPress. Les bases de données se trouvent sur un serveur distinct.

Maintenant, comme ce sont des sites Web très populaires, nous avons normalement 7 à 8 000 visiteurs en ligne en même temps, chaque page atteignant la base de données pour la plupart. Je crois que c'est la cause de nos problèmes.

Parce que nous avons tellement de grandes bases de données sur le serveur MySQL, et parce que les requêtes pourraient, en toute honnêteté, être bien meilleures dans le logiciel, je pense que MySQL échouera parfois à renvoyer les résultats à PHP en temps opportun, créant un effet de cascade qui finira par fait que tout s'arrête jusqu'à ce que nous rechargions PHP-FPM. Après cela, les choses recommencent à bien fonctionner.

La raison pour laquelle j'ai des problèmes à résoudre ce problème est que je ne peux vraiment rien discerner des journaux. Dans le journal des requêtes lentes de MySQL, je ne vois rien d'intéressant quand un temps d'arrêt se produit. Dans les journaux nginx, je vois des milliers d'entrées indiquant que la demande de lecture a expiré ou que la connexion a expiré (vers PHP-FPM). Et dans les journaux PHP-FPM, je vois beaucoup de lignes qui disent "l'exécution a expiré (31 sec), se terminant

Donc, à ce stade, je ne sais tout simplement pas où chercher le problème. De toute évidence, tout ce qui se passe se produit parce que ces scripts ne s'exécutent pas assez rapidement parfois (normalement, ils se chargent en moins d'une seconde, mais quelque chose se produit qui fait monter en flèche le temps de chargement). Cela se produit plusieurs fois par jour et est devenu un problème pour nous.

Pour l'instant, j'ai simplement une crontab pour entretenir le rechargement php5-fpm toutes les 10 minutes, ce qui résout le problème de plantage. Bien sûr, lorsque PHP se recharge, nginx lance une erreur de passerelle 502, donc ce n'est pas vraiment une solution.

PHP exécute le cache APC, si cela est important. J'ai lu à quelques endroits qu'APC peut provoquer des accrochages dans certaines circonstances.

Tout pointeur serait utile. J'aimerais vraiment ne pas avoir à me soucier de cette machine tout le temps.

Plus d'informations peuvent bien sûr être fournies. Faites-moi savoir ce dont vous avez besoin.

Mise à jour: Je viens de copier apc.php sur une racine Web et d'y accéder pour consulter nos statistiques. Les choses semblaient bonnes. Ensuite, j'ai cliqué sur le lien pour accéder aux statistiques utilisateur et BOOM le serveur s'est immédiatement bloqué. J'ai rechargé php-fpm, puis rechargé la page de statistiques utilisateur et tout s'est bien passé. Attendu une minute, rechargé à nouveau, le serveur se bloque à nouveau.

Cela semble donc définitivement lié à APC. La question est - comment pouvons-nous y remédier?

Config APC:

[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"

Mise à jour 2: nous avons fait des progrès à ce sujet ici. Il s'avère que le plugin de mise en cache WordPress (W3 Total Cache) est à l'origine de ces plantages. Nous ne savons toujours pas pourquoi, mais avec elle désactivée, nous utilisons PHP depuis près de 4 heures maintenant sans rechargements, sans ralentissements, sans plantages. Nous utilisons toujours APC sur les forums vBulletin et aucun problème là-bas. Existe-t-il un moyen de déterminer POURQUOI APC plante? J'adorerais l'utiliser sur nos installations WordPress, mais pas au prix d'un système fragile.

Vous utilisez php-fpm, donc je suggère d'être plus agressif avec combien de temps les enfants de php-fpm sont autorisés à vivre. 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.

Je réduirais le nombre de pm.max_requests pour 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 pour une réaction sur les signaux du maître.

Cela devrait garder votre pool de threads de travail PHP agréable, frais et propre. Plus un travailleur est autorisé à fournir des demandes, plus il sera instable. Il existe également un risque plus élevé de fuites de mémoire.

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 empirique pour tout cela, il y a trop de variables qui affectent le comportement et la stabilité de PHP.