Une mise à jour de la liste ci-dessous:
J'ai rencontré un problème similaire sur un script non lié, sur une machine virtuelle Debian située dans un autre centre de données.
Cela ressemble étrangement à la question décrite ici (et comme la personne qui pose cette question, je n'ai pas de proxy configuré devant le serveur).
La principale différence par rapport à la description ci-dessous est que, lorsque je me connecte au processus bloqué, je vois un appel à recvfrom
plutôt que read
:
$ strace -p 17527
Process 17527 attached - interrupt to quit
recvfrom(3,
Cependant, Python n’a pas l’impression d’être traité par proxy:
>>> import os; print os.getenv("HTTP_PROXY"), os.getenv("http_proxy")
None, None
Donc, je suis toujours perplexe. Malheureusement, la question liée n'a pas de réponse finale également.
(Je me demande aussi si cette question est liée, mais il semble peu probable que S3 échoue à honorer Connection: close
en-têtes.)
J'ai plusieurs serveurs Debian (Wheezy, x86_64) qui présentent tous le comportement suivant:
Tous les serveurs ont un ensemble de tâches cron qui, entre autres choses, extraient des données de S3. Ceux-ci fonctionnent généralement bien, mais parfois ps aux
révèle que certains des travaux commencés il y a des heures ou des jours sont toujours en cours d'exécution et ne sont pas terminés proprement.
Les inspecter avec strace -p <pid>
montre que, dans tous les cas, le processus est suspendu à une commande de lecture. Par exemple, la sortie d'un processus que j'ai vérifié tout à l'heure était:
$ strace -p 12089
Process 12089 attached - interrupt to quit
read(5,
Et vérifier les descripteurs de fichiers ouverts me donne ceci:
$ sudo lsof -i | grep 12089
python 12089 user 5u IPv4 809917771 0t0 TCP my.server.net:35427->185-201.amazon.com:https (ESTABLISHED)
Au début, je pensais que c'était simplement dû à l'absence de définition d'un délai de lecture dans les scripts Python, mais cela ne semble pas être le cas, pour deux raisons:
- Cela ne se produit pas lorsque les mêmes travaux sont exécutés sur nos boîtes OS X (tous 10.5, i386), en utilisant un code identique.
- Une variante du script qui Est-ce que définir un délai d'attente (de 60 secondes, à l'aide de
socket.setdefaulttimeout
- ceci est en Python 2.7, mais la base de code doit être compatible 2.5) a été suspendue depuis hier. - Un autre processus qui n'est pas Python semble parfois présenter un comportement similaire. Dans ce cas, un script Python exécute une
svn up --non-interactive
processus (en utilisantsubprocess.Popen
, pour ce que ça vaut).
La situation avec ce processus SVN est similaire--
Python attend SVN:
$ strace -p 28034
Process 28034 attached - interrupt to quit
wait4(28127,
Et SVN attend un read
appel à compléter:
$ strace -p 28127
Process 28127 attached - interrupt to quit
read(6,
Et cette lecture pointe vers un autre hôte externe:
$ sudo lsof -i | grep 28127
svn 28127 user 3u IPv4 701186417 0t0 TCP my.server.net:49299->sparrow.telecommunity.com:svn (ESTABLISHED)
svn 28127 user 6u IPv4 701186439 0t0 TCP my.server.net:49309->sparrow.telecommunity.com:svn (ESTABLISHED)
(Il semble y avoir un svn:externals
propriété définie sur ez_setup svn://svn.eby-sarna.com/svnroot/ez_setup
sur le répertoire en cours de mise à jour; basé sur leur site Web, je pense que ceci est une redirection vers telecommunity.com)
Autres points éventuellement pertinents:
- L’environnement Python sur les Mac est 2.5. Sur les boîtes Debian, il s'agit de 2.7.
- Je ne suis pas très au courant de SVN et je ne sais pas si la raison pour laquelle elle est suspendue est fondamentalement la même chose ou non. Je ne suis pas non plus tout à fait sûr des implications de
svn:externals
sont; cela a été mis en place avant mon temps. - Les scripts Python eux-mêmes récupèrent des blocs de données volumineux (environ 10 Mo dans certains cas) d'Amazon S3, ce qui a tendance à être lent (le temps de téléchargement est de trois minutes, ce qui semble long par rapport à la façon dont longtemps, il faut que les serveurs, même dans différents centres de données, communiquent entre eux). De même, certains de nos référentiels SVN sont plutôt grands. Voilà donc essentiellement pour dire que certaines de ces opérations sont de longue durée en tous casCependant, dans certains cas, ils semblent également être bloqués pendant des heures ou des jours.
- Sur un serveur, le tueur de MOO a sorti MySQL ce matin. En regardant de plus près, l'utilisation de la mémoire était à 90% et l'utilisation de l'échange à 100% (comme indiqué par Monit); l'élimination d'un important arriéré d'emplois bloqués en Python a permis de ramener ces statistiques à 60% et 40% respectivement. Cela me donne l'impression qu'au moins une partie (sinon la totalité) des données est en cours de téléchargement / lecture (et conservée en mémoire pendant que le processus est suspendu).
- Ces tâches cron demandent une liste de ressources à S3 et mettent à jour une liste de tables MySQL en conséquence. Chaque travail est démarré avec la même liste. Nous allons donc essayer de demander les mêmes ressources et mettre à jour les mêmes tables.
J'ai pu capturer du trafic provenant de l'un des processus bloqués; tout cela est un peu impénétrable pour moi, mais je me demande si cela indique que la connexion est active et fonctionne, tout simplement très lente? Je l'ai fourni comme un résumé, pour éviter l'encombrement (je dois noter que cela représente environ deux heures de capture): https://gist.github.com/petronius/286484766ad8de4fe20bC'était un hareng rouge, je pense. Il y a de l'activité sur ce port, mais ce n'est pas la même connexion que celle vers S3, c'est simplement une autre activité de serveur aléatoire.- J'ai essayé de recréer ce problème sur une boîte d'un autre centre de données (une machine virtuelle exécutant la même version de Debian avec la même configuration système) sans succès (je pensais que le problème était peut-être lié à celui-là, mais les boites rencontrant ces problèmes ne sont pas des machines virtuelles et il n’y a pas de paquets perdus conformément à
ifconfig
). Je suppose que cela indique un problème de configuration réseau, mais je ne sais pas par où commencer.
Donc, je suppose que mes questions sont:
- Puis-je résoudre ce problème au niveau du système ou est-ce que quelque chose ne va pas avec chaque processus?
- Existe-t-il quelque chose de fondamentalement différent dans la manière dont OS X et Linux gèrent
read
les appels que je dois savoir pour éviter les processus indéfiniment suspendus?