1 votes

Nginx + php-fpm - erreur recv()

J'obtiens l'erreur suivante dans le journal de nginx

[error] 17734#0 : *6643 recv() failed (104 : Connection reset by peer) pendant la lecture de l'en-tête de réponse en amont, client : [cut], serveur : [cut], request : "GET /venues HTTP/1.1", upstream : "fastcgi://127.0.0.1:9000", hôte : "[cut]".

J'ai une boîte dédiée avec 8 gb ram, quad core chip. Bon serveur. Nginx, php-fpm et mysql toutes les dernières versions fonctionnant sous ubuntu 10.04.

Je n'ai ce problème que lorsque je teste le serveur avec siege. Si j'augmente le nombre de connexions simultanées à 100, je peux obtenir jusqu'à 20% de toutes les requêtes qui échouent.

De plus, je n'obtiens pas ce résultat sur les pages qui n'ont pas de requêtes mysql. Et seulement quelques échecs sur des pages avec un nombre modéré de requêtes. Mais je ne suis pas sûr que cela ait un rapport avec le problème.

J'ai l'impression que ça a quelque chose à voir avec php. Mais je n'arrive pas à le comprendre.

Avez-vous des suggestions sur la façon de commencer à chercher ?

Mise à jour : et le journal des erreurs de php est silencieux. Aucun enregistrement d'un problème quelconque

1voto

Alex Points 7759

Il est fort probable que vous n'ayez plus de travailleurs php-fpm. Le journal était silencieux parce que le code lui-même n'était pas défectueux - les travailleurs étaient simplement occupés à traiter vos demandes. Si vous n'obtenez pas ce résultat sur des pages sans requêtes MySQL, le goulot d'étranglement est la base de données MySQL. Vous devez identifier les requêtes qui s'exécutent depuis longtemps (en utilisant la commande mytop ou la fonction de journalisation lente ou peut-être une journalisation PHP personnalisée autour de votre traitement SQL) et les optimiser. Bien sûr, les "longues requêtes" sont en fait assez courtes dans le monde à forte charge. Même une requête de 200 ms est suffisamment longue pour mettre votre serveur à genoux.

-1voto

leeoniya Points 127

Cela peut être résolu. j'ai rapporté un problème similaire avec l'ouverture et la réutilisation de sockets tcp persistants sous presque aucune charge. il y a maintenant un patch déposé pour cela dans git :

https://groups.google.com/forum/#!topic/highload-php-en/qGu3Eaifj9s

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X