Warteschlange bleibt in Shopware hängen/zu langsam

Ich bin in einigen bestimmten Szenarien auf ein Problem gestoßen. Wir haben etwa 75.000 Kategorien und 110 Vertriebskanäle, und wenn ein Kunde Kategorien aktualisiert, steigt die Zahl der Kategorieindizierungen auf etwa 1.550.050.
In solchen Fällen bleibt die Warteschlange hängen oder verarbeitet sich extrem langsam. Haben Sie eine Idee, wie man damit umgehen kann?
Showpare Version: 6.6.9.0

Moin,

als erstes würde ich schauen, ob man die Abarbeitung der Warteschlange im allgemeinen verbessern kann. Zb über Redis oder RabbitMQ. Weiterhin kann man einzelne Tasks in eigene Consumer auslagern und generell mehrere Consumer laufen lassen.

Grün
Matthias

Danke für die Antwort, ich habe Redis für die Warteschlange verwendet und jeweils zwei Prozesse für ASYC konfiguriert und bin in Superviosr fehlgeschlagen. Bitte sehen Sie sich den Screenshot an. Es funktioniert gut, wenn die Indexnummer innerhalb einer bestimmten Grenze liegt, aber wenn sie sehr groß ist, Alles scheint zu stecken oder zu langsam in der Verarbeitung zu sein.

Hi, mal so als Feedback wie ich es verwende:
RabbitMQ
bin/console messenger:consume async --time-limit=60 --memory-limit=1024M
und 5 Prozesse.
Zusätzlich jeweils 2 für low_priority und failed.

„scheduler_shopware“ kenne ich persönlich nicht, verwende dafür:
bin/console scheduled-task:run --time-limit=60 --memory-limit=512M

@jeje1 Meinst du so?

bin/console messenger:consume async --time-limit=60 --memory-limit=1024M
bin/console messenger:consume async --time-limit=60 --memory-limit=1024M
bin/console messenger:consume async --time-limit=60 --memory-limit=1024M
bin/console messenger:consume async --time-limit=60 --memory-limit=1024M
bin/console messenger:consume async --time-limit=60 --memory-limit=1024M

bin/console messenger:consume low_priority --time-limit=60 --memory-limit=1024M
bin/console messenger:consume low_priority --time-limit=60 --memory-limit=1024M

bin/console messenger:consume failed --time-limit=60 --memory-limit=1024M
bin/console messenger:consume failed --time-limit=60 --memory-limit=1024M

Brauchen wir hier wirklich die Option --time-limit? Selbst wenn ich das Speicherlimit auf 3072 MB (3 GB) eingestellt habe, tritt außerdem gelegentlich die folgende Fehlermeldung auf:
„PHP Fatal error: Allowed memory size of 3221225472 bytes (3GB) exhausted“.
Vor diesem Hintergrund glaube ich nicht, dass der Worker mit einem Speicherlimit von nur 1024 MB (1 GB) effektiv funktionieren wird. Ich empfehle, das Speicherlimit für jeden Prozess auf mindestens 5 GB zu erhöhen. Was denken Sie darüber?

Kann das gleichzeitige Ausführen mehrerer Messenger:Consume-Prozesse in Shopware über Supervisor möglicherweise zu Konflikten führen? Irgendeine Idee dazu?

Theoretisch ist es so wie du es oben aufgeführt hast, das öfter „bin/console“ etc. ausgeführt wird, nur halt über systemd mit einem service.

Aktuell habe ich 130.500 Produkte die regelmäßig aktualisiert werden, jedoch nur gefühlt 5-10 Kategorien, da alles über dynamische Produktgruppen verwaltet wird. Kategorien empfinde ich seit dem es die dynamischen Produktgruppen gibt als überflüssig.
Ich kann daher nur für mein Projekt sprechen. Es sollte dir lediglich als Referenz dienen.

–time-limit ist damals zum Zeitpunkt der Konfiguration die Empfehlung gewesen, wird vermutlich seinen Grund haben, hier ebenfalls mit einem time-limit zu sehen: Message Queue | Shopware Documentation

Die PHP Fehlermeldung könnte ganz normal sein, da halt das memory-limit erreicht wurde.

Es ist nicht wichtig das Speicherlimit eines Workers auf bspw. 10 GB zu setzen. Der Worker verarbeitet kleine Aufgaben aus der Warteschlange und nimmt sich dann der nächsten an.
Es gibt meines Wissens keine Aufgabe die 3 GB RAM erfordert.

Mehrere Prozesse gleichzeitg auszuführen ist kein Problem. Jeder Worker nimmt sich einer anderen Aufgabe an, ohne dieselbe Aufgabe gleichzeitig zu verarbeiten.

Das Problem gab es hier vor ein paar Wochen schon mal, das bei der Änderung einer Kategorie alle neu indiziert werden. Bin mir nicht sicher, ob das wirklich nötig ist bzw. ob das nicht eine Nummer kleiner ginge. Supervisord wird ja von Shopware bzw. Symfony für die Worker empfohlen, sollte also passen. Es gibt in der Doku von Symfony aber einen Hinweis in Verbindung mit Redis, das man die Worker eindeutig benennen soll, da es sonst passieren kann, das Aufgaben von mehreren Workern gleichzeitig bearbeitet werden:

If you use the Redis Transport, note that each worker needs a unique consumer name to avoid the same message being handled by multiple workers. One way to achieve this is to set an environment variable in the Supervisor configuration file, which you can then refer to in messenger.yaml

Und wenn der ins Speicherlimit läuft, dann würde ich ihm mehr geben. Schwierig wird es, wenn er mit allem, was geht, trotzdem ins Limit läuft.

