Verständnis Sellerie Aufgabe prefetching

Ich habe gerade herausgefunden über die Konfigurations-option CELERYD_PREFETCH_MULTIPLIER (docs). Die Standardeinstellung ist 4, aber (ich glaube) möchte ich das prefetching auszuschalten oder so gering wie möglich. Ich setzen Sie ihn auf 1, und das ist nahe genug, um das, was ich Suche, aber es gibt immer noch einige Dinge, die ich nicht verstehe:

  1. Warum ist das prefetching eine gute Idee? Sehe ich nicht wirklich einen Grund für ihn, es sei denn, es gibt eine Menge Wartezeit zwischen der message-queue und den Arbeitnehmer (in meinem Fall, Sie sind momentan auf dem gleichen host und im schlimmsten Fall könnte schließlich laufen auf unterschiedlichen hosts im gleichen Datencenter). Die Dokumentation erwähnt nur die Nachteile, sondern kann erklären, was die Vorteile sind.

  2. Viele Menschen scheinen dies auf 0 gesetzt, erwartet werden in der Lage zu deaktivieren prefetching, die Möglichkeit (eine vernünftige Annahme meiner Meinung nach). Jedoch 0 bedeutet unbegrenzte prefetching. Warum würde jemand jemals wollen unlimited prefetching, das nicht vollständig beseitigt die Parallelität/Asynchronität Sie führte eine task-queue für den ersten Platz?

  3. Warum kann dieses Verfahren nicht abgeschaltet werden? Es ist vielleicht nicht eine gute Idee für performance, es zu deaktivieren in den meisten Fällen aber gibt es einen technischen Grund für diese nicht möglich sein? Oder ist es nur nicht umgesetzt werden?

  4. Manchmal, diese option ist verbunden mit CELERY_ACKS_LATE. Zum Beispiel. Roger Hu schreibt «[...] oft was [Benutzer] wirklich wollen ist ein Arbeitnehmer nur dann behalten, wie viele Aufgaben da sind Kind-Prozesse. Dies ist aber nicht möglich, ohne dass späte Danksagung [...]» ich verstehe nicht, wie diese zwei Optionen verbunden sind, und warum das eine ist ohne das andere nicht möglich. Eine weitere Erwähnung der Verbindung gefunden werden kann hier. Kann mir jemand erklären, warum die zwei Optionen verbunden sind?

