@Rakowu
Leider scheint das Thema bei Shopware keine hohe Priorität zu haben, obwohl das für viele Kunden ein Totschlagkriterium ist.
Wie bei euch werden auf das Thema wohl viele Kunden auch erst nach einer gewissen Zeit stoßen, wenn der Shop ein wenig wächst.
Ihr könnt eventuell beim Import den „searchKeywordUpdater“ ausschalten - der verursacht die schlimmen memory leaks.
Diesen aber nur bei Produktupdates ausschalten und nicht, wenn die Keywords wirklich auch einen Index bekommen sollen. Also der erste Import mit Beschreibung, Titel usw. sollte durchlaufen - was natürlich bereits eine Herausforderung darstellt und wir deshalb das memory_limit auf 32GB setzen mussten…
Wenn man den Import per Headless oder eigenen Script macht und nicht in einem Durchlauf, sondern schrittweise, dann lässt sich das Problem recht einfach umgehen.
Unabhängig davon, ja, der Fehler gehört dringend behoben.
Tatsächlich habe ich Antwort von Shopware bekommen… (Entwickler Support), leider bekomme ich keine Unterstützung da wir kein Blackfire und Tideways auf unseren Server installiert bekommen (keine Root rechte). Die Antwort :
ich habe mit unseren Entwicklern Rücksprache gehalten. Solange wir die angeforderten Tools/Daten nicht erhalten, können wir keine nähere Analyse durchführen. In diesem Fall muss auf einen Fix über besagtes Issue Ticket abgewartet oder aber eigenständig ein Fix implementiert werden.
Also mal über ein Jahr später und ich finde diesen Thread hier und hab schon gehofft hier wäre eine Lösung verzeichnet.
Bei mir läuft der Speicher immer noch voll bei einem upsert im EntityWrittenContainerEvent. Und zwar auch, wenn ich Chunks verwende, ich schaffe kaum 100 Artikel… wir haben aber auch mal über 10k.
Ich habe das Problem mit dem Speicherüberlauf auch bei „einfachen“ Importen, bei denen nur der Bestand oder der Preis geändert wird.
Da unsere Wawi die ID der Artikel nicht kennt arbeiten wir mit der Artikelnummer in den CSVs. Kann es sein, dass die Suche nach der ID den Import stark beeinflusst?
Weiterhin habe ich auch keine spezifischen CSVs, welche nur die notwendigen Werte enthalten. Da sind mehrere Spalten an Werten die der Shop nicht benötigt. Weiterhin auch Produkte die nicht im Shop vorhanden sind. Muss ich da wirklich eine „Vorverarbeitung“ einbauen und allen Schmodder vor dem Import entfernen?
Dann kann ich ja gleich den Preis und den Bestand direkt in die Datenbank schreiben…
Dachte eigentlich das diese Zeiten mit SW6 vorbei sind und die Bordmittel ausreichen.
Also wäre die Lösung, dass man kein Plugin selber schreiben sollte, um Produkte zu importieren, sondern nur die API nutzen kann, weil ansonsten der Speicher vollläuft im Plugin?
Oder genauer gesagt, man verwendet die API dann auch in Import/Export Plugins?
Was ist, wenn Funktionen in der API fehlen? Dann lieber die Shopware API innerhalb des Plugins erweitern?
Die komplette Administration basiert auf der API, auch viele Teile der Storefront.
Du wirst also sehr wahrscheinlich keine Funktionen finden, welche die API nicht erfüllt.
Ich persönlich bereite die Daten außerhalb von Shopware per PHP so auf, dass ich die Daten nur noch an die API übergeben muss.
Das Script lädt nach und nach Daten und überträgt diese dann auch etwas Zeitversetzt, um den Server nicht auszulasten.
So hast du am meisten Kontrolle über die notwendige Performance. Wenn du Index etc. in der API deaktivierst, dann kannst du dies nach dem Upload ausführen lassen.
Dadurch benötigst du sowohl CPU als auch RAM um ein vielfaches weniger.
Und klar, wenn du etwas spezielles hast, dann kannst du auch die API selbst erweitern oder sogar DAL durch SQL ersetzen.
Das würde dann konkret bedeuten, dass die internen php Shopware Objekte (EntityRepository für Produkt, Preis, etc.) zwar sehr schön ausgelagert sind, aber mehr Speicher verbrauchen, als wenn man von „außen“ die API verwendet?
Bisher erschien es schon sinnvoll einen Import über CLI zu fahren, da es dafür so viele schöne Services und Objekte gibt.
Am Ende wird die API ja intern die selben Methoden/Objekte verwenden, ansonsten wäre dies ja nicht wirklich sinnvoll (also intern in Shopware doppelte Funktionen bereit zu stellen).
Nein, es ist eher die Art, wie der Upload verarbeitet wird. Je nach Produktkomplexität (Varianten, Eigenschaften, Bilder, Preise, etc.) lädt Shopware meiner Meinung nach bei schwach ausgestatteten Servern zu viel Daten auf einmal und kommt so zur Auslastung des RAM. Wenn ich weiß, dass ich eher komplexere Produkte habe, dann kann ich darauf eingehen.
Das ist aber nur eine Optimierung, die sich wirklich lohnt, wenn man wirklich unter der Upload-Funktion „leidet“. Ich hatte Kunden, da hat der Excel Upload 5 Stunden benötigt. Über die API 30 Minuten. Nicht da die API großartig anders ist, aber die Daten in für den Server angepassten Blöcken vorlegt, so dass CPU, RAM und MySQL nicht maximal ausgelastet sind und dadurch den ganzen Prozess verlangsamen.
Wie gesagt, das ist meine persönliche Vorgehensweise. Die ist überall individuell zu wählen. Ich habe auf den Post nur geantwortet, da der „Speicherfresse“ bemängelt wurde und ich eine andere Möglichkeit aufzeigen wollte.
Und wenn du ganz große Sachen hast und auf Perfomance angewiesen bist - wirst du (zumindest in Teilen) um DAL/reines SQL nicht herumkommen. Ist durchaus auch Gang und Gebe bei größeren Projekten.
Schwach ausgestattet ist gut Ich habe es testweise mal auf maximal 512 MB begrenzt zum Testen. Aber es geht hier um viele Tausende Produkte beim Import und ich denke mal ein Abbruch, nachdem 2 GB an RAM voll sind, ist nicht wirklich zielführend
Am liebsten würde ich natürlich weiterhin die internen Funktionen mit „Chunks“ verwenden, also auch in Blöcken aufteilen.
Ich verstehe aber, was du meinst bei der API.
Jo, wenn ich eh dabei bin mir eigene Klassen in einem eigenen System für die Nutzung der Shopware API zu basteln, kann man da natürlich auch direkt noch die SQL-Anbindung mit einfügen, wenn es die API nicht ausreichend tut.
Ich habe es testweise mal auf maximal 512 MB begrenzt zum Testen. Aber es geht hier um viele Tausende Produkte beim Import und ich denke mal ein Abbruch, nachdem 2 GB an RAM voll sind, ist nicht wirklich zielführend