Nous avons ~ 300 processus CEPERYD fonctionnant sous Ubuntu 10.4 64 bits, dans le ralenti, chaque processus prend ~ 19 Mo de Res, ~ 174 Mo en virage, il est donc d'environ 6 Go de RAM en ralenti pour tous les processus. En état actif - le processus prend jusqu'à 100 Mo de res et ~ 300MB virte
Chaque processus utilise Minidom (les fichiers XML sont <500 Ko, une structure simple) et Urllib.
Quétions est - Comment pouvons-nous réduire la consommation de RAM - du moins pour les travailleurs inactifs, probablement certaines options de céleri ou de python peuvent aider? Comment déterminer quelle partie prend la majeure partie de la mémoire?
upding: Les agents de recherche de vol, un ouvrier pour une agence / date. Nous avons 10 agences, une recherche d'un utilisateur == 9 dates, nous avons donc 10 * 9 agents par une recherche d'utilisateur.
Est-il possible de démarrer CEPERYD Processes à la demande d'éviter les travailleurs inactifs (quelque chose comme Maxsparservers sur Apache)?
4 Réponses :
Lire ceci:
http://docs.celeryproject.org/en/latest /userguide/workers.html#concurrency
On dirait que vous avez un travailleur par célerid. Cela semble faux. Vous devriez avoir des dizaines de travailleurs par céleri. Continuez à augmenter le nombre de travailleurs (et abaissant le nombre de celeyds) jusqu'à ce que votre système soit très occupé et très lent.
@Paulo Scardine: "Chaque travailleur aboutit une nouvelle instance de céleri". Ne semble pas juste, lorsque la documentation suggère "par exemple 3 Celeryd's avec 10 processus de travailleur chacun".
Je cours 'PS' sur mon serveur, du moins avec Djcelery, je vois une instance de célerie principale + une pour chaque travailleur.
@Paulo Scardine: Je pense que les docs ne parlent que de l'instance principale. Mais je ne suis pas sûr à 100%. À ce stade, vous devriez probablement lire les documents de céleri pour voir comment il peut être configuré.
@Paulo Scardine: Je m'excuse de ne pas être sûr à 100%. Peu de choses sont sûres à 100% dans mon monde. Peut-être que vous avez une meilleure expérience d'être totalement juste à propos de quelque chose. Je ne connais pas votre configuration. Je ne sais pas ce que vous avez fait pour configurer le céleri ou comment vous l'utilisez. Je ne peux pas vraiment commenter ce que vous voyez du tout, car j'ai zéro faits sur lequel baser mes commentaires. Le manque de faits le rend très, très difficile de répondre à votre commentaire. Cependant, le lien que j'ai fourni semble fournir des informations utiles. Peut-être que vous pourriez le lire?
s. Lott a raison. L'instance principale consomme des messages et les déléguette aux processus de piscine des travailleurs. Il ne sert probablement pas de point dans l'exécution de 300 procédés de piscine sur une seule machine! Essayez 4 ou 5 multiplié par le nombre de cœurs CPU. Vous pouvez gagner quelque chose en courant plus que sur Celeryd avec quelques processus, certaines personnes ont, mais vous devrez expérimenter votre demande.
voir http://celeryq.org/docs/userguide/workers.html#concuncurrency
Pour la prochaine version 2.2, nous travaillons sur l'Assistance Eventlet Pool, cette mai Soyez une bonne alternative pour les tâches liées à IO, cela vous permettra d'exécuter 1000 threads avec un minimum de mémoire au-dessus de la mémoire, mais il est encore expérimental et les insectes sont en cours de correction Pour la version finale.
voir http://groups.google.com/group/celery -Utilisateurs / browse_thread / thread / 94fbeccd790E6C04
La prochaine version 2.2 est également prise en charge pour l'autosticale, qui ajoute / supprime le processus à la demande. Voir le changelog: http://ask.github.com/celear/changelog.html # Version-2-2-0 (Ce changelog n'est pas encore écrits)
Nous gérons 300 travailleurs comme tous les demandes HTTP longs, elles sont donc occupées jusqu'à la réception de la réponse HTTP. Y a-t-il un moyen plus correct de résoudre ce problème?
Comme je l'ai dit, le soutien d'eventlet au CELERY MASTER est beaucoup mieux à ce type d'application. Les chances sont que vous ne recevrez plus de demandes / s avec 300 processus que vous ne le faites avec 15 processus. (Si vous avez 8 cœurs), vous aurez plus de chances que vous aurez moins de performances car ce sera le commutateur de contexte à la poubelle.
Le nombre naturel de travailleurs est proche du nombre de noyaux que vous avez. Les travailleurs sont là afin que les tâches intensives de la CPU puissent utiliser tout le noyau de manière efficace. Le courtier est là pour que les demandes qui n'ont pas de travailleur à la main pour les traiter sont tenues en file d'attente. Le nombre de files d'attente peut être élevée, mais cela ne signifie pas que vous avez besoin d'un grand nombre de courtiers non plus. Un seul courtier devrait suffire, ou vous pourriez faire des files d'attente de Shard sur un courtier par machine s'il s'avère ultérieurement une interaction rapide de la file d'attente de travailleur, est bénéfique.
Votre problème ne semble pas lié à cela. Je suppose que vos agences ne fournissent pas d'API de la file d'attente de message et vous devez garder autour de nombreuses demandes. Si tel est le cas, vous avez besoin de quelques processus éventuels, par exemple torsadés ou nœud.js.
Utilisez l'autocaling. Cela permet d'augmenter ou de décrire le nombre de travailleurs sous chaque instance de célerie. http://docs.celeryproject.org/en/latest/userguide/workers .html # autoscaling
Avez-vous essayé Serverfault.com ou #Celery sur irc.freenode.net?
Serverfault est vide, illicance de
Pourquoi tant d'inactifs
CELERYD serveurs?@ S.Lott: +1, j'ai une grosse lettre d'information utilisant seulement 8 travailleurs, je peux envoyer des messages / heure de 500k. Difficile d'imaginer une application nécessitant tant de travailleurs.
Thats Agents de recherche de vols, un travailleur pour une agence / date. Nous avons 10 agences, une recherche d'un utilisateur == 9 dates, nous avons donc 10 * 9 agents par une recherche d'utilisateur
@Andrew: (1) Veuillez Mettre à jour Votre question, ne pas ajouter de commentaires. (2) Pourquoi tant de fois? S'ils sont inactifs plus de 50% du temps, vous en avez 2x autant que vous avez besoin, non? Pourquoi y a-t-il des serveurs de ralenti ?
@Andrew: Si vous vous connectez directement à la compagnie de vol Webservices, je comprends mieux le problème.
@Paulo Scardine - C'est vrai, nous avons un travailleur pour chacune des 9 entreprises de vol que nous travaillons avec