Wir haben ~ 300 selleryd-Prozesse, die unter Ubuntu 10.4 64-bit laufen, im Leerlauf dauert jeder Prozess ~ 19mb RES, ~ 174mb VIRT, also - es sind etwa 6GB RAM im Leerlauf für alle Prozesse. Im aktiven Zustand - Prozess dauert bis zu 100 MB RES und ~ 300 MB VIRT
Jeder Prozess verwendet minidom (xml-Dateien sind & lt; 500 kb, einfache Struktur) und urllib.
Fragen ist - wie können wir RAM-Konsum reduzieren - zumindest für untätige Arbeiter, wahrscheinlich helfen einige Sellerie oder Python-Optionen? Wie kann man feststellen, welcher Teil den größten Speicherbedarf hat?
UPD: das sind Flugsuchagenten, ein Mitarbeiter für eine Agentur / ein Datum. Wir haben 10 Agenturen, eine Benutzersuche == 9 Daten, also haben wir 10 * 9 Agenten pro eine Benutzersuche.
Ist es möglich, selleryd Prozesse bei Bedarf zu starten, um untätige Arbeiter zu vermeiden (so etwas wie MaxSpareServers auf Apache)?
UPD2: Agent-Lebenszyklus ist - HTTP-Anfrage senden, auf Antwort warten ~ 10-20 Sek., XML analysieren (dauert weniger als 0.02s), Ergebnis in MySQL speichern
Lesen Sie dies:
Es klingt, als ob Sie einen Arbeiter pro Sellerie haben. 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.
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 auf Sellerie mit ein paar Prozessen laufen, einige Leute haben, aber Sie müssten für Ihre Anwendung experimentieren.
Siehe Ссылка
Für die kommende Version 2.2 arbeiten wir an der Unterstützung von Eventlet-Pools Eine gute Alternative für IO-gebundene Aufgaben, mit denen Sie mehr als 1000 Threads ausführen können mit minimalem Speicheraufwand, aber es ist immer noch experimentell und Bugs werden behoben für die endgültige Veröffentlichung.
Siehe Ссылка
Die kommende Version 2.2 unterstützt auch Autoscale, die Prozesse bei Bedarf hinzufügen / entfernen. Siehe Changelog: Ссылка (Dieses Changelog ist noch nicht vollständig geschrieben)
Die natürliche Anzahl der Arbeiter liegt nahe bei der Anzahl der Kerne, die 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önnen 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.
Verwenden Sie Autoscaling. Dies ermöglicht es, die Anzahl der Arbeiter unter jeder Sellerie-Instanz je nach Bedarf zu erhöhen oder zu verringern. Ссылка
Tags und Links python django profiling celery memory-management