Fatal error: Allowed memory size of 1234 bytes exhausted

WordPress-Bug Passiert ab und an. Man installiert ein WordPress-Plugin, will es aktiveren … und zack hat man einen weißen Bildschirm mit einer Fehlermeldung, die in etwa so ausschaut:

Fatal error: Allowed memory size of 12345 bytes exhausted (tried to allocate 321 bytes) in /irgend/ein/ordner/wp-content/plugins/[…].php on line 789

Was ist passiert? In der PHP-Konfiguration gibt es mit memory_limit einen Wert, der bestimmt wie viel ein PHP-Skript an Arbeitsspeicher verbrauchen darf und da WordPress auf PHP basiert, gilt diese Begrenzung auch für WordPress und die Plugins. Die Begrenzung an sich ist sinnvoll, da der Server somit vor schlecht geschriebenen Skripten geschützt werden kann.

Allerdings ist es so, dass die Standardeinstellung zu niedrig angesetzt ist und lange nicht mehr reicht. Wie kann man die Grenze erhöhen? Vorausgesetzt man kann den Wert beeinflussen stehen auf einer durchschnittlichen Hostingplattform mindestens zwei Wege zu Verfügung.

Methode 1: .htaccess

Bei der ersten Methode erweitert man die die Konfigurationsdatei von Apache (.htaccess). Einfach folgenden Code in die .htaccess-Datei im Hauptordner einfügen:

php_value memory_limit 128M

Damit bekommt nicht nur WordPress sondern alle PHP-Anwendungen innerhalb dieses Bereich 128mb Arbeitsspeicher zur Verfügung. Falls dies nicht erwünscht wird, kann man die zweite Methode anwenden.

Methode 2: wp-config.php

Wenn man die Konfigurationsdatei der jeweiligen WordPress-Installation (wp-config.php) um folgenden Eintrag erweitert…

define('WP_MEMORY_LIMIT', '128M');

… dann stehen nur der entsprechenden Installation 128mb Arbeitsspeicher zur Verfügung.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