InformationsquelleAutor Henrik Heimbuerger | 2013-04-16
  1. 23

    1. Prefetching kann die Leistung verbessern. Die Arbeiter brauchen nicht zu warten, für die nächste Nachricht von einem broker zu verarbeiten. Die Kommunikation mit einem broker einmal und Verarbeitung eine Menge von Nachrichten bietet einen performance-Gewinn. Bekomme eine Meldung von einem broker (auch von lokalen), ist teuer im Vergleich zu den lokalen Speicher zugreifen. Arbeitnehmer dürfen auch anerkennen, Nachrichten in batches

    2. Prefetching gesetzt auf null bedeutet "keine spezifische Grenze" eher als unbegrenzt

    3. Einstellung prefetching zu 1 dokumentiert ist, gleichwertig sein, Sie auszuschalten, aber dies möglicherweise nicht immer der Fall sein (siehe https://stackoverflow.com/a/33357180/71522)

    4. Prefetching ermöglicht ack-Nachrichten in batches. CELERY_ACKS_LATE=True verhindert Bestätigung der Nachrichten, wenn Sie eine Arbeitskraft, die

    • Danke. 2) Okay, aber warum würde jemand wollen "- keine spezifische Grenze'? 3) ich bin mir ziemlich sicher, dass ich noch sehen "Bekam Aufgabe von broker" - Nachrichten, bevor der aktuelle task beendet wurde.
    • AFAIK Einstellung prefetching zu 1 ist nicht entspricht, Sie auszuschalten. Es ist der niedrigste mögliche Wert (wobei Sie sich nicht Hacker den source-code) für prefetch, was wiederum die Anzahl der CPU/Kerne in der aktuellen Maschine.
    • Es ist nicht die Anzahl der CPUs/cores, es ist die Anzahl der Sellerie Arbeiter, die Sie definiert haben (was in einigen Fällen werden die gleichen, aber in der Regel nicht). Auch wenn jeder Arbeiter ist prefetching einer einzelnen Aufgabe, dann ausführen, dann prefetching anderen, dies ist äquivalent zu drehen prefetching deaktiviert, so dass IMHO deine Aussage ist falsch. (Das system muss immer prefetch-so viele Aufgaben, wie es der Arbeitnehmer, wenn er will, zu halten alle Arbeitnehmer zugeführt, die mit Aufgaben.)
    • meine Aussage basiert auf meiner eigenen Erfahrung mit Sellerie + Redis als backend. Zu erarbeiten, betrachten Sie das folgende Szenario: Mit einem einzelnen Computer für Arbeitnehmer, beginne ich einen Sellerie-Arbeiter mit CELERYD_PREFETCH_MULTIPLIER eingestellt 1. Eine Aufgabe, die bearbeitet wird. Die erste was ausgeführt wird, ist die Abmeldung aus der aktuellen Warteschlange. Sobald die Aufgabe abgeschlossen ist, entweder ich bekomme eine andere Aufgabe, oder eine Fehlermeldung erhalten, fordern kein handler gefunden, die für die aktuelle Aufgabe. Die eine oder andere Weise, das bedeutet, dass prefetching nicht ausgeschaltet.
    • Ich denke, CELERYD_PREFETCH_MULTIPLIER auf 1 gesetzt, bedeutet im Grunde 'Holen'. Pre-fetching ist stillschweigend, wenn der Wert >1. Also im Endeffekt Aufgaben über 1 werden als "pre-fetched'.
    • Ich habe einige Experimente, und (zumindest bei den Redis broker) - Einstellungen CELERYD_PREFETCH_MULTIPLIER = 1 macht nicht deaktivieren prefetching. Es ist einfach — wie der name schon sagt — nur prefetches eine Aufgabe auf Zeit.
    • bitte werfen Sie einen Blick auf dieser link

    InformationsquelleAutor mher
  2. 21

    Alte Frage, aber immer noch hinzufügen meine Antwort, falls es jemand hilft. Mein Verständnis von ersten Tests war die gleiche wie in David Wolever Antwort. Ich habe gerade getestet, die mehr in Sellerie 3.1.19 und -Ofair funktioniert. Nur, dass es ist nicht dazu gedacht, zu deaktivieren, prefetch an der Arbeiter-Knoten-Ebene. Das wird weiterhin passieren. Mit -Ofair hat eine andere Wirkung, die auf der pool-Ebene beleuchtet. Zusammenfassend ist zu deaktivieren, prefetch komplett, dies zu tun:

    1. Set CELERYD_PREFETCH_MULTIPLIER = 1
    2. Set CELERY_ACKS_LATE = True auf globaler Ebene oder task-level
    3. Verwenden -Ofair beim starten der Arbeitnehmer
    4. Wenn Sie die Parallelität auf 1, dann Schritt 3 ist nicht erforderlich. Wenn Sie möchten, eine
      höhere Parallelität, dann Schritt 3 ist wichtig, um zu vermeiden, Aufgaben zu bekommen
      gesichert in einem Knoten, der laufen konnte, lange laufende Aufgaben.

    Hinzufügen von ein paar mehr details:

    Fand ich, dass der worker-Knoten wird immer prefetch standardmäßig. Sie können nur kontrollieren, wie viele Aufgaben es prefetches mithilfe CELERYD_PREFETCH_MULTIPLIER. Wenn auf 1 gesetzt, es wird nur der prefetch-so viele Aufgaben, wie die Anzahl der pool-Arbeiter (Parallelität) in den Knoten. Also, wenn Sie hatte Parallelität = n, die max tasks ein Prefetch durchgeführt wird, indem die Knoten aus n.

    Ohne die -Ofair option, was passiert ist, war für mich, dass, wenn man den pool worker-Prozessen ausgeführt wurde eine lange laufende Aufgabe, die anderen Arbeiter in den Knoten würde auch aufhören Bearbeitung der Aufgaben bereits zuvor abgerufener durch den Knoten. Durch die Verwendung -Ofair verändert. Auch wenn einer der Arbeiter in den Knoten ausgeführt wurde eine lange laufende Aufgaben, andere würden nicht aufhören, Verarbeitung und würden weiterhin zum Bearbeiten der Aufgaben zuvor abgerufener durch den Knoten. Also ich sehe da zwei Ebenen von prefetching. Eine an der Arbeiter-Knoten-Ebene. Die anderen auf der individuellen Ebene beleuchtet. Mit -Ofair für mich schien Sie es deaktivieren, um an der Arbeiter-Ebene.

    Wie ist ACKS_LATE im Zusammenhang? ACKS_LATE = True bedeutet, dass der Auftrag wird nur anerkannt, wenn die Aufgabe erfolgreich ist. Wenn nicht, nehme ich an, es würde passieren, wenn es empfangen wird von einem Arbeiter. Im Falle von prefetch, wird die Aufgabe zunächst durch die Arbeiter (bestätigt von logs) aber wird später ausgeführt. Ich erkannte, dass zuvor abgerufener Nachrichten erscheinen unter "unbestätigte Meldungen" im rabbitmq. Also ich bin mir nicht sicher, ob die Einstellung True absolut notwendig ist. Wir jedenfalls hatten unsere Aufgaben, die Art und Weise (late-ack) aus anderen Gründen.

    • Vielen Dank für noch einen Beitrag zu dieser Frage! Könntest du etwas mehr Details? Sind Sie zum Beispiel schreiben -Ofair hat eine "andere Wirkung", aber nicht, wie die Wirkung ist anders. Auch, Sie bringen bis CELERY_ACKS_LATE, wie andere schon vor, aber bisher hat niemand geschafft, mir zu erklären, was das Attribut zu tun hat, mit deaktivieren von prefetching.
    • Ich hatte das gleiche Problem, läuft mit einem redis-backend. Ich hatte 4 gleichzeitigen Aufgaben ausgeführt werden, und wenn man begann, hängen die anderen würden warten, bis er Sie fertig sind (wäre es nicht) - das Töten, die Arbeiter würden dann ermöglichen, dass andere fortsetzen. Ich hatte schon prefetch=1, celery_acks=True und wenn ich Hinzugefügt -Ofair es behebt das Problem, wo Sie warteten auf die hung-Arbeiter. Leider hing worker-Problem immer noch nicht behoben, für mich und alle Arbeiter irgendwann hängen, aber zumindest werden Sie nicht mehr tun, es auf genau die gleiche Zeit.
    InformationsquelleAutor ksrini
  3. 14

    Nur eine Warnung: als meine Tests mit redis-broker + Sellerie 3.1.15, alle Ratschläge, die ich gelesen habe in Bezug auf CELERYD_PREFETCH_MULTIPLIER = 1 deaktivieren von prefetching ist nachweislich falsch.

    Um dies zu demonstrieren:

    1. Set CELERYD_PREFETCH_MULTIPLIER = 1
    2. Anstehen 5 Aufgaben, die jeweils ein paar Sekunden dauern (ex time.sleep(5))

    3. Beginnen beobachten Sie die Länge der Warteschlange Aufgabe in Redis: watch redis-cli -c llen default

    4. Start celery worker -c 1

    5. Beachten Sie, dass die Länge der Warteschlange in Redis wird sofort fallen von 5 zu 3

    CELERYD_PREFETCH_MULTIPLIER = 1 nicht verhindern, dass prefetching, es einfach Grenzen die prefetching 1 Aufgabe pro Warteschlange.

    -Ofair, trotz allem, was die Dokumentation sagt, auch nicht verhindern, dass prefetching.

    Kurz, eine änderung der source-code, ich habe nicht gefunden eine Methode für ganz deaktivieren von prefetching.

    • Wie die anderen Antworten erwähnt haben, wenn Sie auch festlegen CELERY_ACKS_LATE = 1 dann deaktivieren Sie effektiv prefetching.
    InformationsquelleAutor David Wolever
  4. 9

    Kann ich nicht kommentieren, David Wolever Antworten, da mein stackcred nicht hoch genug. So, ich habe eingerahmt, mein Kommentar als Antwort, da würde ich gerne meine Erfahrung mit Sellerie 3.1.18 und einem Mongodb broker. Ich stoppte prefetching mit den folgenden:

    1. hinzufügen CELERYD_PREFETCH_MULTIPLIER = 1 den Sellerie config
    2. hinzufügen CELERY_ACKS_LATE = True den Sellerie config
    3. Starten Sellerie-Arbeiter mit Optionen: --concurrency=1 -Ofair

    Verlassen CELERY_ACKS_LATE, um die Standard -, die Arbeiter noch prefetches. Genau wie die OP, die ich nicht vollständig zu erfassen die Verbindung zwischen prefetching und späten acks. Ich verstehe, was David sagt, "CELERY_ACKS_LATE=True verhindert Bestätigung der Nachrichten, wenn Sie erreichen, um einen Arbeiter", aber ich kann nicht verstehen, warum die späten acks wäre nicht kompatibel mit dem prefetch. In der Theorie ein prefetch-würde immer noch erlauben, um die ack-Recht spät - wenn auch nicht codiert als solche in Sellerie ?

    InformationsquelleAutor Paul-Armand Verhaegen
Schreibe einen Kommentar