Die automatisch geladenen Optionen sind es nicht. Das sind nur Datensätze, die höchsten Speicher belegen – aber keine CPU-Zeit verwenden. Dennoch finde ich den Wert schon erheblich, hab ich auch noch nicht gesehen. Evtl. hilft es hiermit das mal zu optimieren: https://wordpress.org/plugins/aaa-option-optimizer/ – alternativ könnte vermutlich auch das helfen: https://de.wordpress.org/plugins/wp-optimize/ – unbedingt vorher ein Backup erstellen!
Die Tabelle, die diese Datensätze enthält heißt „options“. Der Prefix von der Tabelle, kann sich bei deiner Installation unterscheiden. Dazu müsstest du entweder schauen, welchen Prefix dein WordPress nutzt oder einfach mal die Liste der Tabellen in der Datenbank nach „options“ im Namen absuchen. Aber wie gesagt: o.g. wäre die sauberere Lösung als in der Datenbank selbst zu fummeln.
Die Cronjobs sehe ich eher als Grund für eine hohe CPU-Last. Du solltest schauen, welches Plugin die Cronjobs erzeugt. Oft ist das am Namen erkennbar. Das Plugin WP Crontrol kann helfen hier einen Überblick zu bekommen.
Und als genereller Tipp: deaktiviere mal testweise alle Plugins und schau wie sich die Website und die CPU-Last dann verhält. Wenn es besser ist, schau nach was für Cronjobs aktiv sind. Aktiviere dann stückweise die Plugins einzeln und kontrolliere wieder die Cronjobs.
Und ja, so eine Analyse kann langwierig sein. Oft ist irgendein eingesetztes Plugin schuld. Du musst dann entscheiden, ob du das benötigst. Der Website-Bericht könnte helfen für dich vlt. etwas vorzufiltern.
Danke thready. Ich habe wp Crontrol installiert und sehe 76 Cronjobs, von denen der größte Teil unter „nächste Ausführung“ Daten in der Vergangenheit ausweist.
Seltsamerweise gibt es auch Hooks von Plugins, die schon lange deinstalliert sind (zB w3tc, Jetpack, optml).
Kann ich diese Cronjobs einfach löschen ?
Das sind 2 verschiedene Aspekte:
- Wenn die Ausführung in der Vergangenheit liegt, deutet das auf ein Ausführungsproblem der Cronjobs generell hin. Schau unter Werkzeuge > Website-Zustand nach, ob WordPress dazu ein Problem meldet.
- Leider räumen nicht alle Plugins sauber hinter sich auf. Sie lassen Cronjobs übrig, die zwar in der Liste stehen, aber nicht ausgeführt werden, da die technische Grundlage dazu fehlt. Diejenigen kannst du durchaus manuell löschen. Das löst aber vermutlich nicht das CPU-Problem, da sie wie gesagt nichts machen.
Richtig.
Was den Websitezustand angeht, hatte ich ja oben geschrieben, dass hier der Hinweis auf sehr viele Automatisch geladene Optionen gibt. Dies hattest Du als nicht relevant für das CPU-Problem eingeschätzt.
Gibt es weitere Anregungen zum CPU-Problem ?
Was ist das Ergebnis hiervon?
deaktiviere mal testweise alle Plugins und schau wie sich die Website und die CPU-Last dann verhält.
@wildnaturalspirit
Gibt es weitere Anregungen zum CPU-Problem ?
Da du den Server mit weiteren Nutzern teilst … könnte es auch Probleme geben wenn es in dieser Nachbarschaft mal hoch her geht? 😉 Ähnliches habe ich mal erlebt … und habe mich von der Nachbarschaft trennen lassen, bin alleine auf dem Server. Aber daran muss es in deinem Fall ja nicht liegen … ist mir nur eben eingefallen. Falls es dich interessiert: Reverse IP Lookup (http://viewdns.info)
@threadi Die Hauptauslöser bei den abgebrochenen Cronjobs sind WC und MC. DA ich auf WC nicht verzichten kann, habe ich MC pausiert. Die Auswertung der CPU-Auslastung erwarte ich im Laufe des Tages. Immerhin gab es seither keine Störungen mehr…
@wpapm ich versteh das nicht wirklich ? Ich bin bei einem normalen kommerziellen Host und selbstverständlich ist der/seine Server nicht alleine für mich da ?? Wie auch immer, ihc bin deinem Link gefolgt, das ergebnis war, dass 680 weitere Domains auf dem Server liegen. Ich hab dann auch noch die DNS Abfrage gemacht, es gab 1 beachtenswerte Rückmeldung „Your local nameservers don’t return IP addresses (glue) along with your NS records!“
… und ? Wie können mit diese Informationen nun bei der Lösung meines Problems helfen ?
Danke Euch beiden für das Engagment. Mal sehen, ob wir das noch gelöst bekommen.
@wildnaturalspirit
Wie können mit diese Informationen nun bei der Lösung meines Problems helfen ?
Mein Hinweis muss nicht unbedingt ursächlich für ein Lastproblem sein … kann es aber wenn z.B auf den weiteren Seiteneinrichtungen innerhalb deines Servers der Teufel los ist. Ich kann selbst auf meinem Server immer wieder diverse gesteigerte Aufrufe verfolgen die absolut nichts mit dem Seiteninhalt zu tun haben … Spam eben … der leider immer mehr zunimmt.
Du solltest halt nie vergessen das noch zig Webseiten neben deiner auf dem Server aktiv sind. Sind diese z.B einem Angriff ausgesetzt … kann sich das auch auf die Erreichbarkeit deiner Seite auswirken. Kann! Nur deshalb mein Hinweis.
@wildnaturalspirit Mein Tipp wären auch die Cronjobs.
Die Frage ist, wann genau die Lastspitzen auftauchen. Und was zu diesem Zeitpunkt passiert ist. Wenn du also konkrete Zeitpunkte einsehen kannst (ggf. vom Hoster bereitgestsellt) und dann mit errorlog bzw. debuglog bzw. accesslog gegenprüfst, dann findest du vielleicht den Schuldigen.
Vermutlich eine „teure“, also CPU-intensive Operation. Das kann ein Backup sein (insbesondere, wenn es komplett ist und am Ende komprimiert), das kann aber auch eine Bildoptimierung auf dem Server sein (WebP/AVIF-Generierung ist sehr CPU-intensiv).
Eine andere Variante wäre ein invalidierter Cache, der danach ein Cache-Warmup auslöst (Site wird komplett durchgegangen und der Cache neu erstellt). Oder du bekommst viel Bot-Traffic und der Server ist dem nicht gewachsen (quasi eine DoS-Attacke).
Eine langsame externe API, die an einem Cronjob hängt, könnte auch solche Probleme auslösen (Retry-Loop).
Aber das sind alles Schüsse ins Blaue ohne mehr Details aus deinen Logs oder deinem Setup mit dem du das näher eingrenzen kannst.
Nutzt du HPOS in deinem WooCommerce wäre auch eine spannende Frage in dem Zusammenhang oder wie viele Produkte, Bestellungen, ggf. Abos/Subscriptions vorhanden sind …
Auch ein Blick in bzw. auf die Datenbank wäre spannend. WooCommerce nutzt ja den action_scheduler für Hintergrundprozesse. Gibt es langsame Queries in der DB? Was sagen die action_sceduler logs?
Mit mehr Infos können wir besser helfen. Aber mit diesen Tipps, hast du vielleicht ein paar mehr Ideen, wo du jetzt genauer schauen kannst.
@zodiac1978 Danke, Torsten, für deine ausführlichen HInweise.
Die CPU-Peaks (die ich nur für max 2 Monate bekomme) sind in dem betrachteten Zeitraum ständig extrem häufig (mehrmals täglich) hoch. Jedes mal wenn sie an den von alfahosting gesetzten „cage“ stoßsen, gibt es Probleme mit der Website.
Ich habe tatsächlich die Cron Jobs im Verdacht – bin diese (76 offen !) mehrfach durchgegangen, viele laufen nicht durch. Besonders häufig wc_facebook_async_sync, wordfence_(verschiedene), ivole_send_reminder, wp_seo_(versch). Ausserdem sind noch jetpack Jobs gelistet, obwohl ich Jetpack längst deinstalliert habe.
Crontrol hilft nicht wirklich….
Ist es möglich die gesamte Cron Konstellation zu löchen und neu aufzusetzen um zu sehen, ob es dann läuft ?
API wäre durch Plugin-Deaktivierung zu checken, richtig?
Für diesen Rat von Dir
„WooCommerce nutzt ja den action_scheduler für Hintergrundprozesse. Gibt es langsame Queries in der DB? Was sagen die action_sceduler logs?“ bräuchte ich genauere Anweisungen.
Danke für die Mühe !
Wenn du die Cron-Tabelle zurücksetzen willst, deaktiviere ALLE Plugins außer WP Crontrol. Dann gehst du in WP Crontrol und löschst alle Cronjobs, die noch da sind. Anschließend aktivierst du wieder alle Plugins, wodurch diese die von ihnen benötigten Cronjobs wieder setzen sollten.
Ich würde empfehlen vorher ein Backup zu erstellen.
„Action Scheduler“ ist ein Tool was von verschiedenen Plugins als Ersatz bzw. Aufsatz für die WordPress-eigene Cronjob genutzt wird. Mit dem Plugin https://de.wordpress.org/plugins/action-scheduler/ kann man sich anschauen, was dort in der Tabelle der Aufgaben steht. Ein Blick in die Datenbank ist dafür nicht notwendig (auch wenn dort alles gespeichert wird).
Keine Ahnung, was das Plugin macht, die Beschreibung ist schlecht und es gibt keine Screenshots. Der Blick in die Datenbank zeigt dir ggf. die Größe/Anzahl Einträge. Bei großen Sites kann man dort an ein Limit geraten, was Performance beeinträchtigt. Dann hilft die Begrenzung der Logs auf weniger Tage (über einen Filter einstellbar).
Ansonsten ist der (umständliche) Weg, den @threadi beschreibt, wohl die einzige Variante, das zu „resetten“. Mir fällt zumindest kein anderer/besserer ein.
Spannend wäre halt noch, ob du die Peak-Zeiten mit den Logs abgleichen kannst, um daraus Erkenntnisse zu bekommen, was das ausgelöst hat.
Und für externe API-Anfragen hilft vielleicht Query Monitor beim Debuggen.
Da seit einiger Zeit keine Rückmeldung mehr vom TE kam, wird der Thread aus administrativen Gründen auf gelöst gesetzt, damit die ungelösten Threads, in denen noch Hilfe benötigt wird, leichter auffindbar sind.
Der Status „gelöst“ kann vom TE jederzeit geändert und der Thread kann mit Nachfragen oder einem Feedback ergänzt werden.
Lösung gefunden? In einem User-helfen-User-Forum wie diesem hier ist das Posten der Lösung für andere User immer hilfreich, danke.
