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
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.
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.
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.
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
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?!
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:
Wusste mir tatsächlich hier nicht anders zu helfen…
