le processus enfant php-fpm s'est terminé sur le signal 11
Notre application est exécutée sur un conteneur docker sur AWS . Système d'exploitation: Ubuntu 14.04.2 LTS Version Nginx: nginx/1.4.6 (Ubuntu) Version Memcached: memcached 1.4.14 Version PHP: PHP 5.5.9-1ubuntu4.11 (cli) (construit le: 2 juillet 2015 15:23:08) Mémoire système: 7,5 Go
Nous obtenons des pages vierges et des erreurs 404 moins fréquemment. Lors de la vérification des journaux, nous avons constaté que le processus php-child est supprimé et il semble que la mémoire soit principalement utilisée par les processus memcache et php-fpm, ainsi que par une mémoire disponible très faible.
memcache est configuré pour utiliser 2 Go de mémoire.
Voici php www.conf
pm = dynamic
pm.max_children = 30
pm.start_servers = 9
pm.min_spare_servers = 4
pm.max_spare_servers = 14
rlimit_files = 131072
rlimit_core = unlimited
Journaux d'erreur
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] WARNING: [pool www] child 259 exited on signal 11 (SIGSEGV - core dumped) after 1339.412219 seconds from start
/var/log/nginx/error.log
2015/07/29 14:37:09 [error] 141#0: *2810 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /suggestions/business?q=Selectfrom HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", Host: "example.com", referrer: "http://example.com/"
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] NOTICE: [pool www] child 375 started
/var/log/nginx/php5-fpm.log:[29-Jul-2015 14:37:56] WARNING: [pool www] child 290 exited on signal 11 (SIGSEGV - core dumped) after 1078.606356 seconds from start
Coredump
Core was generated by php-fpm: pool www.Program terminated with signal SIGSEGV, Segmentation fault.#0 0x00007f41ccaea13a in memcached_io_readline(memcached_server_st*, char*, unsigned long, unsigned long&) () from /usr/lib/x86_64-linux-gnu/libmemcached.so.10
dmesg
[Wed Jul 29 14:26:15 2015] php5-fpm[12193]: segfault at 7f41c9e8e2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:28:26 2015] php5-fpm[12211]: segfault at 7f41c966b2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:29:16 2015] php5-fpm[12371]: segfault at 7f41c9e972da ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:36 2015] php5-fpm[12469]: segfault at 7f41c96961e9 ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:43 2015] php5-fpm[12142]: segfault at 7f41c9e6c2bd ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:07 2015] php5-fpm[11917]: segfault at 7f41c9dd22bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:54 2015] php5-fpm[12083]: segfault at 7f41c9db72bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
S'il vous plaît laissez-moi savoir si besoin de plus d'informations
Merci d'avance
Tout en cherchant Google pour le même problème, et en essayant de trouver une solution qui était not liée aux sessions (parce que j’ai exclu cette possibilité) ni à un mauvais code PHP (car j’en ai plusieurs les sites Web fonctionnant exactement avec la même version de WordPress, et aucun n’ayant de problèmes ... sauf un), j’ai trouvé une réponse indiquant qu’une solution possible impliquait de supprimer une extension boguée (généralement memcache/d, mais pourrait être autre chose).
Étant donné que ce même site fonctionnait parfaitement sur un serveur Ubuntu, lors du passage à un serveur plus récent, j'ai tout de suite suspecté que le problème était dû à la migration de PHP 5.5 vers 7. C'était juste étrange car aucun autre site Web n'a été affecté. Ensuite, je me suis rappelé qu’un autre problème était différent sur ce nouveau serveur: j’avais également installé New Relic . C'est à la fois une extension et un petit serveur qui s'exécute en arrière-plan et envoie beaucoup de données d'analyse à New Relic pour traitement. Il s’agirait d’une extension PHP 5, mais étonnamment, elle se charge bien aussi sur PHP 7.
Maintenant, voici la partie la plus délicate. À un moment donné, j'avais installé W3 Total Cache pour l'installation WordPress de ce site Web particulier. Par la suite, j’ai vu que les performances de ce serveur étaient si stellaires que le W3TC n’était plus nécessaire, et restait simplement bloqué dans une configuration beaucoup plus simple. Je pourrais donc désinstaller W3TC. Tout cela est très gentil, mais ... j'ai oublié que j'avais également activé New Relic sur W3TC (apparemment, cela ajoute des données analytiques supplémentaires à envoyer à New Relic). Lors de la désinstallation de W3TC, il restait probablement quelque chose dans la configuration de New Relic sur mon serveur qui essayait toujours d'envoyer des données via l'interface W3TC (en supposant que W3TC possède une interface ... Je ne sais vraiment pas comment cela fonctionne à ce moment-là. niveau), et, parce que ce bit de code spécifique était manquant, le gestionnaire php_fpm de ce site Web échouerait ... de temps en temps. Pas all l’heure, parce que je suppose que, dans la plupart des cas, nginx renvoyait des pages statiques. Ou peut-être que php_fpm, réglé sur 'recycler' après 100 appels ou plus, planterait à l'arrêt. Quoi qu’il se passe exactement, cela était certainement lié à New Relic - dès que j’ai supprimé l’extension New Relic de PHP, ce site Web est revenu à son fonctionnement normal.
Comme il s'agit d'un scénario spécifique, j'écris simplement ceci comme une réponse, dans la mesure où il est peu probable que quelqu'un à l'avenir recherche le problème avec précision.
Cela peut arriver si php ne parvient pas à écrire les informations de session dans un fichierPar défaut, il s'agit de /var/lib/php/sessionVous pouvez le modifier à l'aide de la configuration session_save_path.
J'ai eu ce problème après avoir installé xdebug, ajouté quelques propriétés à /etc/php/7.1/fpm/php.ini et redémarré nginx. Ceci fonctionne sur une boîte Homestead Laravel.
Redémarrer simplement le service php7.1-fpm l'a résolu pour moi.
Dans notre cas, cela a été causé par Guzzle + New Relic. Dans le journal des modifications de New Relic Agent, ils ont mentionné que dans la version 7.3, il existait un correctif pour Guzzle, mais que même en utilisant la version 8.0 ne fonctionnait pas, il restait donc un problème. Dans notre cas, cela ne se produisait que dans 2 de nos scripts utilisant Guzzle. Nous avons trouvé qu'il y a deux solutions:
- Définissez
newrelic.guzzle.enabled = falsedansnewrelic.ini. Vous perdrez des données dans Services externes onglet de cette façon, mais vous n'en aurez peut-être pas besoin de toute façon. - Déclassement du nouvel agent Relic vers la version 6.x qui fonctionne également
- Si vous lisez ceci quand ils ont publié quelque chose de plus récent que la version 8.0, vous pouvez aussi essayer de mettre à jour le nouvel agent de relique au plus tard et peut-être qu'ils ont corrigé cela
Dans mon cas, il était lié à zend debug/xdebug . Il transmet des paquets TCP à IDE (phpstorm), qui n'écoutait pas sur ce port (le débogage était désactivé). La solution consiste à désactiver ces extensions ou à activer l'écoute de débogage sur le port de débogage.
Dans mon cas, cela était dû à l'agent New Relic PHP. Par conséquent, pour des fonctions spécifiques qui provoquent un crash, j'ai ajouté ce code pour désactiver New Relic.
if (function_exists('newrelic_ignore_transaction')) {
newrelic_ignore_transaction();
}
voir: https://discuss.newrelic.com/t/how-to-disable-a-specific-transaction-in-php-agent/42384/2
Vous pouvez généralement trouver plus de détails sur ces plantages en consultant votre syslog (/var/log/syslog sur linux, /var/log/system.log sur mac os).
J'ai eu Sep 14 11:16:26 bob ReportCrash[89504]: Saved crash report for php-fpm[13757] version 0 to /Users/bob/Library/Logs/DiagnosticReports/php-fpm_2017-09-14-111626_MacBob.crash sur mon syslog, et le fichier généré contenait tout pour savoir quelle extension rencontrait des problèmes.
dans mon cas, j'ai désactivé la fonction de mise en mémoire tampon ob_start("buffer"); dans mon code;)