admin frißt bei uns 100% CPU pro angemeldetem Mitarbeiter.

Hallo,

wir haben die v6.3.2.0 Stable Version, sind aber noch nicht online mit dem Shop, zum Glück.

Bei uns ist es so, daß pro angemeldetem Mitarbeiter im admin eine CPU bzw. eben ein Thread fast zu 100% ausgelastet ist

und das bleibt auch so, solange der Mitarbeiter dort angemeldet ist, sprich theoretisch über Stunden.

Wir haben keine sonstigen Cron-Jobs laufen, an aktiven Plugins nur die “CMS-Erweiterungen für Shopware 6”, sonst nichts.

Und er ist auch im Produktiv-Modus und es wird auch kein Cache/Indizes oder sonstiges erzeugt.

Ist aber auch bei mir in der Entwicklungsumgebung so, da habe ich gar keine Plugins aktiv,

Ist auch so wenn ich im Produktivmodus bin.

Ist das bei Euch nicht so?

Woran kann das liegen?

Gruß,

Werner.

Hallo,

okay, es gibt da seit 26.08 ein Ticket im Issuetracker, hat sich aber scheinbar bisher nichts verbessert, zumindest bei mir,

ist auch an sich schon lange so.

https://issues.shopware.com/issues/NEXT-10505

Scheint auch ziemlich unabhängig von der eingesetzten Server-Software zu sein, dort ist es Nginx, beim mir der Apache.

Ist auch egal, ob man Firefox oder den Chrome/Chromium benutzt.

Gruß,

Werner.

Moin Werner,

hatte bis eben auch High CPU Load, nur wenn ein Admin im Backend war.

Ich verwende ISPConfig 3 und habe mir das mal eben angeguckt, da ich im HTOP auf dem Server einen total langen Pfad für den PHP Interpreter hatte .

Nun habe den PHP open_basedir (bei ispconfig unter domain und dann Options) mal angepasst und Verzeichnisse raus geschmissen, die ich da nicht drin haben wollte und die Ordner die es auf dem Server gar nicht gibt.

Und plötzlich… keine 98% CPU Last mehr.

(Update während des Posts) CPU ist wieder auf Hig Load, wenn sich ein 2. Admin einloggt

In meinen Konkreten fall war das vorher:

