Scheduled-Tasks füllen den RAM komplett aus

Hallo Zusammen,

aktuell stehe ich vor dem Problem, dass die Scheduled-Tasks (speziell der product.indexer = Produktindexierung) nicht abgearbeitet werden können. Verwendet wird ein CLI-Worker; der Admin-Worker ist deaktiviert. Eingerichtet wurde das ganze nach folgender Anleitung: https://community.hetzner.com/tutorials/install-shopware-6#step-6---configuring-background-queue-worker

Mittels glances sehe ich auf dem Server, das er hier für den messenger:consume - Befehl sich den kompletten RAM (30GB!) nimmt. Der Server killt den Task letztendlich (logischerweise), abgearbeitet ist er dann nicht. Vorab: An den Tasks wurde nichts verändert, es handelt sich um die SW6 Standard-Tasks.

Daher die Frage: Warum verbraucht er beim Indexieren so viel RAM und kann man das irgendwie „charmanter“ lösen?

Vielen Dank vorab für euere Unterstützung!!
LG
Mirco

läuft Dein SW im DEV- oder PROD-Mode?

Der Shop läuft im Prod-Modus

Dann fällt schon mal eine möglich Ursache weg. Auf die Schnelle fällt mir jetzt aber nix ein, müsste ich mir mal genauer ansehen.

Das wäre euch super! Vielen dank dir schonmal. Wie gesagt es ist speziell der product.indexer = Produktindexierung Task. Warum auch immer, frisst er unmengen an RAM.

FYI - Wir haben ca 100 Produkte mit Varianten sind es dann ca 14000 Produkte.

LG

hast Du mal versucht, den indexer ohne „worker“ auf der console laufen zu lassen?

Ja, gleiches Phänomen: RAM läuft irgendwann voll.
Habe mal den indexer mit dem Befehl: bin/console dal:index:refresh --skip=product.indexer -vv
ausgeführt. Ergebnis: 30 Sekunden Laufzeit, ca 3-4 Gig RAM.

also, dass was mir auffällt ist, dass der „indexer“ welchen ich in einem eigenen plugin verwende „dal:refresh:index“ lautet. Und nicht „index:refresh“ → aber vielleicht spielt das ja auch keine Rolle. Kannst ja mal bin/console aufrufen um nachzusehen. 2. Schreibt Dir der Indexer Dein Log voll? wenn ja, gibt doch mal --quiet=true als Parameter mit. Was ich noch verwende ist „–use-queue=true“. Möglicherweise ändert das ja auch etwas. Ich habe zwar mehr Hauptprudukte und weniger Varianten als Du und komme in der Gesamtzahl auch auf weniger Einträge, aber der Indexer spielt RAM-seitig bei mir fast keine Rolle.

Nur, um Mißverständnisse zu vermeiden (auch in Slack hatte das ja jemand gefragt )… in Deiner „.env“ steht „APP_ENV=prod“ drin. Richtig?

Ja in der .ENV steht PROD.

Hier ein Bild der aktuellen RAM Auslastung:

Das Problem ist, dass er die queue nicht abarbeitet augenscheinlich.

wie schon geschrieben, wenn Du nur console ohne parameter im bin ausführst solltest Du eine Liste aller möglichen commands bekommen. Das aktuell von Dir verwendete (ohne Parameter) sollte so dabei sein. Deine ursprüngliche Nachricht im Slack hat das schon gezeigt, dass der dem PHP zugewiesene Speicher überläuft. Ist meistens halt im DEV-Mode so, weil alles SQL-Commands mitgeschrieben werden

@moschadr: Leider verstehe ich deine Antwort jetzt nicht so ganz. Mein System ist Produktiv und in der Datei .env im Hauptverzeichnis ist auch APP_ENV=PROD hinterlegt. Der Consumer schafft anscheinend die Verarbeitung nicht, weil er maximal viel Speicher benötigt. (Bei fast 50GB pendelt er sich ein - siehe Screenshot)
Wie bekomm ich es jetzt also hin, dass er die Tasks abarbeitet, ohne das der Speicher permanent voll läuft? Hierfür muss es doch eine Lösung geben?
In den Logs vom Shop steht regelmässig drin, dass er nicht genug Speicherplatz zur Verarbeitung hat und deswegen abbricht.
Wie machen das denn größere Shop-Betreiber mit Millionen von Produkten, bei mir sind es doch gerade mal 14K Produkt-Varianten.

@Moritz_Naczenski: Hättest du hier eventuell eine Lösung?

LG
Mirco

