Allowed memory size exhausted-Meldung zeigt an, dass ein einzelner PHP-Anfrage die definierte memory_limit-Wert verbraucht hat. Freier RAM auf dem Server ändert diese Grenze nicht. Zuerst müssen Sie den Verbrauch verursachende Plugin, Abfrage oder Prozess finden; dann sollten Sie die geeigneten WordPress- und PHP-Grenzen in einem ausgewogenen Verhältnis anpassen.
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
tried to allocate 4096 bytes
wp-includes/class-wpdb.php on line ...
PHP memory_limit ist die maximale Menge an Speicher, die jeder PHP-Prozess verwenden kann. WP_MEMORY_LIMIT legt den Wert fest, den WordPress für normale Operationen benötigt, während WP_MAX_MEMORY_LIMIT den oberen Wert für einige Operationen auf der Verwaltungseite festlegt.
Haben Sie auf dem Server 64 GB RAM, so wird dies nicht verhindern, dass ein einzelner PHP-Anfrage die 128 MB-Grenze überschreitet. Im Gegensatz dazu kann eine zu hohe Grenze dazu führen, dass alle RAM der gleichzeitigen PHP-Prozesse verbraucht werden.
Der 'tried to allocate'-Wert im Log ist nicht die Gesamtnachfrage; es ist der letzte zusätzliche Betrag, der nachdem der Prozesslimit voll ist, angefordert wird. Der tatsächliche Verbraucher sollte im Stack-Trace und im Datei gefunden werden.
WooCommerce-Import, große Bildverarbeitung, Elementor-Editor, Backup- und Berichts-Plugins können mehr Speicher als reguläre Seiten verbrauchen. Die Verwaltungsgrenze sollte getrennt bewertet werden.
Der Objekt-Cache, große autoload-Optionen-Einträge und endlose Query-Loops können die Speicherabfrage erhöhen. Wenn es nach der Erhöhung der Grenze wieder ansteigt, wurde der Wurzelproblem nicht gelöst.
memory_limit=-1 ist in einem lebenden Hosting-Umgebung keine sichere Lösung. Die Anzahl der PHP-FPM-Arbeiter und die Prozesse pro Thread-Limit sollten gemeinsam berechnet werden.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: PHP hat den memory_limit-Wert für die Anfrage erreicht.
Mögliche Ursache: Schwere Erweiterung, große Daten, Schleife oder niedriger Grenzwert.
Bedeutung: Zeigt die nach Erreichen des Limits angeforderte letzte Menge an.
Mögliche Ursache: Zeigt den Gesamtspeicherbedarf nicht allein an.
Bedeutung: PHP oder das Betriebssystem kann keine Speicherbereiche allozieren.
Mögliche Ursache: PHP Grenze, globale RAM oder OOM.
Bedeutung: WordPress verwendet für normale Operationen eine geringere Anfrage.
Mögliche Ursache: wp-config-Konstante oder Standardwert
Bedeutung: Die Verwaltungsvorgänge haben die WordPress-Grenze überschritten.
Mögliche Ursache: Import, Update, Bericht oder Editor.
Bedeutung: Bei der Verarbeitung eines großen Bildes ist der Speicher aufgebraucht.
Mögliche Ursache: Hohe Auflösung, Imagick/GD und niedrige Grenzwerte.
Bedeutung: WooCommerce unter der empfohlenen Wertgrenze sieht
Mögliche Ursache: Web PHP- und CLI-PHP-Einstellungen können sich unterscheiden.
Bedeutung: Kernel tötete den PHP-Prozess wegen globaler RAM-Druck.
Mögliche Ursache: Übermäßiger Arbeiter, Ausfall von Swap oder Speicherleck.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
php -r 'echo ini_get("memory_limit"), PHP_EOL;'
CLI zeigt den effektiven memory_limit-Wert an.
wp config get WP_MEMORY_LIMIT 2>/dev/null
wp config get WP_MAX_MEMORY_LIMIT 2>/dev/null
Ist in der wp-config eine benutzerdefinierte Limitierung definiert?
wp eval 'echo WP_MEMORY_LIMIT." / ".WP_MAX_MEMORY_LIMIT.PHP_EOL;'
Zeigt die von WordPress gesehenen normalen und Admin-Grenzen an.
wp db query "SELECT option_name,LENGTH(option_value) boyut FROM wp_options WHERE autoload='yes' ORDER BY boyut DESC LIMIT 20;"
Erkennen Sie autoloadete große Optionen; warnen Sie, wenn das Präfix unterschiedlich ist.
ps -eo pid,user,%mem,rss,etime,cmd --sort=-rss | grep -E 'php-fpm|lsphp' | head -n 30
Zeigt die PHP-Prozesse mit dem höchsten RAM-Verbrauch an.
journalctl -k --since '2 hours ago' | grep -Ei 'oom|out of memory|killed process'
Trennt die PHP-Grenze aufgrund globaler RAM-Auslastung.
Die Grundursache des WordPress-Fehlers ist dieselbe, aber Protokollpfade, PHP-Einstellungsbildschirme und Dienstverwaltung variieren je nach verwendeter Hosting-Infrastruktur.
cPanels MultiPHP INI Editor und MultiPHP Manager verwalten Web- PHP-Werte.
php -r 'echo ini_get("memory_limit"), PHP_EOL;'Die Plesk PHP-Einstellungen-Seite legt die memory_limit-Werte pro Domain fest.
cd /var/www/vhosts/ALANADI/httpdocs && wp eval 'echo WP_MEMORY_LIMIT;'In einer panellosen Serverumgebung werden php.ini, FPM-Pool und Workerkapazität zusammen berechnet.
php --ini && systemctl list-units 'php*-fpm.service' --no-pagerMessung des echten Web- PHP-Grenzwert, finden Sie den Fehler-Log, isolieren Sie den konsumierenden Komponenten und setzen Sie kontrollierte Grenzwerte mit Kapazitätsabrechnung.
Speichern Sie den Fehler, der in der Plugin-, Theme- oder Core-Aufruf auftritt.
tail -n 150 wp-content/debug.logDas PHP im Browser und der SSH php-Befehl können unterschiedliche ini-Dateien verwenden.
php --iniImport, Editor oder Cron-Job mit kontrolliert isolierten Plugin-Installation für den Test.
wp plugin list --status=activeVerwenden Sie eine vernümftige WP_MEMORY_LIMIT/WP_MAX_MEMORY_LIMIT für normale und Admin-Bereiche.
Vergleichen Sie max_children und die GesamtrAM mit dem tatsächlichen RSS am Anfang des Prozesses.
ps -eo rss,cmd --sort=-rss | grep php-fpm | headPeak-Benutzung, Log und globale RAM-Verhalten überprüfen.
Der Admin-Speicher, die Anzahl der Erweiterungen und die großen Template-Daten werden untersucht.
Das File in Teile aufteilen, die Batch-Größe und Action Scheduler prüfen.
Große Pixelgröße, Imagick-Richtlinie und Miniaturbild-Generierung werden überprüft.
Speicherleak, Schleife oder sehr große Autoload-Daten werden untersucht.
Dies ist nicht nur PHP memory_limit, sondern ein globales OOM-Problem.
journalctl -k | grep -Ei 'oom|killed process'Nein. Die PHP-Einstellung memory_limit ist die Obergrenze; die WordPress-Einstellung ist der vom Anwendungsprogramm geforderte Wert und kann die Obergrenze von PHP nicht überschreiten.
Es variiert je nach Site und Prozessart; 128–256 MB ist üblich, aber der tatsächliche Prozessverbrauch und die Serverkapazität sollten gemessen werden.
PHP legt für jeden Vorgang einen separaten memory_limit fest.
Nein; der Limit ist die gewünschte Menge nachdem der Limit gefüllt ist.
Import, Bericht, Produktvariation und Admin-Aufgaben können mehr Ressourcen als ein Standardblog verbrauchen.
In der Regel nein; es löst nur Speichermangel. Überschreiten Sie die Grenzen nicht, da dies globalen RAM-Druck verursachen kann.
WordPress identifiziert höhere Speicheranforderungen für einige schwere Operationen auf der Verwaltungseite.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.