2017-01-31 1 views
0

J'ai une application django configurée pour fonctionner derrière nginx en utilisant uWSGI. Sur une machine séparée, je cours le céleri, et pousse les tâches à exécution longue du serveur Web à la machine de tâche. La majorité des E/S de tâches sont des demandes http sortantes, qui durent une heure ou plus. Le courtier de tâches est redis.Nginx non réactif pendant l'exécution de céleri

Lorsque les tâches sont exécutées pendant plus d'une minute ou deux, le serveur Web ne répond plus (503 erreurs).

Aucune erreur n'a été détectée dans l'application python. Les tâches se terminent normalement, après quoi le serveur Web continue de gérer les demandes.

Est-ce que quelqu'un a déjà vécu cela et, dans l'affirmative, comment l'avez-vous traité? Merci

Répondre

0

par défaut uwsgi commence par un processus unique et un seul thread

De l'uwsgi docs. Selon votre configuration, cela pourrait causer le problème. : Viens de remarquer que vous n'avez pas dit uwsgi, mais seulement wsgi - néanmoins, selon votre implémentation wsgi, le problème pourrait être causé par le même fait.

+0

Désolé, c'est en effet uWSGI (édité plus haut). Nous l'avons configuré pour le multitraitement. Même si nous ne l'avons pas fait, je ne vois pas pourquoi une seule application web à threads se bloquerait après avoir appelé une tâche de céleri. Ou pourquoi le blocage ne se produirait pas immédiatement, mais plutôt après quelques minutes. – joek575

+0

Est-ce que cela s'applique: la boîte de dialogue nginx uwsgi django est la machine à tâches et les requêtes http de céleri sont-elles sur cette machine? Ou est le seul lien entre ces deux boîtes redis et ils n'ont rien d'autre à faire les uns avec les autres? – dahrens

+0

Les deux boîtes sont connectées uniquement via redis. Il existe également une base de données postgres partagée, mais celle-ci se trouve encore dans une autre case, et aucune des deux ne semble avoir de problème à maintenir la connexion db. – joek575

0

Compris au bout de quelques jours. Nous utilisions une application django appelée django-health-check. Il a un composant appelé health_check_celery3 qui était dans les applications installées. Cela avait du mal à charger pendant que le céleri fonctionnait, et causant ainsi l'ensemble de l'application à caler. Après l'avoir enlevé, le céleri fonctionne comme il se doit.