Sellerie - minimieren Speicherverbrauch

Question

Wir haben ~ 300 selleryd Prozesse laufen unter Ubuntu 10.4 64-Bit, im Leerlauf dauert jeder Prozess ~ 19mb RES, ~ 174mb VIRT, so - es ist rund 6GB RAM im Leerlauf für alle Prozesse. Im aktiven Zustand - Prozess dauert bis zu 100mb RES und ~ 300mb VIRT

Jeder Prozess verwendet Minidom (XML-Dateien sind < 500kb, einfache Struktur) und urllib.

Fragen ist - wie können wir RAM Konsum reduzieren - zumindest für untätige Arbeiter, wahrscheinlich einige Sellerie oder Python-Optionen können helfen? Wie ermittelt man, welcher Teil den größten Teil des Speichers belegt?

UPD: Das ist Flugsuche Agenten, ein Arbeiter für eine Agentur/Datum. Wir haben 10 Agenturen, eine Benutzersuche == 9 Daten, also haben wir 10 * 9 Agenten pro eine Benutzersuche.

Ist es möglich, selleryd Prozesse auf Anfrage zu starten, um Leerlaufarbeiter zu vermeiden (so etwas wie MaxSpareServers auf Apache)?

UPD2: Agent-Lebenszyklus - HTTP-Anforderung für eine Antwort senden, warten ~ 10-20 sec, xml parsen (dauert weniger als 0,02 s), zu MySQL speichern führen

Answer 1

Lesen Sie dieses:

http://docs.celeryproject.org/en/latest/userguide/workers.html#concurrency

Es klingt wie Sie haben einen Arbeiter pro Sellerie. Das scheint falsch zu sein. Sie sollten Dutzende Arbeiter pro Sellerie haben. Erhöhen Sie die Anzahl der Arbeiter (und senken Sie die Anzahl der Sellerie), bis Ihr System sehr beschäftigt und sehr langsam ist.

Answer 2

S. Lott hat Recht. Die Hauptinstanz verbraucht Nachrichten und delegiert sie an Worker-Pool-Prozesse. Es hat wahrscheinlich keinen Sinn, 300 Pool-Prozesse auf einer einzigen Maschine auszuführen! Versuchen Sie 4 oder 5 multipliziert mit der Anzahl der CPU-Kerne. Sie können etwas gewinnen, indem Sie mehr als nur auf Sellerie mit ein paar Prozessen laufen, einige Leute haben, aber Sie müssten für Ihre Anwendung experimentieren.

Siehe http://celeryq.org/docs/userguide/workers.html#concurrency

Für die kommende Release 2.2 wir auf Eventlet Pool Unterstützung arbeiten, diese eine gute Alternative für IO-gebundene Aufgaben sein können, dass Sie ermöglichen 1000+ Threads mit minimalen Speicher laufen Overhead, aber es ist immer noch experimentell und Fehler werden behoben für die endgültige Version.

Siehe http://groups.google.com/group/celery-users/browse_thread/thread/94fbeccd790e6c04

Das kommende Release 2.2 auch Unterstützung für automatische Skalierung hat, die/entfernt auf Demand-Verfahren erstellt. Siehe das Changelog: http://ask.github.com/celery/changelog.html#version-2-2-0 (das Changelog nicht komplett noch geschrieben wird)

Answer 3

Die natürliche Zahl der Arbeitnehmer ist in der Nähe der Anzahl der Kerne Sie haben. Die Mitarbeiter sind da, damit CPU-intensive Aufgaben einen ganzen Kern effizient nutzen können. Der Broker ist vorhanden, sodass Anfragen, die keinen Mitarbeiter zur Bearbeitung haben, in der Warteschlange verbleiben. Die Anzahl der Warteschlangen kann hoch sein, aber das bedeutet nicht, dass Sie auch eine hohe Anzahl an Brokern benötigen. Ein einzelner Broker sollte ausreichen, oder Sie könnten Warteschlangen an einen Broker pro Maschine verteilen, wenn sich später herausstellt, dass eine schnelle Worker-Queue-Interaktion von Vorteil ist.

Ihr Problem scheint damit nichts zu tun zu haben.Ich nehme an, dass Ihre Agenturen keine Nachrichtenwarteschlange api bereitstellen und Sie viele Anfragen bearbeiten müssen. Wenn ja, brauchen Sie ein paar (Schwerpunkt auf nicht viele) ausgeglichene Prozesse, zum Beispiel twisted oder node.js basierend.

Answer 4

Verwenden Sie Autoscaling. Dies ermöglicht es, die Anzahl der Arbeiter unter jeder Sellerie-Instanz je nach Bedarf zu erhöhen oder zu verringern. http://docs.celeryproject.org/en/latest/userguide/workers.html#autoscaling