Ich versuch nur, mögliche Ursachen zu ermitteln. 1. Den Prozess für für das Refreshen des index gibt es auch ohne messanger:consume. Folglich bestünde doch die Möglichkeit, dass nicht del:refresh sondern messanger:consume Ursache ist. Also würde ich zur Eingrenzung den messanger erstmal weglassen. 2. wie Du geschrieben hast, rufst Du (mit selbem Ergebnis) dal:index:refresh auf. Jedenfalls in meiner console gibt es den Parameter so nicht. Sondern nur refresh:index (Paramter umgedreht). Das könnte - nur eine Vermutung - auch ein Teil des Problems sein. Zudem lassen sich an den Prozess weitere Parameter wie „quiet“ und/oder „use-queue“ übergeben, die vielleicht auch Einfluss auf den Speicherbedarf haben könnten. Die wiedeholte Nachfrage nach APP_ENV kommt nur daher, dass es schon Posts gabe, bei denen ein User unter Produktivsystem verstand, dass der Shop online aktiv, also produktiv ist und nicht mehr als Entwicklungssystem dient

Aber der Befehl refresh:index mit dem Parameter „use-queue“ befüllt die Warteschlange. Wohingegen der Befehl „messenger:consume“ diese Warteschlange abarbeitet. Oder?

Habe jetzt nochmal RAM nachgelegt und versuche es über den „refresh:index“ Befehl. Diese indexer müssen doch vermutlich in Zukunft öfter mal gebildet werden. Das stelle ich mir aber schwierig vor, wenn diese jedesmal den RAM voll pusten.

ja, da hst Du Recht. Der Speicherbedarf DARF gar nicht in diese Höhe schnellen. Wenn die BasisDaten fehlerfrei sind und sonst auch alles richtig eingestellt ist sollte ein Bruchteil Deines aktuell benötigten Speichers ausreichen

Aber , da SW noch einige Baustellen hat, kommt man nicht drum rum mögliche interne Bugs irgendwie zu identifizieren und zu umschiffen

@moschadr Vielen Dank nochmal für deine Antworten. Allerdings hilft mir das nicht so recht weiter.

Fakt ist: Der Prozess benötigt eine große Menge an Arbeitsspeicher und es ist nicht ersichtlich warum dies so ist.

Eventuell hat ja jemand anderes dieses Problem schon einmal gehabt. @AndreHerking: Ist dir hier etwas bekannt?

Vielen Dank!!
LG Mirco

Vielleicht läuft der Shop im prod, aber der cli worker im dev? Ich meine eine Indexierung kann mal etwas länger dauern, aber nach jedem indexierten Datensatz wird der Speicher geleert… also entweder befindest du dich im dev Modus oder dein SQL Logger ist trotz prod aktiv?!

$this->connection = $connection;
$this->connection->getWrappedConnection()->setAttribute(\PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false);
$this->connection->getConfiguration()->setSQLLogger(null);

Oder ist beim Datenbank Server ein Logger aktiv?
https://dev.mysql.com/doc/refman/8.0/en/query-log.html

Ansonsten einfach mal diesen Befehl probieren:

APP_ENV=prod php bin/console dal:refresh:index

Bei der Produkt-Indexierung werden soweit ich sehe alle Parent und Children Ids auf einen Schlag geladen und entsprechend verarbeitet!

Das multipliziert mit 50 kann schon auf den Speicher gehen.

Entspricht in diesem Bsp. also ca. 7000 Produkte auf ein mal?!

Also den Wert einfach manuell auf 1 statt 50 setzen könnte auch helfen.

VG

1 Like

Hey @Moorleiche,

sorry bin dir hier noch eine Antwort schuldig! Danke erstmal für deine Hinweise, aber habe das Problem jetzt anders gelöst. Wobei von Lösung hier eigentlich keine Rede sein kann.
Auf Grund der hohen Anzahl an Varianten ist es unmöglich diese zu Indexieren ohne den Shop lahm zu legen. Daher bin ich hin gegangen und Indexiere nun nur noch die erste unter Variante die er findet. Bestimmt nicht schön, geschweige denn richtig allerdings läuft so die Warteschlange mal durch und er crashed nicht immer bei den Produkten. Hab im Vendor die Funktion angepasst:
image

Wusste mir tatsächlich hier nicht anders zu helfen…

LG Mirco

1 Like

Ich mische mich mal etwas mit ein…

16:21:04 INFO      [messenger] Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage was handled successfully (acknowledging to transport). ["message" => Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage^ { …},"class" => "Shopware\Core\Content\Product\DataAbstractionLayer\ProductIndexingMessage"]
16:21:04 INFO      [messenger] Stopping worker. ["transport_names" => ["default"]]
16:21:04 INFO      [messenger] Worker stopped due to memory limit of 34359738368 bytes exceeded (120001134592 bytes used) ["limit" => 34359738368,"memory" => 120001134592]

Ich habe den Speicher des Cronjob auf 32 GB limitiert, was dezent ignoriert wurde, bei 120 GB (von 128 GB) war‘s aber vorbei.

Ich habe nun die „IteratorFactory.php“ auf „$query->setMaxResults(10);“ gesetzt und er scheint mit ca. 5 GB klar zu kommen…