17 Kommentare

  1. … interessant … würde die htaccess-Variante auch die Geschwindigkeit insgesamt erhöhen?

    1. Hallo Reinhard,

      bei Frontend habe ich das jetzt so nicht beobachtet, auf jeden Fall hilft die Erhöhung des Speichers der Performance im Admin-Bereich.

    2. … habe es mal etwas anders – mit GTmetrics getestet (www.cms-flex.de) page-size 191KB … kein signifikanter Unterschied – mal 1.06s und mal 1.14s – . Allerdings nicht mit htaccess sondern mit: ini_set(‘memory_limit’, ‘128M’); -> Hosting bei 1und1 … bei htaccess habe ich Error 500 bekommen …

  2. Durch die Verbreitung von WordPress sollte es sich kaum noch ein Provider erlauben können, das PHP-Limit so niedrig anzusetzen, dass WordPress Probleme bekommt. Es sei denn, man lockt mit Dumpingpreisen, um dann Aufpreise verlangen zu können.

    Als WordPress vor Jahren so richtig in Mode kam, hatte ich ein einziges Mal Probleme mit dem memory_limt. Das lag aber glaube ich um die 30MB. Dieser Hoster war dann nicht mehr lange mein Hoster.

    Bei all-inkl.com liegt das Limit glaube bei 64MB. Damit hatte ich noch nie Probleme. Aber das gute ist, da funktionieren ja deine beiden angegeben Varianten im Notfall.

    1. Hallo Sebastian,

      ich hatte vorhin, und das war der Grund für den Artikel, Probleme auf einem all-inkl-Server. Standard-Einstellung war, wie du es erwähnt hast, 64mb, was in der Regel auch ausreicht. Allerdings gab es dann bei der Aktivierung eines neuen Plugins den o.g. Fehler, weil 65mb notwendig gewesen wären. 🙂

        1. Auf der Website waren so gut ein dutzend Plugins bereits aktiv und da wollte ich Jetpack aktivieren. Jetpack hat die Angewohnheit mehrere Module direkt aktivieren zu wollen und das war dann ein bisschen zu viel.

  3. Das Problem hatte ich auch schon mal bei einer meiner Webseiten. Ich weiß noch, dass mich die Fehlersuche etliche Stunden gekostet hat. Irgendwann bin ich dann auf das Speicherproblem gestoßen. Die Fehlermeldung ist so herrlich aussagekräftig :/
    Guter Artikel, wird hoffentlich vielen helfen 🙂

  4. Hallo Vladimir,

    ich kann von all-inkl.de und dem php_value memory_limit 64MB auch ein Liedchen singen. Da ich damals noch nicht wusste, woher dieser Fehler kommt, habe ich das zuletzt installierte Plugin einfach hart wieder vom FTP gelöscht.

    Nicht gerade elegant, aber der “white screen of death” war dann mal weg!

    Eine kurze Nachfrage bei all-inkl.de hat dann alles schnell und einfach in Wohlgefallen aufgelöst. Da kann man nicht meckern!

    Frage: Gibt es eine bessere bzw. elegantere Möglichkeit, als das Plugin hart vom FTP runterzuschmeissen?

    Gruß
    Matthias

    1. @Matthias:
      Das Plugin einfach aus dem Ordner zu löschen, ist schon in Ordnung, wenn man ins Backend nicht rein kommt. WordPress erkennt, dass das Plugin nicht mehr existiert, und löscht einfach den Eintrag im Backend.

      1. Hallo Torsten,

        vielen Dank für den Hinweis. Habe ich nicht gewusst!

        Mir zwar aufgefallen, dass nach meinem Löschen der Plugin Eintrag im Backend fehlt, aber ich dachte so bei mir …
        Zauberei! 😉

        Schönen Feiertag

        Gruß
        Matthias

  5. TOP 🙂
    hatte seit gestern auch gesucht und verschiedene Plugins deaktiviert. Konnta aber eigentlich keinem der Plugins diesen Fehler tatsächlich zuordnen.

    Danke und Gruß, Rainer

  6. Hatte das Problem mit dem niedrigen Memory-Limit bei meinem alten Provider auch, bin dann mit meinem Blog zu WP-Webhosting gewechselt und die Sache war erledigt.

  7. bei Frontend habe ich das jetzt so nicht beobachtet, auf jeden Fall hilft die Erhöhung des Speichers der Performance im Admin-Bereich

    Da ich im Adminbereich auch etwas Performance Probleme beim Erstellen von neuen Beiträgen habe, hört sich das nicht schlecht an. Kann man irgendwo einfach überprüfen wieviel Speicher das aktuelle Limit sind und wie viel davon beansprucht wird?

    Vielen Dank

  8. Das memory_limit lässt sich bei all-inkl in meinen Tarif über diesen htaccess Eintrag problemlos setzen, bzw. ist bei WP Installationen über deren Tools sogar standardmäßig gesetzt:
    php_value memory_limit 256M

    Wichtig ist auch die Wahl einer geeigneten PHP-Version. Die CGI Variante von PHP 5.3 beansprucht im Backend 84MB, ab PHP 5.4 nur 42MB wobei ich PHP 5.6 aufgrund der Performance bevorzuge.

    @Det, ich benutze das Plugin WP-Memory-Usage

  9. Hallo zusammen,
    habe bei mir auch die Fehlermeldung entdeckt.
    Würde das auch folgendes erklären?: Es passiert mir immer wieder dass nach dem Bearbeiten von Seiten (ich benutze WP 3.9) die Inhalte nicht mehr stimmen. D.h. es wird irgendwas angzeit, was woanders hingehört. Wenn ich dann wieder ins Backend gehe, dann kann ich die Seiten normal bearbeiten, aber wenn ich dann auf Edit klicke, wird mir wieder die falsche Seite angezeigt.
    Ich hab das nun mit den Tipps versucht, bin als Laie aber offenbar zu blöd:
    (a) .htaccess. Da hab ich zwei; einmal im Root-VZ des Servers, einmal im WP-Verzeichnis. Aber bei beiden kriege ich eine Fehlermeldung. Ich kann mich nicht mehr anmelden. Vielleicht hab ich’s ja an die falsche Stelle geschrieben.
    Bei dem jetzt wieder vorhandenen Chaos auf meiner Site graut’s mir.
    DAnke für eure Hilfe
    (b) hab ich als Laie erst gar nicht versucht.

Kommentare sind geschlossen.