Nachdem ich vor ca 2 Wochen eine größere Menge Artikel (ca 60k) importiert habe taucht jedes mal wenn ich ins Backend gehe folgende Meldung auf (mit sinkender Anzahl):
Kategorie-Indexierung
Circa 891350 Kategorien verbleibend …
Vorschaubilder werden generiert
14699 Bilder verbleibend …
Ich vermute das Indexieren passiert nur wenn ich im Backend bin (und wenn wer im Frontend unterwegs ist?). Deshalb zieht es sich vermutlich so lange hin. Ich denke es würde deshalb Sinn machen eventuell per Cronjob die Indexierung im Hintergrund laufen zu lassen. Wie würdet ihr da am besten vorgehen?
Hi, die Meldungen haben erst mal nicht viel zu bedeuten, sind aber ein Hinweis auf einen Prozess, der irgendwie bzw. irgendwann abgebrochen ist bzw. ständig erneut abbricht. Dann hast Du bestimmt noch den Admin-Worker aktiv, der ständig u.a. die Tabelle increment abfragt. Aus dieser kommen u.a. die Zahlen.
Ich/wir haben den SW eigenen Indexer abgeschaltet und uns dafür ein Command-Plugin gebaut, dass regelmäßig via Cron angesteuert wird.
Das Hauptproblem vom SW-Indexer ist, dass sämtliche Last ins PHP verlagert ist. Die DB langweilt sich, PHP schwitzt und führt Arbeiten aus, die eigentlich von der DB viel schneller und besser erledigt werden könnten. Aus diesem Grund geht unnötigerweise der Bedarf an RAM und CPU hoch. Zudem sind einige der Methoden nicht auf Sparsamkeit ausgelegt. Belegter Speicher wird nur unzureichend wieder frei gegeben. Und an anderern Stellen werden riesige Arrays/ Objekte aufgebaut. Aus meiner Sicht, wenn die Aufgaben zwischen PHP und der DB besser verteilt wären, absolut unnötig.
Neben den RAM und CPU Problemen waren bei uns tatsächlich deadlocks der DB und deadmessages ein Problem. Die deadmessages kann man mit einem Decorator umgehen und ein umstieg von DB messages auf RabbitMQ hat uns da sehr geholfen - allerdings brachte uns das mit unseren 10Mio Produkten nicht VIEL weiter. Weg von DB messages auf RabbitMq oder Redis würde ich in jedem Fall gehen.
Danke, das war hilfreich. Ich hab den Admin Worker jetzt über die .yaml abgeschaltet und einen Cronjob für die Tasks eingerichtet. Danach hatte ich noch die cache gelöscht, die Meldungen zur Indexierung erscheinen aber weiterhin im Backend. Heißt das, der Admin Worker läuft noch?
Nein, ich glaube das ist einfach ein genereller Stand zu den Messages und deren Verarbeitung (Auch wenn ich den sehr hoch erscheinenden Zahlen nicht auf den Grund gegangen bin)…der AdminWorker ist deaktiviert wenn du ihn eben in der yaml-config deaktiviert hast.
Danke, ich vermute da läuft irgendwo was bei der Indexierung der Kategorien und der Bilder schief. Nachdem die Anzahl der zu Indexierenden Kategorien und Bilder zu beginn, nach der Einrichtung der Worker als cronjob, stetig sinkten hängt er jetzt bei 13050 Kategorien und einem verbleibenden Bild fest. Bisher konnte ich aber noch nicht feststellen was das Problem ist.
Die Anzeige habe ich bisher nicht in den Griff bekommen. Es werden ständig haufenweise Kategorien angezeigt die noch Indexiert werden sollen. Aktuell 2’415’350, dabei hat der Shop nur etwa 200-300 Kategorien.
Aber die langsamen Zugriffszeiten auf die Kategorien habe ich nun gelöst bekommen, indem ich die Kategorien alle 15 Minuten per Skript aufrufen lasse. Das scheint die Kategorien dauerhaft im Cache zu halten und die Zugriffszeit reduziert sich allgemein von 30 Sekunden auf ca 1 Sekunde.
Hi, bei mir im Shop habe ich auch ein Problem mit der Produkt-Indexierung.
Circa 540000 Produkte verbleibend …
Kategorie-Indexierung
Circa 99200 Kategorien verbleibend …
Ich habe weder 540.000 Produkte noch habe ich 99200 Kategorien in meinem Shop. Der Shop ist sehr langsam, wenn die Produkte und Kategorien indexiert werden. Die Startseite lädt über 10 Sekunden im Peak…
Also muss ich nun den Admin Worker über die .yaml abschalten und einen Cronjob für genau welche Tasks einrichten?
Scheinbar haben die Probleme viele Nutzer hier.
Ist es realistisch, dass Shopware hier aktiv wird und einen Fix bereit stellt?
Ich vermute dass sich die hohe Kategorie Indexierung durch ein rekursives neu Indexieren der Unterkategorien ergibt.
Lädt die Startseite bei dir auch noch so lange wenn du sie kurz danach von einem anderen Gerät oder Browser aus besuchst?
Ich habe festgestellt dass die Seiten nach dem ersten langen Laden eine Zeit lang schneller laden (auch von anderen Geräten aus). Ich habe deshalb ein paar Cronjobs eingerichtet die die Startseite und die Hauptkategorie regelmäßig abruft.
Jedes Mal wenn ich etwas an den Daten ändere, Bestände aktualisiere usw… fängt der Shop wieder an mit der ewigen Indexierung…was den Shop im Frontend langsam macht… und vermutlich auch alles andere.
Kann es sein, dass wegen der ewigen Indexierung auch der Abgleich von Warenwirtschaft zu Shopware langsam wird? Vor einigen Monaten war der bei uns mehr als doppelt so schnell wie jetzt.
Beispiel: für ca. 10000 Artikel benötigt der Abgleich jetzt über 20 Stunden.
Wir benutzen JTL-Wawi und Shopware 6. Grundsätzlich ist beim Abgleich die Datenbank des Shops das Bottleneck für die Performance.
Zu dem Thema Warenwirtschaft kann ich nichts sagen. Wir haben den Shop nie traditionell an die WaWi angeschlossen weil der Shop bei der großen Artikelzahl kaum zu gebrauchen ist. Aktuell sind unsere wichtigen Produkte noch bei einem anderen Shop System. Ein kompletter Wechsel nach Shopware6 war angedacht, aber liegt aufgrund der Probleme erstmal auf Eis.
Um die ewige Indexierung zu beenden habe ich die Tools Erweiterung von Friends of Shopware installiert. Damit kann man einfach Warteschlange zurücksetzen. Jetzt ist die Performance in meinem Shop ist wieder in Ordnung.
In 45-60 Minuten 30k Produkte zu importieren ist schnell. Ich hatte in der Vergangenheit auch ein Tool auf Basis der Shopware REST API (Admin API) geschrieben. Das war deutlich langsamer (ca 1-2 Sekunden pro Produkt). Hast du das auch über die REST API gemacht oder auf anderen Wege?
Ein Problem wurde dann auch der Bestands Sync. Bei 100k+ Produkten die Bestände per API zu updaten war zu langsam und wenn man sie direkt in der Datenbank aktualisiert werden sie nicht zuverlässig zeitnah im Frontend übernommen.
Hatte hier auch ähnliche Probleme und zusammen mit diesem Thread und mit Unterstützung des Supports von all-inkl.com ist es gelöst. und somit möchte ich als Zusammenfassung meine Lösung an euch zurückgeben.
Problem war beim Ausführen von
php bin/console dal:refresh:index
diese Fehlermeldung: Error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 1503232 bytes)
Der Hinweis durch diesen Befehl das Memorylimit abzuschalten mit:
php -d memory_limit=-1 bin/console dal:refresh:index", bzw. auf 512MB zu erhöhen:
php -d memory_limit=512M bin/console dal:refresh:index
löste das Problem temporär.
Bei All-inkl.com ist standardmäßig 256MB eingestellt:
Abfrage mit: php -i | grep memory_limit
schau ob sich etwas verändert. Nach meiner Erfahrung nicht.