--- title: "WordPress-Hosting-Ressourcen prüfen: PHP-Worker, Arbeitsspeicher und Limits" date: 2026-09-30T21:54:59+02:00 modified: 2026-11-09T11:42:38+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-hosting-ressourcen-php-worker-memory-limit-pruefen keywords: - WordPress - Hosting - PHP - Performance - wp-config reading_time: 9 --- # WordPress-Hosting-Ressourcen prüfen: PHP-Worker, Arbeitsspeicher und Limits Wenn eine WordPress-Website unter Last langsam wird, Seiten mit „Auf dieser Website ist ein kritischer Fehler aufgetreten“ abbrechen oder Uploads scheitern, liegt die Ursache oft nicht im Code, sondern an den Grenzen des Hostings: zu wenig PHP-Prozesse für gleichzeitige Besucher, ein zu knappes Speicherlimit oder zu kurze Laufzeiten. Diese Grenzen stehen selten auf der Tarifseite, lassen sich aber auslesen. Diese Anleitung zeigt, wie Sie die tatsächlichen Werte ermitteln, verstehen, welche Einstellung welche Wirkung hat, und mit einer einfachen Messung prüfen, ob Ihr Hosting für die Besucherzahl ausreicht. **Kurzfassung:** Unter „Werkzeuge > Website-Zustand > Bericht“ zeigt WordPress die PHP-Grenzen des Servers. Werte aus WP-CLI können davon abweichen, weil die Kommandozeile eine eigene PHP-Konfiguration nutzt. Die Zahl der PHP-Worker bestimmt, wie viele Seitenaufrufe gleichzeitig laufen, alle weiteren warten. `WP_MEMORY_LIMIT` in der `wp-config.php` wirkt nur, wenn der Hoster das PHP-Limit nicht fest vorgibt. Prüfen Sie Grenzen mit einer eigenen Messung, statt Werte blind zu erhöhen. ## Voraussetzungen - [ ] **WordPress:** ab Version 5.2, weil es den Website-Zustand erst seit dieser Version gibt. - [ ] **PHP:** mindestens 7.4. - [ ] **Zugriff:** Backend-Konto mit der Rolle Administrator. Für Änderungen an der `wp-config.php` FTP oder SSH, für die Schritte mit WP-CLI SSH. - [ ] **Hoster-Dokumentation:** die Beschreibung Ihres Tarifs oder die Einstellungsseite im Kundenbereich, denn viele Grenzen legt allein der Hoster fest. - [ ] **Backup:** eine aktuelle Sicherung von Dateien und Datenbank, bevor Sie `wp-config.php` oder `.htaccess` ändern. Ein Tippfehler in einer dieser Dateien legt die Website sofort lahm. ## Schritt 1: Aktuelle Grenzen im Website-Zustand ablesen Öffnen Sie im Backend „Werkzeuge > Website-Zustand“ und wechseln Sie zum Reiter „Bericht“. Klappen Sie die Abschnitte „Server“ und „WordPress-Konstanten“ auf. Die für die Ressourcen wichtigen Zeilen: | Anzeige im Bericht | Bedeutung | Beispielwert | | --- | --- | --- | | PHP-Arbeitsspeichergrenze (memory_limit) | Höchster Arbeitsspeicher, den ein einzelner PHP-Aufruf belegen darf | 128M | | Maximale PHP-Ausführungszeit (max_execution_time) | Sekunden, nach denen PHP ein Skript abbricht | 30 | | Maximale Dateigröße beim Upload (upload_max_filesize) | Größte Datei in der Mediathek | 2M | | Maximale Größe der PHP-Post-Daten (post_max_size) | Größe eines gesamten Formularversands | 8M | | Maximale PHP-Eingabe-Variablen (max_input_vars) | Anzahl der Felder pro Formular, wichtig für große Menüs | 1000 | | WP_MEMORY_LIMIT | Speicherlimit, das WordPress im Frontend anfordert | 40M | | WP_MAX_MEMORY_LIMIT | Speicherlimit für den Adminbereich und aufwendige Aufgaben | 256M | Die Anzeige 40M bei `WP_MEMORY_LIMIT` wirkt knapp, ist aber harmlos. Der Quellcode in `wp-includes/default-constants.php` zeigt: WordPress setzt das PHP-Limit nur dann auf `WP_MEMORY_LIMIT`, wenn dieser Wert größer ist als das bestehende Limit. Mit 128M auf dem Server bleibt es also bei 128M. Die Grenze bezieht sich auf einen einzelnen Aufruf. Ein Hosting mit 2 GB Arbeitsspeicher und `memory_limit` 128M erlaubt nicht einem Aufruf 2 GB, sondern teilt den Speicher auf alle gleichzeitig laufenden PHP-Prozesse auf. > **Prüfen:** Sie haben die sieben Werte aus der Tabelle für Ihre Website notiert. ## Schritt 2: Werte aus Sicht des Webservers prüfen Wer mit WP-CLI arbeitet, sollte wissen: Die Kommandozeile nutzt oft eine eigene PHP-Konfiguration. Zum Beispiel meldet WP-CLI `max_execution_time` 0 (unbegrenzt), der Webserver dagegen 30 Sekunden. Für Besucher zählt der Wert des Webservers. Wenn Sie die Angabe aus dem Website-Zustand gegenprüfen möchten, legen Sie vorübergehend eine Testdatei im WordPress-Verzeichnis an: ```php **Prüfen:** Die Testdatei zeigt dieselben Werte wie der Website-Zustand und ist danach gelöscht. Ein erneuter Aufruf liefert den Status 404. ## Schritt 3: PHP-Worker verstehen Jeder Seitenaufruf, der nicht aus einem Cache kommt, belegt für seine Dauer einen PHP-Prozess. Hoster nennen diese Prozesse PHP-Worker oder PHP-Prozesse. Technisch entspricht das bei PHP-FPM der Einstellung `pm.max_children`, laut PHP-Handbuch die Grenze für gleichzeitig bediente Anfragen. Beim Apache-Modul übernimmt `MaxRequestWorkers` diese Rolle. Laut Apache-Dokumentation werden Anfragen über dieser Grenze in eine Warteschlange gestellt, bis ein Prozess frei wird. Diese Warteschlange wird sichtbar, wenn ein Skript 2 Sekunden wartet und dann antwortet. Zehn gleichzeitige Aufrufe ergeben: | Gleichzeitige Prozesse | Antwortzeiten der 10 Aufrufe (gerundet) | Letzte Antwort nach | | --- | --- | --- | | 2 | 2, 2, 4, 4, 6, 6, 8, 8, 10, 10 Sekunden | 10 Sekunden | | 150 (Standard im Image, begrenzt durch 2 CPU-Kerne) | 2 bis 5,8 Sekunden | 5,8 Sekunden | Mit zwei Prozessen arbeitete der Server die Aufrufe paarweise ab, der zehnte Besucher wartete fünfmal so lange wie der erste. Genau so verhält sich ein Tarif mit zwei PHP-Workern, wenn mehrere Besucher gleichzeitig ungecachte Seiten anfordern: Warenkorb, Kasse, Suche, Formulare und der Adminbereich. Die zweite Zeile zeigt die andere Grenze: Mehr Prozesse helfen nur, solange genug CPU-Kerne da sind. Wie viele Worker Ihr Tarif hat, steht in der Tarifbeschreibung oder im Kundenbereich. Fehlt die Angabe, fragen Sie den Support. Bei PHP-FPM auf eigenem Server zeigt die Statusseite (`pm.status_path`) den Zähler „max children reached“. Laut PHP-Handbuch ist er 1 oder größer, sobald die Grenze einmal erreicht wurde. > **Prüfen:** Sie kennen die Anzahl der PHP-Worker Ihres Tarifs oder haben beim Hoster danach gefragt. ## Schritt 4: Bedarf abschätzen Die Worker-Zahl allein sagt wenig. Entscheidend ist, wie lange ein Aufruf dauert. Ein Worker, der eine Seite in 0,2 Sekunden erzeugt, schafft rechnerisch fünf Aufrufe pro Sekunde. Braucht die Seite 1 Sekunde, ist es nur einer. Deshalb ist die Messung der Antwortzeit aus der Anleitung [WordPress schneller machen: Ladezeit messen und Engpässe finden](https://s-edv.com/anleitungen/wordpress-schneller-machen-ladezeit-messen-engpaesse-finden) die Grundlage jeder Abschätzung. Für den Arbeitsspeicher gilt: Jeder Worker belegt Speicher. Apache-Prozesse mit PHP belegen zum Beispiel jeweils etwa 43 bis 51 MB (Wert `VmRSS`). Bei eigenem Server können Sie grob rechnen: verfügbarer Arbeitsspeicher für PHP geteilt durch Speicher pro Prozess ergibt die Obergrenze an Workern. Mehr Worker als Arbeitsspeicher führt zum Auslagern oder dazu, dass das Betriebssystem Prozesse beendet, und das ist schlimmer als eine Warteschlange. Für die Planung helfen drei Fragen: Wie viele Besucher sind zur Spitzenzeit gleichzeitig auf Seiten, die nicht aus dem Cache kommen? Wie lange dauert ein solcher Aufruf? Und laufen im Hintergrund Aufgaben wie Backups, Importe oder WP-Cron, die ebenfalls Worker belegen? > **Prüfen:** Sie haben die Antwortzeit einer ungecachten Seite gemessen und können abschätzen, wie viele Aufrufe pro Sekunde Ihre Worker schaffen. ## Schritt 5: Speicherlimit richtig erhöhen Reicht der Speicher nicht, bricht WordPress mit „Auf dieser Website ist ein kritischer Fehler aufgetreten“ ab. Im Protokoll steht die eigentliche Meldung. Belegt ein Plugin 150 MB bei einem Limit von 128M, sieht die Meldung so aus: Ausgabe: ```plaintext PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 157286432 bytes) in /var/www/html/wp-content/plugins/speicher-test.php on line 3 ``` Die Zahl 134217728 Byte entspricht 128 MB, die Datei nennt den Verursacher. Wie Sie das Protokoll aktivieren, beschreibt die Anleitung [WordPress Debug-Modus aktivieren und Error-Logs analysieren](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben). Erstellen Sie ein Backup und tragen Sie dann in der `wp-config.php` oberhalb der Zeile `/* That's all, stop editing! Happy publishing. */` ein: ```php define( 'WP_MEMORY_LIMIT', '256M' ); ``` Mit WP-CLI geht das mit `wp config set WP_MEMORY_LIMIT 256M`. Danach läuft der Aufruf durch: `belegt 153 MB bei memory_limit 256M`. Das funktioniert sogar, wenn das Limit per `.htaccess` mit `php_value memory_limit 64M` auf 64M gesenkt ist, weil WordPress den Wert zur Laufzeit wieder anhebt. Anders, wenn der Hoster das Limit fest vorgibt. Dazu steht zum Beispiel in der Apache-Konfiguration `php_admin_value memory_limit 128M`. Trotz `WP_MEMORY_LIMIT` 256M bleibt es bei 128M und der kritische Fehler kommt wieder. Die gleiche Direktive in der `.htaccess` führt zu einem Fehler 500, weil sie dort nicht erlaubt ist. In diesem Fall hilft nur die Einstellung im Kundenbereich des Hosters oder ein anderer Tarif. Erhöhen Sie das Limit nicht vorsorglich auf sehr hohe Werte. Ein Plugin, das 500 MB belegt, ist fehlerhaft, und ein höheres Limit verdeckt das nur. Zudem darf jeder Worker dann mehr Speicher belegen. > **Prüfen:** Im Website-Zustand steht bei `WP_MEMORY_LIMIT` der neue Wert, und die Seite mit dem vorherigen Speicherfehler lädt ohne Fehlermeldung. ## Schritt 6: Grenzen im Blick behalten Hosting-Grenzen ändern sich: Plugins kommen hinzu, Besucherzahlen steigen, der Hoster stellt Tarife um. Prüfen Sie den Bericht im Website-Zustand nach jedem größeren Update und nach Tarifwechseln, und halten Sie die Werte aus Schritt 1 in Ihrer Dokumentation fest. Achten Sie im Fehlerprotokoll auf wiederkehrende Meldungen zu `Allowed memory size` und `Maximum execution time`. Treten diese Meldungen häufiger auf, reicht der Tarif nicht mehr aus oder ein Plugin arbeitet fehlerhaft. Solche Kontrollen gehören zur laufenden Pflege, genau wie Updates und Sicherungen. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=62) übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und beginnt mit einer einmaligen Analyse der Website. > **Prüfen:** Ihre Dokumentation enthält die aktuellen Grenzwerte mit Datum, und das Fehlerprotokoll zeigt keine neuen Speicher- oder Zeitfehler. ## Typische Fehler **`Allowed memory size of 134217728 bytes exhausted`** Ein Aufruf hat das Speicherlimit von 128 MB überschritten. Verursacher steht in der Meldung. Limit per `WP_MEMORY_LIMIT` erhöhen, wenn der Hoster es zulässt, und das Plugin prüfen. **`WP_MEMORY_LIMIT` wirkt nicht** Der Hoster setzt das Limit mit `php_admin_value` oder in einer nicht änderbaren PHP-Konfiguration. Dann bleibt das Limit bei 128M. Ändern Sie den Wert im Kundenbereich des Hosters. **Fehler 500 nach Änderung der `.htaccess`** `php_admin_value` ist in der `.htaccess` nicht erlaubt, `php_value` funktioniert nur beim Apache-Modul, nicht bei PHP-FPM. Entfernen Sie die Zeile wieder. **WP-CLI zeigt andere Werte** Die Kommandozeile hat eine eigene PHP-Konfiguration. Zum Beispiel ist `max_execution_time` dort 0 statt 30. Maßgeblich für Besucher sind Website-Zustand und Testdatei. **Testdatei vergessen** `limits-test.php` oder `phpinfo()`-Dateien verraten Serverdetails. Löschen Sie sie direkt nach dem Test. **Mehr Worker, aber keine Besserung** Die CPU ist der Engpass. Bei 2 Kernen können 10 gleichzeitige Aufrufe trotz 150 erlaubter Prozesse bis zu 5,8 Sekunden brauchen. ## Häufige Fragen ### Wie viele PHP-Worker brauche ich? Dafür gibt es keine feste Zahl. Sie hängt von der Zahl gleichzeitiger Aufrufe ohne Cache und von deren Dauer ab. Eine Visitenkarten-Website mit Seiten-Cache kommt mit wenigen Workern aus, ein Shop mit vielen gleichzeitigen Bestellungen braucht mehr. Messen Sie die Antwortzeit und vergleichen Sie sie mit den Spitzenzeiten Ihrer Besucher. ### Was ist der Unterschied zwischen WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT? `WP_MEMORY_LIMIT` gilt für normale Aufrufe, `WP_MAX_MEMORY_LIMIT` für den Adminbereich und aufwendige Aufgaben wie die Bildbearbeitung. Der Standard für den zweiten Wert ist 256M, sofern das PHP-Limit nicht höher liegt. ### Hilft ein Seiten-Cache bei zu wenigen Workern? Ja, für nicht angemeldete Besucher. Eine Seite aus dem Cache belegt keinen oder nur sehr kurz einen PHP-Prozess. Warenkorb, Kasse, Suche und das Backend profitieren davon aber nicht. ## Fazit Die Grenzen Ihres Hostings sind messbar: Der Website-Zustand zeigt die PHP-Werte, eine Testdatei bestätigt sie aus Sicht des Webservers, und ein Lasttest mit wenigen Aufrufen macht die Worker-Warteschlange sichtbar. Erhöhen Sie Limits gezielt nach einer Fehlermeldung und nicht vorsorglich. Wer die regelmäßige Pflege rund um diese Kontrollen abgeben möchte, findet sie bei der [WordPress-Wartung](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=62) von Marcel Schönfelder. ## Weiterführende Anleitungen und Quellen - [WordPress schneller machen: Ladezeit messen und Engpässe finden](https://s-edv.com/anleitungen/wordpress-schneller-machen-ladezeit-messen-engpaesse-finden) - [WordPress Debug-Modus aktivieren und Error-Logs analysieren](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [PHP-Version für WordPress aktualisieren](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen) - [WordPress-Handbuch: wp-config.php](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/) - [PHP-Handbuch: FPM-Konfiguration](https://www.php.net/manual/de/install.fpm.configuration.php) - [Apache-Dokumentation: MaxRequestWorkers](https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers)