WordPress 3.5: Speicherlimit auf 40 MB erhöht

Im Zusammenspiel mit vielen Plugins, älteren PHP Versionen und anderen Faktoren kann WordPress recht schnell das festgelegte Speicherlimit überschreiten. Dies endet dann in der PHP typischen Fehlermeldung à la Fatal error: Allowed memory size of 999999 bytes exhausted.

In der aktuellen Version versucht WordPress das Speicherlimit auf 32 MB festzulegen. „Versucht“ deswegen, weil nicht jeder Webhoster den Zugriff über ini_set() zulässt.

In WordPress 3.5 wird das Speicherlimit nun auf 40 MB erhöht. Das liegt allerdings nicht daran, dass die zukünftige Version 8 MB mehr Speicher benötigt, sondern viel mehr daran, um die schon oben genannte Fehlermeldung zu unterdrücken bzw. mehr Spielraum zu bieten.

Persönliche Meinung: Ich hab die Erhöhung erstmal nicht befürwortet, da es meiner Meinung nach der falsche Weg ist. In der PHP Doku findet man folgende Aussage:

[memory_limit] Setzt den Maximalwert des Speichers in Byte, den ein Skript verbrauchen darf. Damit können schlecht geschriebene Skripte daran gehindert werden, den gesamten verfügbaren Speicher eines Servers „aufzufressen“.

Heißt im Umkehrschluss: Schlechte Skripte aka Plugins bekommen mehr „zu fressen“.

Allerdings muss es nicht immer ein schlechtes Plugin sein. Benutzer erwarten heutzutage leider immer mehr die eierlegende Wollmilchsau. Und natürlich spielt die Anzahl von Plugins auch eine wesentliche Rolle. — Nein, 50 aktive Plugins zu haben ist nicht normal.

Wie sieht dein Speicherverbrauch aus?

Der Speicherverbrauch meines Dashboards beläuft sich aktuell auf 19,6 MB bei 9 Datenbankabfragen, 7 aktivierten Plugins und deutscher Sprachdatei. Ein guter Wert, wie ich finde.
Diese Informationen lass ich mir übrigens bei jeder Seite durch ein kleines Plugin ausgeben. Das Plugin habe ich mal auf Github veröffentlicht.

Mich würde nun mal brennend interessieren, wie den dein aktueller Speicherverbrauch ausfällt und wie viele Plugins aktiviert sind? Würdet ihr von einer Speichererhöhung profitieren?

Zum Thema

Titelbild von jjackowski, CC BY-NC-SA 2.0.