/var/www/clients/client1/web1/web:/var/www/clients/client1/web1/private:/var/www/clients/client1/web1/tmp:/var/www/*****.de/web:/srv/www/*****.de/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin:/dev/random:/dev/urandom

Angepasst:

/var/www/clients/client1/web1/web:/var/www/clients/client1/web1/tmp:/var/www/*****.de/web:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin

 

Allerdings… läuft Shopware 6 nicht gut rund, beim Bilderhochladen und dann Bilder auswählen, zuwesein etc. hängt es sich auf (dachte es liegt an der hohen CPU Last)

Meine Specs: Shopware v6.3.2.0 Stable Version

Umgebung: Debian 10, PHP 7.3.19,  Apache/2.4.38, MariaDB 10.3.23
php.ini (all green) + momory_limit 512M

Debian 4.19.132-1 (2020-07-24) x86_64

 

Ich werde gleich mal das Hotfix v6.3.2.1 einspielen
(Update: hat keine veränderung gebracht)

Hallo,

an open_basedir liegt das nicht, zumindest nicht bei mir.

Wie in dem Ticket im IssueTracker an sich ja auch schon erwähnt, liegt das an dem ‘…_action/message-queue/consume’,

also diesem hier:

https://github.com/shopware/platform/blob/429e58ddd0f33c69f54914696c1aa2900315fe94/src/Core/Framework/MessageQueue/Api/ConsumeMessagesController.php#L73

Bzw. da dann an dem Worker…warum auch immer…

Gruß,

Werner.

Ich würde eh empfehlen auf den CLI Worker umzusteigen, da die Abhängigkeit von „User muss eingeloggt sein“ am besten aufgelöst werden sollte.

Hier ist das zum Beispiel für Hetzner beschrieben: https://community.hetzner.com/tutorials/install-shopware-6#step-6---configuring-background-queue-worker

1 Like

Hallo,

ja, lustig, wir hatten jetzt zeitgleich auch auf Slack das mit dem ‚enable_admin_worker: false‘ gesehen,

allerdings ist das Beispiel auf Hetzner ausführlicher und besser, danke für den Link.

BTW. noch eine Frage: kann man die Kombination Nginx und Shopware 6 so wie im Beispiel bei Hetzner empfehlen?

Gruß,

Werner.

@Moritz Naczenski schrieb:

Ich würde eh empfehlen auf den CLI Worker umzusteigen, da die Abhängigkeit von „User muss eingeloggt sein“ am besten aufgelöst werden sollte.

Hier ist das zum Beispiel für Hetzner beschrieben: https://community.hetzner.com/tutorials/install-shopware-6#step-6—configuring-background-queue-worker

Also man davon abgesehen, dass ich das nicht 1:1 auf mein Debian umsetzten konnte, scheint das nicht zu laufen. Jetzt habe ich zwei Prozesse, die auf High Load laufen…

Einmal den normalen und den neu erstellten.

Bringt das was, wenn ich von Fast-CGI auf Mod-PHP oder PHP-FPM umsteige? 

@WernerBu schrieb:

Hallo,

ja, lustig, wir hatten jetzt zeitgleich auch auf Slack das mit dem ‘enable_admin_worker: false’ gesehen,

allerdings ist das Beispiel auf Hetzner ausführlicher und besser, danke für den Link.

BTW. noch eine Frage: kann man die Kombination Nginx und Shopware 6 so wie im Beispiel bei Hetzner empfehlen?

Gruß,

Werner. 

 

Du kannst auch Nginx nutzen, hier gibts bspw. eine Beispielkonfiguration: shopware-docker/10-platform.conf at master · shyim/shopware-docker · GitHub

Generell ist das eher eine Philosophie-Frage. Nginx hat sicherlich seine Vorteile, bei Apache bekommt man meist über die .hatccess schon eine Konfiguration mitgeliefert. Kann man aber beides gut einsetzen.

1 Like

Äh… sorry mal eben BTT…

Ich habe einen vServer der 2 Cores hat und beide sind fast die ganze Zeit auf 100% Load und somit ist mein ganzes Server fast am abkacheln, wenn ich den Shop benutzte.

Das wäre für mich sehr sehr sehr wichtig, wenn ich dieses Problem in den Griff bekommen könnte… ich versteh auch nicht wirklich warum das nur im Backlog ist?

Die Einstellung von Hetzner haben es noch schlimmer gemacht, weil jetzt 2 Cores auf 100% laufen, während es vorher nur einer war…

Wir haben das gleiche Problem, bereits mit dem Hoster gesprochen der auf Apache umgestellt hat aber ist nichts passiert. Scheint mir ein Shopware 6 Problem zu sein. Solange das so bleibt ist der Shop bzw. das Backend nahezu unbrauchbar, erwarte hier von Shopware 6 eine zeitnahe Unterstützung oder Fix…

@Flo_S schrieb:

Wir haben das gleiche Problem, bereits mit dem Hoster gesprochen der auf Apache umgestellt hat aber ist nichts passiert. Scheint mir ein Shopware 6 Problem zu sein. Solange das so bleibt ist der Shop bzw. das Backend nahezu unbrauchbar, erwarte hier von Shopware 6 eine zeitnahe Unterstützung oder Fix…

Moin Flo,

also… ich habe bei mir jetzt auf Mod-PHP umgestellt, jetzt geht es. Allerdings erstellt Apache2 diese Prozesse jetzt unter www-data und nicht mehr unter den jeweiligen web User.

Gerade ein Hoster wird das wohl nicht umstellen, würde ich zumindest nicht, wenn ich das richtig verstanden habe.

Fast-CGI und PHP-FPM und auch die Lösung von hetzner haben bei mir einen Prozess immer auf nah zu 100% Load gehabt.

Wie viele Kunden Daten habt ihr denn?

Habt ihr die Sitemap Generierung als Scheduled Task laufen?

Möglichkeit Blackfire / Tideways auszuführen?

1 Like

Ich habe den Shop frisch in der 6.3.2.0 installiert, 0 Kundendaten nur einige (unter 100) Artikel + Varinten.

Wir sind noch nicht Live, sondern nur an Artikel einpflegen

Update zur Mod-PHP umstellung
Der Shop ist nicht mehr aufrufbar, ich vermute, dass der jetzt www-data User nicht in die web User Daten einfach rein schreiben kann (Cache etc.) ich guck mal ob ich die Permission soweit anpassen kann, sonst muss ich wieder umstellen

@Shyim schrieb:

Wie viele Kunden Daten habt ihr denn?

Habt ihr die Sitemap Generierung als Scheduled Task laufen?

Möglichkeit Blackfire / Tideways auszuführen?

Äh ja, in den Einstellung unter Sitemap steht per default alle Kanäle 3600 und Geplant. Wo wird das Task dafür definiert?
Ich habe es nun mal auf manuell gestellt und kurz danach war mein High Load Prozess weg…

Echt jetzt? Was ich nicht verstehe, führt der sich nur aus, wenn man als Admin im Interface unterwegs ist?

Was meinst du mit Blackfire / Tideways?

Danke schonmal für den Tipp mit der Sitemap… (was sollte man da denn einstellen am besten?) 

Unabhängig davon, dass man den Admin Worker sicherlich optimieren kann, ist das genauso wie in SW5: für den Livebetrieb empfehlen wir eine serverseitige Ausführung. Und wenn korrekt definiert, dann läuft der Admin Worker auch nicht mehr - sieht man dann auch im Admin im Netzwerktab, da wird dann der consume-Call nicht mehr ausgeführt.

 

Die Zeit der scheduled Tasks kann man aktuell über die DB ändern, ein Interface gibt es dafür nicht.

Hi, 

schonmal besten Dank für die ganzen Hinweise und Tipps. Haben die vergangenen Tage nochmal getestet und haben sogar eine Spiegelung auf dem Server gemacht.

Der eine Shop ware langsam während der andere extrem schnell war, aber sobald man Änderungen vornimmt sind beide wieder langsam geworden. Die ganzen Serveränderungen und Anpassungen haben zumindest bei uns keinen Einfluss drauf gehabt…

Da ich diesen Thread nocht gefunden habe (suche nach cpu liefert keine ergebnisse) hatte ich nochmals einen neuen aufgemacht.

Ich möchte alle mit diesem Problem bitten es hier hochzuvoten: Shopware Issuetracker

Falls es in den letzten 2 Monaten neue Erkenntnisse gab, bitte lasst es mich wissen. Mir ist auchgefallen, dass viele mit diesem Problem in einer Debian/MariaDB Umgebung gearbeitet haben.

Habe das Problem auch bei Timmehosting, Managed-Server nginx. Aber nur bei einem Kunden, bei allen anderen SW6-Shops habe ich das Problem nicht. Aber wenn sich der Kunde einloggt passiert es manchmal, alle Kerne auf 100% Auslastung. Aber auch nicht immer. Hatte es jetzt aber schon mehrfach gehabt. Dann Kunden-IP auf blacklist gesetzt und wieder freigeschaltet, dann ging es wieder. Aber es taucht immer wieder mal auf und beruight sich auch nicht von alleine. Hat jemand eine gute Lösung für das Problem?

UPDATE :
Bei timmehosting für die Website im Reiter Optionen
PHP open_basedir ein none eintragen.

Admin-Worker deaktivieren und Cronjobs für consumer und scheduled task einrichten.
Shopware 6 - Tutorials und FAQ - Scheduled Tasks anlegen

Keine Ahnung warum Shopware das nicht per default schon so hinterlegt. Schein ein gravierendes Problem zu sein, das den gnazen Server lahm legt. Sollte bei jeder Installation direkt gemacht werden. 

Ich habe die Lösung des Problems mal in einem Blog-Artikel zusammengefasst: Shopware 6 Problem mit 100% CPU Auslastung durch Admin-Worker
Auch speziell für Timmehostig bzgl. der Cronjobs. Hoffe es hilft dem einen oder anderen weiter. 

An was könnte es noch liegen, wenn man den admin worker schon deaktiviert bzw. ausgelagert hat? Ab und zu kommen Lastspitzen… und der Shop ist dann nicht mehr erreichbar