Ich würde behaupten, dass wenn es bspw. 1 oder 10 Worker gibt, die jedoch 10.000.000 Aufgaben erledigen müssen, diese Worker ohne --time-limit früher oder später IMMER das memory-limit erreichen.

Daher lieber ein time-limit setzen und neustarten.
Darauf sind die Worker ausgelegt, dass wenn sie korrekt eingerichtet wurden, an der Stelle weiterarbeiten, wo sie aufgehört haben.

Die Frage ist, ob 1,5 Millionen Kategorie-Indizierungen in mehreren Aufgaben liegen oder in einer. Hatte so extreme Fälle noch nicht.

Ich vermute, dass bei mehreren Aufgaben, wie dem Aktualisieren/Einfügen von Kategorien, die Unterkategorien usw. indiziert werden

Ok, dann setze ich ein Zeitlimit und überprüfe es

Ok, ich werde es überprüfen, danke für die Info.

Hi @Anotherone

Ein Zweifel, wir haben ein Zeitlimit von 60 Sekunden festgelegt und eine Aufgabe benötigt 120 Sekunden, um sie abzuschließen. Wird der Vorgang dadurch abgebrochen oder wird derselbe Vorgang bei der nächsten Ausführung fortgesetzt? Irgendeine Idee dazu

Vielleicht ist auch der Webserver zu langsam. Was steht dann an Blech (Hardware) dahinter? Basierend von Ausgangspost ist das keine kleine Installation.

Auch mal Shopware direkt dazuholen, da so viele Kategorien und Kanäle sicherlich nicht alltäglich sind.

1 „Gefällt mir“

Okay, lass es mich überprüfen

Ich bin mir ehrlich gesagt nicht sicher, ich hab mir die Worker noch nie angesehen, wie die intern arbeiten. Weiß das jemand zufällig? Sonst schau ich mir den Code mal an.

1 „Gefällt mir“

verbindet euch mithilfe von bspw. Putty per SSH und dann einfach mal folgendes eingeben:

„bin/console messenger:consume -help“

dann seht ihr, dass es bspw. die Option „verbose“ gibt, das heißt ihr könnt bspw.:

„bin/console messenger:consume async -vvv“ angeben, um alles zu sehen was ein worker gerade so macht. -vv um weniger zu sehen und -v nur das nötigste.
Die Aufgaben dauern keine 60 Sekunden. Solange die Warteschlange abgearbeitet wird, ist alles in Ordnung.

bin/console messenger:consume -help
Description:
Consume messages

Usage:
messenger:consume [options] [–] […]

Arguments:
receivers Names of the receivers/transports to consume in order of priority

Options:

-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

@jeje1 , Vielen Dank für die Antwort, ich werde es mit der VV-Option überprüfen. Aber ich habe das Zeitlimit von über 60 Sekunden immer noch verwechselt.

Wenn ich eine geplante Aufgabe geschrieben habe, um eine große Menge abzurufen
Wenn Sie Produktdaten von der API eines Drittanbieters beziehen, dauert dieser Abruf- und Einfügevorgang alle 1 Stunde 5 bis 10 Minuten

Dann wird die Aufgabe 1 Minute lang ausgeführt und angehalten, und sie wird erneut 1 Minute lang ausgeführt und angehalten. Dann können wir die vollständigen API-Daten aktualisieren

Das Zeitlimit bezieht sich auf den Worker, nicht auf eine geplante Aufgabe.

Es gibt nicht nur eine Aufgabe für eine große Aufgabe die erledigt werden muss.

Wenn ich 100.000 Preise aktualisiere, könnten daraus X Aufgaben resultieren.
Ich weiß nicht wie genau das umgesetzt wurde, ob es per „payload“ ist, daher kann ich nicht zu sehr ins detail gehen.

Wenn ich bspw. einen Artikel mit Eigenschaften in einem request anlege, könnte die 1. Aufgabe das Anlegen sein und die 2. Aufgabe Eigenschaft ggfs. erstellen, 3. Aufgabe Artikel<->Eigenschaften verbinden.

In RabbitMQ hat man eine Übersicht wo man die queue sieht und wenn man bspw. einen SEO-Index neuerstellt, sieht man dort „n“ Aufgaben und nicht nur eine.
Der Prozess „Index erstellen“ wird in ganz viele Teilaufgaben unterteilt, sodass es am Ende viele kleine Aufgaben sind und nicht eine große.

SEO Eintrag/Index für Artikel 1
SEO Eintrag/Index für Artikel 2


Um auf das Beispiel einzugehen, bräuchte ich weitere Informationen was genau eingefügt wird.
Nehmen wir an Preise. Wenn ich Preise aktualisiere, mache ich das in einem payload Array mit der Sync API.
Als Beispiel in 100er Schritten, sodass die API nicht überfordert wird und die Anfrage schnell bearbeiten kann.
Aus diesen 100 payloads werden dann X Aufgaben in die queue gepackt und das wird dann nach und nach verarbeitet.

1 „Gefällt mir“

Ich kann dir leider keine Antwort darauf geben, ob die geplante Aufgabe abgebrochen wird.

Die queue und geplante Aufgaben sind eigentlich zwei unterschiedliche Dinge:

Geplante Aufgaben können die Warteschlange befüllen, um gewisse Prozesse nicht zu blockieren oder ressourcenschonend zu arbeiten.

Daraus würde ich ableiten, dass wenn die geplante Aufgabe läuft, diese auch solange läuft, bis die geplante Aufgabe durch ist.

Aus der geplanten Aufgabe sollten dann ganz viele Einträge in der queue entstehen.

1 „Gefällt mir“