23 thoughts on “WordPress 3.5: Speicherlimit auf 40 MB erhöht”

  1. Hallo Dominik,

    das Problem liegt glaube ich eher bei veralteten/mühsamen Hostern – ich hatte nicht nur einmal schon die Diskussion mit Technikern, das nicht mehr geht als 32. Dadurch werden wahrscheinlich viele Webseiten nach einem unbedachten automatischen Update sich verabschieden.

    Anbei mal meine Werte:
    Time : 3,013 | DB Queries: 46 | Memory: 29,8/256M | Cache Hits: 913 | Cache Misses: 112 | Active Plugins: 24

    1. Hi Patrick,

      ja, das ist das Problem mit den Shared Host Providern. Elegant unter „und anderen Faktoren“ zusammengefasst.
      Hat der Host zum Beispiel nur 1 GB RAM und jeder bekommt 64 MB Speicher zur Verfügung, so sind im Endeffekt nur 16 Nutzer für den Host möglich. Zu wenig/teuer.

    2. ich habe da viele im Auge, die dann crashen werden,
      hoffnungslos und genauso hoffnungslos, das diesen Leuten zu erklären.

      der Hoster ist der “Nachbar”, der den man seit Anbeginn des WWW kennt, der der die allererste html Seite hochgeladen hat, der wo man rübergeht und fragt wieso was so nicht läuft und gegen diese Argumente gibts nur das Angebot des netten , aber anonymen Hosters, der technisch perfekt, aber kein Gesicht hat.

      die wechseln eher die Software, denn den Hoster …

      ich stöpsel mein Tel. ab für diese Zeit

    1. Hi Tom,

      ja, durch die Sprachdatei wird leider auch viel Speicher benötigt.
      Dein genanntes Plugin prüft allerdings nur, ob gettext vorhanden ist.

      WordPress verwendet diese Library nämlich bis dato noch nicht. Es war nur geplant für 3.4, dann aber geschoben. Ticket: http://core.trac.wordpress.org/ticket/17268

      Es könnte also in Zukunft weniger werden, wenn denn die Variante implementiert wird.

  2. Grösserer 3.4.2 Website mit Child-Template, WPML-Plugin (2-sprachig), keine extra Cache-Plugins:
    Dashboard:
    Time : 1,111 | DB Queries: 94 | Memory: 39,8/128M | Cache Hits: 802 | Cache Misses: 129 | Active Plugins: 18
    Artikel:
    Time : 1,249 | DB Queries: 226 | Memory: 37,0/128M | Cache Hits: 2107 | Cache Misses: 194 | Active Plugins: 18
    Seiten:
    Time : 1,267 | DB Queries: 157 | Memory: 37,1/128M | Cache Hits: 1864 | Cache Misses: 169 | Active Plugins: 18
    Custom Post Type 1:
    Time : 1,379 | DB Queries: 197 | Memory: 38,1/128M | Cache Hits: 1821 | Cache Misses: 247 | Active Plugins: 18
    Custom Post Type 2:
    Time : 0,999 | DB Queries: 109 | Memory: 36,5/128M | Cache Hits: 991 | Cache Misses: 115 | Active Plugins: 18
    Menü:
    Time : 2,254 | DB Queries: 679 | Memory: 39,1/128M | Cache Hits: 5249 | Cache Misses: 313 | Active Plugins: 18

  3. Time : 0,662 | DB Queries: 79 | Memory: 22,2/256M | Cache Hits: 918 | Cache Misses: 127 | Active Plugins: 7

    und bekomme leider trotzdem den Fatal Error :(

    1. Ich würde mal den verfügbaren Speicher mit phpinfo(); prüfen. Dominiks Plugin meint ich hätte ebenfalls 256MB RAM zur Verfügung, tatsächlich sind es aber nur 64MB.

    2. Nein ist nicht korrekt. Das Plugin ließt auch bei ini_get aus, nur bevor WordPress die Speicherverwaltung durchgeführt hat. Das maximale Limit wird jedoch durch WP_MAX_MEMORY_LIMIT gesteuert.

    3. Mit “korrekten 64MB” meine ich, die 64MB die in der php.ini stehen und die für gewöhnlich auch verfügbar sein müssten.


      <?php
      ini_set( 'memory_limit', 34359738368 );
      var_dump( ini_get( 'memory_limit' ) );

      Auf meinem PC kann ich das Limit problemlos auf 32GB hoch schrauben obwohl nur 8GB RAM installiert sind. Auf meinem Webspace geht es wegen PHP5.2 “nur” bis 2GB. Nun sitzen auf dem Server wo ich meinen Webspace habe noch 99 andere Kunden, da gehe ich mal davon aus das ich noch nicht einmal die 256MB bekomme die mir WordPress verspricht.

      Das der Wert den man über ini_get('memory_limit'); auch mal Tinnef sein kann, zeigt sich ja daran, dass man mit ini_set( 'memory_limit', -1 ); das Maximum an verfügbaren Speicher abrufen kann. Über ini_get() bekommt man in diesen Fall logischerweise auch nur ‘-.1’ als Wert zurück. Die Ausgabe im Footer wäre demnach in etwa “43,91MB von -1MB RAM in Benutzung”.

      Aber selbst wenn die ini_get(); einen glaubwürdigen Wert zurück liefert, ist es nicht sicher das PHP auch auf diese Menge an Speicher zurück greifen kann.
      PHP ist halt so ziemnlich die letzte Schicht in einen weitaus komplexeren System. Der Apache bietet von Haus aus z.B. die RLimitMEM-Direktive mit der man z.B. PHP-CGI den Speicher begrenzen kann. Viele Apache-Server sind obendrein mit dem Suhosin-Patch ausgestattet. Der Suhosin-Patch hat eine Einstellung die dafür sorgt das PHP nie mehr Speicher zugeteilt wird als in der php.ini eingestellt ist. Alternativ kann man Suhosin so einstellen, dass zu dem Wert aus der php.ini nur maximal x MB mehr reserviert werden können.

      Ich werde zur Sicherheit aber mal bei meinem Hoster nachfragen ob ich tatsächlich 2GB Speicher in Beschlag nehmen kann. Glauben kann ich es zumindest nicht.

    4. Ok, jetzt hab ichs verstanden.

      Bis dato war mir gar nicht bewusst, dass da anscheinend keine Überprüfung stattfindet.

      Es scheint, als gibt es auch keine wirkliche zuverlässige Aussage über das maximale Limit. Keiner Austausch mit meinem Hoster: https://twitter.com/ocean90/statuses/249615605815201792

      Bleibt also nur die Prüfung mit get_cfg_var(). Wenn ini_set() mehr ausgibt dann den Wert von get_cfg_var() nutzen, ansonsten den Wert von ini_set().

    5. support@all-inkl.com

      Sehr geehrter Herr Albert,

      standardmäßig sind 64 MB eingetragen mit PHP ini_set oder auch .htaccess php_value können Werte bis 256 MB gesetzt werden.
      Allerdings, sollten durch zu Hohe Werte der Server ausgelastet werden, können wir die Werte eigenmächtig zurücksetzen oder auch, Ihre Domains auf einen Isolationsserver ziehen, bis die Auslastung wieder auf einen vernünftigen Rahmen ist.

      Scheint mir so als wenn sich bis jetzt niemand so wirklich einen Kopf um das Problem gemacht hat. Bei 32GB Speicherverbrauch ist der Server so ausgelastet, dass die mir wohl eher die Domain kündigen würden ;)

  4. >>Time : 1,194 | DB Queries: 20 | Memory: 41,4/256M | Cache Hits: 479 | Cache Misses: 63 | Active Plugins: 11
    (Alle Plugins deaktiviert, sind es immer noch rund 39MB)

    Das Problem bei mir sind demnach definitiv nicht die Plugins, sondern das vier oder fünf Jahre alte Theme. Demnach ist die Anzahl der Plugins auch völlig wumpe. Packe ich die Funktionen aus den Plugins in die functions.php, spare ich mir damit nicht ein einziges Byte.
    Die Architektur von WP dürfte auch das grundsätzliche Problem sein. Wenn man gnadenlos alles in den globalen Namensraum packt, dann geht dabei halt jede Menge Speicher drauf. Und leider wird der gobale Namensraum ja nicht schlanker, sondern, eher ganz im Gegenteil, kommt mit der Zeit immer mehr hinzu.

    Hat der Host zum Beispiel nur 1 GB RAM und jeder bekommt 64 MB Speicher zur Verfügung, so sind im Endeffekt nur 16 Nutzer für den Host möglich.

    Öhmm nö. Der Speicher wird dynamisch vergeben, nicht statisch. Memory Limit ist eigentlich nur eine Zusage an den Benutzer das er diesen Wert an Speicher verbrauchen kann. Das bedeutet nicht, das der Benutzer auch physikalisch über diesen Speicherbereich verfügen kann. Zumindest nicht jederzeit.
    Stellen wir uns mal einen Server mit 640MB Speicher vor. Dort sind 10 Benutzer die alle nur 15MB verwenden obwohl das Memory Limit bei 64MB liegt. Das bedeutet, das maximal 150MB Speicher verwendet werden. Man könnte also noch weitere 10 Benutzer anlegen und denen 64MB Memory Limit zuweisen ohne das es Probleme gibt. Erst wenn alle 20 Benutzer gleichzeitig weit mehr als 30MB verbrauchen, kommt es zu Problemen.
    Aber selbst das lässt sich über MaxClients in der Apache-Config lösen. Habe ich nur 640MB zur Verfügung, und sage jedem Benutzer 64MB zu, können halt nicht mehr als 10 Anfragen gleichzeitig beantwortet werden. Der Rest muss sich hinten anstellen.

    Memory Limit ist also keine physikalisch Grenze die man nicht verschieben kann. Es ist eine Abmachung um einen reibungslosen Ablauf zu gewähren. Von daher dürfte es auch wenige Probleme geben wenn WP zukünftig 40MB max. Memory anfordert (ob es diese 40MB auch bekommt, ist eine andere Frage).
    Da PHP 5.2 den vorhandenen RAM deutlich besser ausnutzt als PHP <5.2, sollten auch nicht gleich alle Billighoster die Flügel strecken.

  5. Bei mir wird´s auch immer mehr :(

    Time : 0,418 | DB Queries: 42 | Memory: 43,3/256M | Cache Hits: 684 | Cache Misses: 117 | Active Plugins: 11

    Anmerkung: 64Bit OS mit deutscher Sprachdatei

    Ohne Sprachdatei komm´ ich dann auf folgendes:

    Time : 0.322 | DB Queries: 42 | Memory: 31,9/256M | Cache Hits: 682 | Cache Misses: 117 | Active Plugins: 11

  6. Ich bekomme auf einer Installation mit BuddyPress und diversen komplizierteren Plugins auf einem 64Bit-Server folgende Werte:
    Time : 1,212 | DB Queries: 85 | Memory: 66,4/128M | Cache Hits: 898 | Cache Misses: 84 | Active Plugins: 16

  7. Zum Glück muss ich mir bei meinem Hoster wp-webhosting.de darüber keine Gedanken machen, dort habe ich 256 MB Memory-Limit zur Verfügung stehen.

  8. Bezüglich Datenbank und Speicher habe ich ein Problem. Es wäre schön wenn in der Runde mir jemand eine Lösung anbieten könnte.

    —————————————————————————————————–
    Auf meinem Blog läuft das Plugin “WP-Optimize”.
    Nach Optimierung sagt mir das Tool “Total Size of Database: 56659.503 Kb”

    Wenn ich mich in auf den Server einlogge zeigt der mir an:
    Von Datenbanken verwendeter Speicherplatz 473.56 MB
    —————————————————————————————————–

    Die Zahlen klaffen schon mächtig auseinander. Kennt sich damit jemand aus?

    Grüße aus Hamburg

Leave a Reply