{"id":15679,"date":"2025-11-30T11:52:09","date_gmt":"2025-11-30T10:52:09","guid":{"rendered":"https:\/\/webhosting.de\/ungleichmaessige-cpu-last-wordpress-cronjobs-stabilitaet\/"},"modified":"2025-11-30T11:52:09","modified_gmt":"2025-11-30T10:52:09","slug":"%e4%b8%8d%e5%9d%87%e4%b8%80%e3%81%aa-cpu-%e8%b2%a0%e8%8d%b7-wordpress-cronjobs-%e5%ae%89%e5%ae%9a%e6%80%a7","status":"publish","type":"post","link":"https:\/\/webhosting.de\/ja\/ungleichmaessige-cpu-last-wordpress-cronjobs-stabilitaet\/","title":{"rendered":"WordPress \u3067\u306e CPU \u8ca0\u8377\u306e\u4e0d\u5747\u4e00 \u2013 Cron \u30b8\u30e7\u30d6\u304c\u30d1\u30d5\u30a9\u30fc\u30de\u30f3\u30b9\u3092\u640d\u306a\u3046\u53ef\u80fd\u6027"},"content":{"rendered":"<p>Ungleichm\u00e4\u00dfige CPU-Last in WordPress entsteht oft durch schlecht konfigurierte <strong>wordpress cronjobs<\/strong>, die bei jedem Seitenaufruf als Hintergrundprozesse starten und so Spitzen verursachen. Ich zeige, wie diese Trigger die TTFB verl\u00e4ngern, PHP-Worker binden und Latenzen erzeugen \u2013 und wie du mit System-Cron, Intervallen und Priorisierung wieder zu <strong>gleichm\u00e4\u00dfiger<\/strong> Last kommst.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<p>Die folgende \u00dcbersicht bringt die wichtigsten Aspekte auf den Punkt, bevor ich tiefer einsteige und konkrete Schritte erkl\u00e4re. Ich halte die Liste kurz, damit der Fokus auf <strong>Handlung<\/strong> und Wirkung liegt.<\/p>\n<ul>\n  <li><strong>WP-Cron<\/strong> triggert bei Seitenaufrufen und erzeugt unplanbare Last.<\/li>\n  <li><strong>PHP-Prozesse<\/strong> stauen sich bei Traffic und verlangsamen TTFB.<\/li>\n  <li><strong>System-Cron<\/strong> entkoppelt Aufgaben vom Besucherstrom.<\/li>\n  <li><strong>Intervalle<\/strong> und Priorit\u00e4ten gl\u00e4tten CPU-Spitzen.<\/li>\n  <li><strong>Monitoring<\/strong> deckt Engp\u00e4sse und fehlerhafte Events auf.<\/li>\n<\/ul>\n\n<h2>Was WordPress-Cronjobs wirklich tun \u2013 und wo die Last herkommt<\/h2>\n\n<p>WordPress setzt auf ein Pseudo-Cron-System: Beim Aufruf wird wp-cron.php per POST ausgel\u00f6st, pr\u00fcft f\u00e4llige Events und startet Tasks wie Ver\u00f6ffentlichungen, Update-Checks, Entwurfs-Speichern via Heartbeat und Datenbank-Aufr\u00e4umarbeiten \u2013 jedes Ereignis kostet <strong>CPU-Zeit<\/strong>. Dieser Ansatz klingt komfortabel, verursacht aber unkontrollierbare Trigger, weil Besuche die Ausf\u00fchrung bestimmen und nicht ein planbarer Zeitgeber. Treffen mehrere Aufrufe zusammen, starten parallele PHP-Prozesse, die um Worker konkurrieren. Multisite-Setups verst\u00e4rken den Effekt, da jede Subsite ihren eigenen Event-Stack pflegt und so die Anzahl der Pr\u00fcfungen erh\u00f6ht [1]. Wer die Zusammenh\u00e4nge vertiefen will, findet fundierte Grundlagen unter <a href=\"https:\/\/webhosting.de\/wp-cron-verstehen-optimieren-wordpress-aufgabenmanagement-expert\/\">WP-Cron verstehen<\/a>, doch die Kernbotschaft bleibt: Besucherlenkung eignet sich nicht als verl\u00e4sslicher <strong>Taktgeber<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress-cpulast-server-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Die eigentliche Bremse: parallele PHP-Prozesse durch wp-cron.php<\/h2>\n\n<p>Jeder Cron-Trigger startet einen separaten PHP-Prozess, der einen Worker bindet und dadurch die verf\u00fcgbare <strong>Rechenzeit<\/strong> f\u00fcr echte Seitenrenderings reduziert. H\u00e4ufen sich Trigger, steigt die Wartezeit auf einen freien Worker, TTFB verl\u00e4ngert sich, und der erste Byte kommt sp\u00e4ter beim Browser an [2]. In Messungen zeigte sich eine Verz\u00f6gerung um bis zu 800 Millisekunden, was Core Web Vitals belastet und die organische Sichtbarkeit d\u00e4mpft [3]. Shared-Hosting oder knapp bemessene PHP-FPM-Settings versch\u00e4rfen den Effekt, weil max_children schnell erreicht werden und Prozesse in Warteschlangen landen. Gerade bei Shop-Peaks oder Kampagnen kann das zu einem Teufelskreis werden: Mehr Traffic erzeugt mehr Cronpr\u00fcfungen, die wiederum Rendering blockieren und so <strong>Ladezeiten<\/strong> strecken [1][2].<\/p>\n\n<h2>Caching, CDN und Loopback-Fallen richtig behandeln<\/h2>\n\n<p>WP-Cron nutzt standardm\u00e4\u00dfig einen internen <em>Loopback-Request<\/em> auf die eigene Domain. Liegen davor ein aggressiver Page-Cache, ein CDN oder eine Basic-Auth-Sperre, kann der Aufruf fehlschlagen oder warten \u2013 Cronl\u00e4ufe stocken, wiederholen sich und verl\u00e4ngern so die CPU-Bindung. Ich sorge deshalb daf\u00fcr, dass <code>\/wp-cron.php<\/code> nicht gecacht, nicht rate-limited und intern erreichbar ist. System-Cron entsch\u00e4rft diese Schwachstelle, weil er <strong>ohne<\/strong> HTTP-Loopback direkt PHP ausf\u00fchrt. Wenn ein Proxy vorgeschaltet ist, pr\u00fcfe ich zus\u00e4tzlich, ob Requests an <code>127.0.0.1<\/code> sauber durchgereicht werden und keine WAF-Regel den Endpunkt blockiert. In Maintenance-Phasen ist wichtig: Entweder Cron bewusst pausieren \u2013 oder den Endpunkt explizit durchlassen, damit f\u00e4llige Tasks nicht als Paket \u201enachfeuern\u201c.<\/p>\n\n<h2>Ungleichm\u00e4\u00dfige CPU-Last erkennen und einordnen<\/h2>\n\n<p>Typisch sind Lastspitzen zu Sto\u00dfzeiten, die sich nicht allein durch Besucherzahlen erkl\u00e4ren lassen, sondern durch Cron-Wellen aus \u00fcberf\u00e4lligen Events, die sich stapeln und gemeinsam feuern. Multisite-Installationen vervielfachen die Last, da jede Subsite Cronlisten verwaltet und beim Besuch gepr\u00fcft wird \u2013 so entstehen kurze, aber harte Peaks, die Logfiles als Kaskaden von wp-cron.php-POSTs zeigen [1]. H\u00e4ufig registrieren Plugins eigene Events mit zu kurzen Intervallen, teils alle f\u00fcnf Minuten oder \u00f6fter, was sich bei zehn Plugins schnell zu Dutzenden Pr\u00fcfungen je Aufruf summiert. Achte zus\u00e4tzlich auf dein <a href=\"https:\/\/webhosting.de\/php-workers-hosting-flaschenhals-ratgeber-balance\/\">PHP-Worker Limit<\/a>, denn volle Worker erzwingen Wartezeiten, die Nutzer direkt sp\u00fcren. Wer diese Muster liest, versteht die ungleichm\u00e4\u00dfige Kurve als Folge von Triggern, nicht als unvermeidliche <strong>Laune<\/strong> des Traffics.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress_cpu_meeting_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Warum System-Cron die Last gl\u00e4ttet<\/h2>\n\n<p>Ein echter System-Cron entkoppelt Aufgaben vom Besucherstrom und setzt einen klaren Takt, etwa alle f\u00fcnf Minuten, st\u00fcndlich oder t\u00e4glich \u2013 damit wird die Ausf\u00fchrung planbar und die Last gleichm\u00e4\u00dfig verteilt [1][6]. Besuchende l\u00f6sen dann keine Cronjobs mehr aus, was TTFB entlastet und Rendering priorisiert. Auch bei wenig Traffic laufen Tasks zuverl\u00e4ssig, weil der Server sie ausf\u00fchrt, selbst wenn niemand die Seite besucht. Das hilft Updates, Mails oder Index-Pings, p\u00fcnktlich zu laufen und verhindert, dass Events \u201eliegen bleiben\u201c und sp\u00e4ter als Paket feuern. So schaffe ich eine vorhersehbare <strong>Systemlast<\/strong>, die nicht nach Laune des Traffics schwankt.<\/p>\n\n<h2>Schritt f\u00fcr Schritt: WP-Cron deaktivieren und System-Cron einrichten<\/h2>\n\n<p>Ich beginne mit dem Abschalten des internen Triggers in der wp-config.php, damit kein Seitenaufruf mehr Cronjobs startet. F\u00fcge dazu die folgende Zeile hinzu und speichere die Datei, damit WordPress keine Cron-Pr\u00fcfung beim Rendern anst\u00f6\u00dft. Danach richte ich eine saubere Crontab-Regel ein, die wp-cron.php zyklisch anst\u00f6\u00dft, ohne unn\u00f6tige Ausgabe zu erzeugen. So l\u00e4uft der Job zeitgesteuert und entlastet Seitenaufrufe konsequent. Das Ergebnis: Rendering hat Vorrang, Cronjobs haben eine eigene <strong>Taktung<\/strong>.<\/p>\n\n<pre><code>\/\/ wp-config.php\ndefine('DISABLE_WP_CRON', true);\n<\/code><\/pre>\n\n<pre><code># Crontab-Beispiel (alle 5 Minuten)\n*\/5 * * * * php -q \/var\/www\/html\/wp-cron.php &gt; \/dev\/null 2&gt;&1\n<\/code><\/pre>\n\n<h2>WP-CLI statt direktem PHP-Aufruf<\/h2>\n\n<p>F\u00fcr bessere Kontrolle setze ich den Cronlauf gern per <strong>WP-CLI<\/strong> ab. So kann ich \u201enur f\u00e4llige\u201c Events ausf\u00fchren, detaillierter loggen und Multisite gezielt abarbeiten. Zus\u00e4tzlich verhindert ein Lock, dass mehrere L\u00e4ufe parallel starten.<\/p>\n\n<pre><code># WP-CLI: nur f\u00e4llige Events abarbeiten\n*\/5 * * * * \/usr\/local\/bin\/wp cron event run --due-now --path=\/var\/www\/html --quiet\n\n# Mit einfachem Lock \u00fcber flock (empfohlen)\n*\/5 * * * * flock -n \/tmp\/wp-cron.lock \/usr\/local\/bin\/wp cron event run --due-now --path=\/var\/www\/html --quiet\n<\/code><\/pre>\n\n<p>In Multisite-Umgebungen kann ich so per <code>--url=<\/code> Site f\u00fcr Site durchgehen oder \u00fcber ein kleines Shell-Loop die Sites rotieren lassen. Das vermeidet, dass 100 Subsites zeitgleich den gleichen Takt treffen und Lastspitzen erzeugen.<\/p>\n\n<h2>Intervalle und Priorit\u00e4ten: welche Aufgaben wann laufen sollten<\/h2>\n\n<p>Nicht jede Aufgabe braucht Minutentakt; ich staffele nach Relevanz und Kosten, damit SEO-kritische Jobs Vorrang erhalten und teure Arbeiten in Nebenzeiten wandern [1]. Im Fokus stehen Sitemap-Erzeugung, Indexing-Pings und Cache-Warming, danach folgen Datenbankpflege und Transient-L\u00f6schungen. Backups plane ich in Nachtfenstern und w\u00e4hle inkrementelle Verfahren, um I\/O-Spitzen zu vermeiden. Newsletter-Queues oder Importer fasse ich zusammen und lasse sie in festen Slots laufen, statt sie bei jedem Seitenaufruf zu pr\u00fcfen. Diese Ordnung sorgt f\u00fcr klare Priorit\u00e4ten und verhindert, dass kurze Poll-Intervalle die <strong>CPU<\/strong> verstopfen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aufgabe<\/th>\n      <th>Empfohlenes Intervall<\/th>\n      <th>CPU-Impact<\/th>\n      <th>Hinweis<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Sitemap\/Indexing-Pings<\/td>\n      <td>st\u00fcndlich bis 1\u00d7\/Tag<\/td>\n      <td>niedrig<\/td>\n      <td>SEO-relevant; vor dem Cache-Warming <strong>priorisieren<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Cache-Warming<\/td>\n      <td>1\u20132\u00d7\/Tag<\/td>\n      <td>mittel<\/td>\n      <td>URLs staffeln, keine Voll-Scans zur Hauptzeit<\/td>\n    <\/tr>\n    <tr>\n      <td>Backups<\/td>\n      <td>nachts<\/td>\n      <td>hoch<\/td>\n      <td>inkrementell; Remote-Ziel mit Bandbreitenlimit<\/td>\n    <\/tr>\n    <tr>\n      <td>Datenbankbereinigung<\/td>\n      <td>t\u00e4glich oder w\u00f6chentlich<\/td>\n      <td>mittel<\/td>\n      <td>Revisionen\/Transients in Bl\u00f6cken <strong>l\u00f6schen<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>E-Mail-Benachrichtigungen<\/td>\n      <td>st\u00fcndlich\/1\u00d7\/Tag<\/td>\n      <td>niedrig<\/td>\n      <td>Batches bilden, Queue nutzen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress-cronjobs-cpu-last-5271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Single-Run-Mechanismen und saubere Locks<\/h2>\n\n<p>Damit Cronl\u00e4ufe sich nicht \u00fcberlappen, setze ich neben <code>flock<\/code> auch WordPress-eigene Schranken ein. <code>WP_CRON_LOCK_TIMEOUT<\/code> definiert, wie lange ein Lauf exklusiv bleibt. Ist die Seite langsam oder laufen lange Jobs, erh\u00f6he ich den Wert moderat, damit kein zweiter Prozess fr\u00fchzeitig startet. Umgekehrt senke ich ihn, wenn Jobs kurz sind und ein H\u00e4nger keine Kaskaden ausl\u00f6sen soll.<\/p>\n\n<pre><code>\/\/ wp-config.php \u2013 Lock-Zeit in Sekunden (Standard 60)\ndefine('WP_CRON_LOCK_TIMEOUT', 120);\n<\/code><\/pre>\n\n<p>Zus\u00e4tzlich begrenze ich in Plugins bewusst Parallelit\u00e4t (Batch-Gr\u00f6\u00dfen, Schrittl\u00e4ngen, Sleeps zwischen Requests). So verhindere ich, dass ein Cronlauf selbst wieder Dutzende PHP-Prozesse erzeugt und die Lastkurve aufschaukelt.<\/p>\n\n<h2>Monitoring und Analyse: Engp\u00e4sse sichtbar machen<\/h2>\n\n<p>Ich starte bei den Access-Logs und filtere POST-Requests auf wp-cron.php, um H\u00e4ufigkeit und Zeitfenster zu erkennen; viele kurze Abst\u00e4nde deuten auf enge Intervalle oder blockierende Events hin. Parallel pr\u00fcfe ich Fehler-Logs auf Timeouts, Locking und Datenbankwartezeiten, die Cronjobs beeinflussen. Im Backend verschafft WP Crontrol Einblick in registrierte Events, ihre Hooks und geplante Laufzeiten; dort l\u00f6sche ich veraltete oder h\u00e4ngende Eintr\u00e4ge. F\u00fcr tieferen Einblick in Transaktionen, Query-Zeiten und PHP-FPM-Warteschlangen setze ich <a href=\"https:\/\/webhosting.de\/wordpress-apm-tools-monitoring-best-practices-hosting-empfehlung-monitoring\/\">APM-Tools f\u00fcr WordPress<\/a> ein, um Hotspots zu isolieren. So finde ich die Ursachen, statt nur Symptome zu d\u00e4mpfen, und kann gezielt <strong>Ma\u00dfnahmen<\/strong> priorisieren.<\/p>\n\n<h2>Messbare Ziele und Kurztest in 10 Minuten<\/h2>\n\n<p>Ich definiere klare Zielwerte: TTFB p95 f\u00fcr gecachte Seiten unter 200\u2013300 ms, f\u00fcr uncached Seiten unter 800 ms; PHP-FPM-Queue dauerhaft nahe 0; CPU ohne spitze Peaks, die in S\u00e4ttigung laufen. Der Kurztest: WP-Cron deaktivieren, System-Cron setzen, f\u00e4llige Events einmalig per WP-CLI abarbeiten, dann Logs pr\u00fcfen. In 10 Minuten siehst du, ob die TTFB f\u00e4llt, die PHP-Queue schrumpft und ob auff\u00e4llige Hooks (z. B. Update-Checks, Importer) den Hauptanteil tragen. Danach justiere Intervalle, Batch-Gr\u00f6\u00dfen und den Takt, bis die Kurven stabil sind.<\/p>\n\n<h2>Heartbeat-API und Plugin-Events z\u00e4hmen<\/h2>\n\n<p>Der Heartbeat-Mechanismus aktualisiert Sitzungen und Entw\u00fcrfe, erzeugt aber im Frontend oft unn\u00f6tige Requests; ich drossele ihn auf Admin-Bereiche oder setze passende Intervalle. Viele Plugins registrieren Cronjobs mit Werkswerten, die zu eng takten; hier stelle ich auf l\u00e4ngere Abst\u00e4nde um und verschiebe Tasks in Nebenzeiten. In Shop-Setups begrenze ich Inventar-Feeds und Preis-Syncs auf feste Slots, statt min\u00fctlich zu pollen. F\u00fcr Feeds und Cache-Warming nutze ich Batch-Listen, damit nicht alle URLs in einem Rutsch laufen. Diese Eingriffe senken Request-Frequenzen und gl\u00e4tten die <strong>Kurve<\/strong> deutlich.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress_cpu_load_0372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Skalierung: Von Cronjobs zu Queues und Workern<\/h2>\n\n<p>Bei hohem Traffic halte ich WP-Cron m\u00f6glichst klein und verlagere rechenintensive Tasks in Queues mit dedizierten Workern. Job-Queues verteilen Last auf mehrere Prozesse, lassen sich horizontal erweitern und vermeiden, dass das Frontend warten muss. In Container- oder Orchestrierungs-Setups skaliere ich Worker unabh\u00e4ngig von PHP-FPM, wodurch Rendern und Hintergrundarbeit getrennte Ressourcen bekommen. F\u00fcr Importe, Bildverarbeitung, Newsletter-Batches und API-Syncs zahlen sich Queues besonders aus. So bleibt das Frontend reaktionsschnell, w\u00e4hrend Hintergrundjobs kontrolliert und <strong>planbar<\/strong> laufen.<\/p>\n\n<h2>WooCommerce, Action Scheduler und gro\u00dfe Queues<\/h2>\n\n<p>WooCommerce bringt mit dem <em>Action Scheduler<\/em> eine eigene Queue mit, die Bestell-Mails, Webhooks, Abos und Syncs verarbeitet. Gerade hier drohen CPU-Spitzen, wenn tausende Aktionen \u201edue\u201c sind. Ich lasse den Runner nicht beim Seitenaufruf laufen, sondern triggere ihn \u00fcber System-Cron oder WP-CLI in festen Fenstern. Batch-Gr\u00f6\u00dfen und Parallelit\u00e4t stelle ich so ein, dass ein Lauf die Datenbank nicht blockiert und PHP-FPM-Worker frei bleiben. Importer, Bildregeneration und Webhook-Spitzen verteile ich in mehrere kleine Durchl\u00e4ufe \u2013 lieber 10\u00d7 kurz als 1\u00d7 stundenlang mit I\/O-Blockaden.<\/p>\n\n<h2>Multisite-Spezifika: Taktung per Site balancieren<\/h2>\n\n<p>In Multisite-Setups summiert sich die Last, weil jede Site ihre eigene Eventliste hat. Statt alles alle f\u00fcnf Minuten zu pr\u00fcfen, rotiere ich die Sites: Site-Gruppen mit leicht versetzten Takten, damit nicht alle Cronlisten gleichzeitig laufen. F\u00fcr stark aktive Sites erh\u00e4lt die Queue \u00f6fter einen Slot, ruhige Sites seltener. Das Ergebnis ist eine gleichm\u00e4\u00dfigere CPU-Kurve und weniger Konkurrenz um Worker \u2013 bei gleicher Gesamtarbeit.<\/p>\n\n<h2>Praxis-Check: Konfiguration ohne Stolperfallen<\/h2>\n\n<p>Ich pr\u00fcfe zuerst, ob DISABLE_WP_CRON korrekt gesetzt ist, denn doppelte Trigger (intern + extern) versch\u00e4rfen Lastspitzen. Danach kontrolliere ich die Crontab: korrekter Pfad, kein unn\u00f6tiger Output, sinnvoller Intervall, und keine \u00dcberschneidungen mit Backup-Fenstern. In WP Crontrol bereinige ich veraltete Hooks und stelle enge Intervalle auf realistische Zyklen um. Die PHP-FPM-Settings passe ich an das Besucherprofil an, damit PHP-Worker nicht st\u00e4ndig an der Obergrenze h\u00e4ngen. Abschlie\u00dfend tracke ich TTFB, Antwortzeiten und CPU, um den Effekt der \u00c4nderungen sauber zu <strong>bewerten<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress_cpu_cronload_7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PHP-FPM, OPCache und Zeitlimits passend dimensionieren<\/h2>\n\n<p>Die beste Cron-Strategie verpufft, wenn PHP-FPM zu klein oder falsch getaktet ist. Ich w\u00e4hle <code>pm=dynamic<\/code> oder <code>pm=ondemand<\/code> je nach Traffic-Profil und leite <code>pm.max_children<\/code> aus dem realen RAM-Budget ab: Als Daumenregel RAM_f\u00fcr_PHP \/ durchschnittlicher Scriptverbrauch. Beispiel: 2 GB Budget und ~128 MB je Prozess ergeben ~16 Worker. <code>pm.max_requests<\/code> setze ich moderat (500\u20131000), um Leaks zu kappen. <code>request_terminate_timeout<\/code> begrenzt Ausrei\u00dfer-Jobs; ein sauberer <em>slowlog<\/em> deckt Query-Schleifen und externe Wartezeiten auf. Ein gesunder OPCache (gen\u00fcgend <code>max_accelerated_files<\/code>, <code>memory_consumption<\/code>, <code>interned_strings_buffer<\/code>) verhindert kalte Starts und spart CPU pro Request \u2013 auch f\u00fcr Cronl\u00e4ufe.<\/p>\n\n<h2>Object Cache und Optionen-Hygiene<\/h2>\n\n<p>Ein persistenter Object Cache (z. B. Redis\/Memcached) reduziert Datenbankdruck f\u00fcr Cronpr\u00fcfungen deutlich. Wichtig ist dabei die <em>Hygiene<\/em> in der <code>wp_options<\/code>-Tabelle: Die Option <code>cron<\/code> darf nicht auf mehrere Megabyte anwachsen, sonst wird jede Pr\u00fcfung teuer. Veraltete oder h\u00e4ngende Events entferne ich, autoload-Schrott reduziere ich, und gro\u00dfe, selten genutzte Optionen stelle ich auf <code>autoload = no<\/code>. So sinken Query-Zeiten und Cronlisten lassen sich schneller evaluieren.<\/p>\n\n<h2>Feintuning: Takt, Reihenfolge und Ressourcengrenzen<\/h2>\n\n<p>F\u00fcr Websites mit Spitzen am Vormittag takte ich Cache-Warming auf die fr\u00fche Nacht und lasse Sitemaps kurz vor Gesch\u00e4ftszeiten laufen, damit Crawler frische Daten sehen. Teure Datenbankbereinigungen splitte ich in kleinere Bl\u00f6cke, um Lock-Zeiten zu senken und Query-Spitzen zu verhindern. Gro\u00dfe Exporte setze ich auf Wochenendfenster, in denen weniger Interaktion stattfindet. Wo sinnvoll, begrenze ich parallele Jobs, damit nicht mehrere cron-php-Prozesse zeitgleich um I\/O k\u00e4mpfen. Dieses Feintuning sorgt f\u00fcr gleichm\u00e4\u00dfigen Durchsatz und bessere <strong>Antwortzeiten<\/strong>.<\/p>\n\n<h2>Sicherheit: wp-cron.php vor externen Zugriffen sch\u00fctzen<\/h2>\n\n<p>Weil Cron intern ausgel\u00f6st werden soll, sperre ich direkten externen Zugriff auf <code>\/wp-cron.php<\/code>. So verhinderst du Missbrauch, DDoS und versehentliche Fremdaufrufe. Erlaube nur lokale Aufrufe (Loopback oder CLI) und blocke alles andere. Das senkt Rauschen in den Logs und sch\u00fctzt PHP-Worker.<\/p>\n\n<pre><code># Nginx-Beispiel\nlocation = \/wp-cron.php {\n  allow 127.0.0.1;\n  deny all;\n  include fastcgi_params;\n  fastcgi_pass php-fpm;\n}\n\n# Apache-Beispiel\n&lt;Files \"wp-cron.php\"&gt;\n  Require ip 127.0.0.1\n&lt;\/Files&gt;\n<\/code><\/pre>\n\n<h2>H\u00e4ufige Ursachen f\u00fcr \u201eGhost\u201c-Last durch Cron<\/h2>\n\n<p>Sehr kurze Intervalle (1\u20135 Minuten) f\u00fcr unkritische Tasks geh\u00f6ren zu den gr\u00f6\u00dften Lasttreibern, besonders in Kombination mit vielen Plugins. H\u00e4ngende Events, die durch fehlgeschlagene L\u00e4ufe immer wieder neu geplant werden, erzeugen Schleifen, die Logs fluten. Locking-Probleme in der Datenbank zwingen Cronjobs in l\u00e4ngere Laufzeiten, wodurch \u00dcberschneidungen zunehmen. Au\u00dferdem k\u00f6nnen HTTP-Blockaden (z. B. DNS oder Remote-API) Cronl\u00e4ufe k\u00fcnstlich verl\u00e4ngern und Worker binden. Wer diese Muster kennt, spart viel Zeit bei der Ursachensuche und senkt die <strong>Peaks<\/strong> schnell.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/11\/wordpress-cron-cpu-last-8327.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Ungleichm\u00e4\u00dfige CPU-Last in WordPress hat oft ihren Ursprung in WP-Cron, das bei Seitenaufrufen als Trigger wirkt und PHP-Worker bindet. Ich schalte den internen Trigger ab, setze einen System-Cron, optimiere Intervalle und priorisiere SEO-relevante Aufgaben, damit Rendering Vorrang hat. Monitoring mit Logs, WP Crontrol und APM-Analysen zeigt mir fehlerhafte Events, enge Takte und blockierende Prozesse. F\u00fcr gro\u00dfe Projekte verschiebe ich rechenintensive Arbeiten in Queues, um Frontend und Hintergrundjobs sauber zu trennen. Dieser Weg f\u00fchrt zu gleichm\u00e4\u00dfiger Last, k\u00fcrzerer TTFB und sp\u00fcrbar <strong>schnellerer<\/strong> Auslieferung \u2013 ohne unerwartete Spitzen.<\/p>","protected":false},"excerpt":{"rendered":"<p>WordPress \u306e\u30af\u30ed\u30f3\u30b8\u30e7\u30d6\u304c CPU \u8ca0\u8377\u306e\u4e0d\u5747\u4e00\u5316\u3092\u5f15\u304d\u8d77\u3053\u3059\u4ed5\u7d44\u307f\u3068\u3001\u30b7\u30b9\u30c6\u30e0\u30af\u30ed\u30f3\u306e\u5b9f\u88c5\u306b\u3088\u3063\u3066\u30a6\u30a7\u30d6\u30b5\u30a4\u30c8\u306e\u30d1\u30d5\u30a9\u30fc\u30de\u30f3\u30b9\u3092\u5b89\u5b9a\u3055\u305b\u308b\u65b9\u6cd5\u3092\u3054\u7d39\u4ecb\u3057\u307e\u3059\u3002\u5b9f\u7528\u7684\u306a\u6700\u9069\u5316\u306e\u305f\u3081\u306e\u30d2\u30f3\u30c8\u3068\u624b\u9806\u3082\u3054\u7d39\u4ecb\u3057\u3066\u3044\u307e\u3059\u3002.<\/p>","protected":false},"author":1,"featured_media":15672,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-15679","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"3098","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"wordpress cronjobs","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"15672","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts\/15679","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/comments?post=15679"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/posts\/15679\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/media\/15672"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/media?parent=15679"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/categories?post=15679"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/ja\/wp-json\/wp\/v2\/tags?post=15679"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}