Wie viel RAM braucht WordPress?
WordPress selbst braucht wenig Arbeitsspeicher, und seine offiziellen Anforderungen nennen keine RAM-Zahl. Für eine kleine Website sind 1-2 GB RAM meist ein guter Ausgangspunkt (eine Faustregel, die je nach Website variiert). Shops, viele Plugins und starker Datenverkehr können den Bedarf auf 4 GB oder mehr treiben.
Was Sie tatsächlich brauchen, hängt von der Art der Website ab: den Plugins, dem Datenverkehr, der Größe der Datenbank und davon, ob Caching eingeschaltet ist. Dieser Artikel behandelt die offiziellen Zahlen, was Speicher frisst und woran Sie merken, dass er nicht reicht.
Was sagen die offiziellen Anforderungen?
Die Seite mit den Hosting-Anforderungen auf WordPress.org (eine offizielle Empfehlung) verlangt PHP 8.3 oder neuer, MariaDB 10.11 oder MySQL 8.0 oder neuer und HTTPS-Unterstützung. Als Webserver empfiehlt sie Apache oder Nginx. Eine Zahl für den RAM nennt die Seite nicht. Ältere Versionen wie PHP 7.4 und MySQL 5.5.5 laufen noch, doch die Seite weist darauf hin, dass sie das Ende ihrer Lebenszeit erreicht haben und Sicherheitsrisiken bergen. Wählen Sie bei einer Neuinstallation die empfohlenen Versionen.
Die einzigen offiziellen Speicherzahlen sind die Limits, die PHP WordPress einräumt. Bei einer Einzelinstallation beträgt der Standardwert von WP_MEMORY_LIMIT 40 MB, bei Multisite 64 MB. Der Admin-Bereich nutzt WP_MAX_MEMORY_LIMIT, und der WordPress-Kern versucht standardmäßig, es auf 256 MB anzuheben. Das sind Obergrenzen für eine einzelne PHP-Anfrage, nicht der gesamte RAM des Servers. Die für Ihre Website geltenden Werte sehen Sie unter Tools > Site Health > Info: Das PHP-Speicherlimit steht im Abschnitt Server, WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT im Abschnitt WordPress Constants.
Was braucht wirklich den RAM?
- PHP-Prozesse. Jede gleichzeitige Anfrage startet einen PHP-Prozess. In PHP-FPM begrenzt
pm.max_children, wie viele gleichzeitig laufen können (siehe das PHP-Handbuch). Je nach Plugins kann ein Prozess zwischen zehn und mehreren hundert Megabyte belegen. Das ist eine allgemeine Beobachtung und unterscheidet sich von Website zu Website. - Die Datenbank. MariaDB oder MySQL hält häufig gelesene Daten im Arbeitsspeicher. Große, plugin-lastige Websites wollen mehr.
- Der Cache des Betriebssystems. Linux nutzt freien Arbeitsspeicher als Festplatten-Cache. Wenig freier Speicher in der Ausgabe von
free -hist kein Problem. Schauen Sie stattdessen auf die Spalte Verfügbar. - Cache-Schichten. Ein Objekt-Cache (etwa Redis) verringert Datenbankabfragen, belegt aber selbst Arbeitsspeicher.
Ein einfaches Beispiel. Reservieren Sie auf einem Server mit 2 GB RAM etwa 1 GB für Betriebssystem und Datenbank, bleibt 1 GB für PHP. Braucht ein PHP-Prozess durchschnittlich 100 MB, ist es sinnvoll, pm.max_children bei etwa 10 zu halten. Diese Zahlen zeigen nur, wie die Rechnung funktioniert. Ihre eigenen Messungen können anders ausfallen.
Startgröße nach Art der Website
Diese Werte sind Faustregeln. Sie variieren je nach Plugins und Datenverkehr und sind kein festes Versprechen.
| Art der Website | Start-RAM | Hinweis |
|---|---|---|
| Kleiner Blog oder Visitenkarten-Website, wenige Plugins | 1-2 GB | Seiten-Cache einschalten |
| Unternehmenswebsite mit vielen Formularen und Bildern | 2-4 GB | Bilder verkleinern |
| Page Builder, Mitgliederbereich, viele Plugins | 4 GB | Mehr Seiten, die sich nicht zwischenspeichern lassen |
| Online-Shop (WooCommerce) | 2-4 GB, mehr bei Wachstum | Warenkorb und Kasse lassen sich nicht zwischenspeichern |
Wenn Sie einen Shop aufbauen, lesen Sie auch unseren Artikel „Server für WooCommerce wählen“.
Was sehen Sie, wenn der RAM ausgeht?
- Die Website liefert hin und wieder einen 502- oder 503-Fehler. PHP-FPM oder der Webserver kann nicht antworten.
- Die Meldung „Error establishing a database connection“ erscheint. Die Datenbank wurde womöglich beendet, weil der Arbeitsspeicher ausging.
- Der Admin-Bereich wird sehr langsam, und Plugin-Updates oder Bild-Uploads bleiben auf halbem Weg hängen.
Zur Bestätigung verbinden Sie sich mit dem Server und führen diese Befehle aus:
free -h
sudo journalctl -k | grep -i -E "out of memory|oom-kill"
Der zweite Befehl listet die Ereignisse auf, bei denen der Kernel ein Programm beendet hat, weil der Arbeitsspeicher ausging. Gibt er Zeilen aus, reicht der RAM nicht. Drücken Sie in top Shift+M, um die Prozesse mit dem größten Speicherverbrauch zu sehen.
Was Sie vor dem Vergrößern versuchen können
- Richten Sie einen Seiten-Cache ein, als Plugin oder serverseitig. Eine Seite aus dem Cache führt weder PHP noch die Datenbank aus.
- Entfernen Sie Plugins, die Sie nicht nutzen. Jedes aktive Plugin lädt bei jeder Anfrage seinen Code.
- Stimmen Sie
pm.max_childrenin PHP-FPM auf Ihren Arbeitsspeicher ab. Grob gesagt teilen Sie den Speicher, den Sie PHP geben können, durch den durchschnittlichen Speicher eines PHP-Prozesses. Ein zu hoher Wert frisst unter Last Speicher. - Ein kleiner Swap-Bereich verhindert Abstürze bei kurzen Spitzen. Swap liegt aber auf der Festplatte und ist langsam, ersetzt also keinen RAM.
Haben Sie das alles versucht und der Speicher läuft trotzdem voll, ist es Zeit zu vergrößern. Messen Sie zuerst: Tritt das Problem zu Stoßzeiten auf oder den ganzen Tag? Als allgemeine Schwelle denken Sie über ein Vergrößern nach, wenn der Verfügbar-Speicher zu Stoßzeiten oft unter 10-15 Prozent des gesamten RAM fällt oder Swap ständig in Benutzung ist. Das ist keine feste Regel, nur ein Anhaltspunkt.
Im Panel vergrößern
Im Seturack-Panel vergrößern Sie den Server mit dem Regler auf dem Reiter Größe. Nach der Zahlung startet der Server einmal von selbst neu, und Ihre IP-Adresse und Ihre Daten bleiben gleich. Mit einer kleinen Größe zu beginnen ist deshalb ein sicherer Weg. Ein Server mit vorinstalliertem WordPress ist in etwa 3,5 bis 4 Minuten bereit. Sehen Sie sich die Seite zum WordPress-Server an.
Kommentare0
Noch keine Kommentare
Schreiben Sie den ersten Kommentar und teilen Sie Ihre Gedanken.
Bitte melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen.