Ursache des enormen Speicherbedarfs gefunden!

Das Aktualisieren (Updaten) dieser WordPress-Installation auf WordPress 2.8.x ging mit einem enormen zusätzlichen PHP-Speicherbedarf einher (siehe hierzu meinen Blogbeitrag „Webseiten-Infos.de auf WordPress 2.8.1 aktualisiert„).

Mit WordPress 2.7.1 und vielen Plugins betrug im Administrationsbereich (Backup) der PHP-Speicherbedarf bereits beachtliche 28 bis 30 MB. Bei meinem vorhergehenden Hoster one.com gab es aber eine PHP-Speicherbegrenzung (ein PHPMemory-Limit) von 24 MB, das nicht erhöht werden konnte. Deshalb war ich zu alfahosting.de gewechselt (siehe hierzu den Blogbeitrag „In eigener Sache: Umzug zu Alfahosting„).

Die PHP-Speicherbegrenzung und -Speicherauslastung kannst Du übrigens beispielsweise mit den Plugins WP Security Scan und WP System Health überprüfen.

Inzwischen hat der Autor des WordPressPlugins WP System Health, Heiko Rabe, die wohl wichtigste Ursache des enormen zusätzlichen PHP-Speicherbedarfs beim Aktualisieren (Updaten) von manchen WordPress-Installationen auf WordPress 2.8, 2.8.1 bzw. 2.8.2 gefunden:

Sofern der Hoster als Plattform ein 64Bit-System einsetzt, verdoppelt sich beim Wechsel auf WordPress 2.8.x der Speicherbedarf fast. Anscheinend werden dann fast doppelt so große Speicherblöcke durch WordPress belegt (siehe hierzu den Blogbeitrag „Enormer PHP-Speicherverbrauch – Ursache gefunden?!“ bei WordPress-Deutschland.org). Mit dem Plugin WP System Health kannst Du über Details beim Server Setup auch feststellen, ob bei Deinem Hoster als Plattform ein 32- oder 64Bit-System zum Einsatz kommt.

Sofern Dein Hoster als Plattform ein 32Bit-System verwendet, musst Du mit einem etwa 4 MB höheren PHP-Speicherbedarf bei einer Aktualisierung (einem Update) Deiner WordPress-Installation von der Version 2.7.x zu 2.8.x ausgehen. Bei einem 64Bit-System ist dagegen der PHP-Speicherbedarf deutlich höher.

Etwas lässt sich der Speicherhunger von WordPress 2.8.x jedoch durch den Austausch der für die Verarbeitung der (deutschen) Sprachdateien zuständigen Datei mo.php durch eine Betaversion von Heiko Rabe reduzieren. Die diesbezüglichen Einzelheiten und die gezippte Datei gibt es im Blogbeitrag „WordPress 2.8 – Sprachdatei Speicherverbrauch minimieren“ und eine erste Analyse zu dem Betatest unter „WordPress Sprachdateiverarbeitung Betatest – erste Analysen“ auf code-styling.de.

Ich habe übrigens diese geänderte mo.php von Heiko Rabe bereits hier im Einsatz. Sie reduzierte den PHP-Speicherverbrauch um 4,6 MB!

Probleme: Bisher keine!

17 Kommentare und 3 Trackbacks/Pingbacks

  1. 1. Ute

    Kommentar vom 27. Juli 2009 um 22:55

    Heftig, dass nur die optimierte Sprachdatei schon so viel ausmacht. Allerdings meine ich ist das ein weiterer Negativpunkt für WordPress.

    Aus meiner Sicht spricht inzwischen schon einiges gegen WP, wäre ein Wechsel nicht so aufwändig, hätte ich es wohl schon getan.

    Ich fürchte der hohe Marktanteil tut einfach nicht gut, schade…

  2. 2. Dieter

    Kommentar vom 27. Juli 2009 um 23:14

    @Ute
    Seltsam auch, dass der erhöhte Speicherverbrauch bei 64Bit-Systemen erst mit WP 2.8 auftritt. Da müssen die Entwickler wohl etwas unter der Haube verändert haben.

    In der Tat hält auch mich der hohe Aufwand von einem Wechsel zu einer anderen Software ab.

    Allerdings gibt es für WordPress eine besonders aktive Online-Community und mit Abstand das umfangreichste Literaturangebot. Für mich als Autodidakt ist das wichtig.

    Gäbe es das auch für eine andere Blogsoftware bzw. ein anderes CMS würde ich mich wohl leichter aufraffen und mal diese Software ausprobieren.

  3. 3. Ute

    Kommentar vom 28. Juli 2009 um 00:18

    Mich stört massiv, dass die Entwickler selbst bei bekannten Problemen manchmal keine Lösung suchen. Gekrönt von den Trackbackproblemen bis hin zu der Aussage, es wäre nicht nötig etwas zu ändern, weil das Problem ja nicht überall auftrete…

    Bezogen auf Literatur ist WP sicher führend, auch hinsichtlich der Größe der Community, aber z.B. bei Serendipity scheint mir die Aktivität sehr hoch. Der direkte Kontakt zu den Entwicklern klappt besser. Außerdem gibt es nicht ständig Updates, die jedesmal ein Glücksspiel sind…

    Bleibt noch der Aufwand des Wechselns, der relativiert sich jedoch bei der Updatefrequenz und der häufigen Fehlersuche…

  4. 4. codestyling

    Kommentar vom 28. Juli 2009 um 02:13

    @Ute: Eingangs schreibst du über den Marktanteil. Das ist einer der springenden Punkte. Wenn Serendipity das Plugin und Theme Volumen von WP erreicht, sieht es dort genauso aus. Mit steigender Codegröße (Total) wird es immer schwerer wartbar und erweiterbar und knabbert dann an den gleichen Problemen wie WP.
    Sicher hat Serendipity den Vorteil, von Grund auf neu, OOP erschaffen und aus WP Fehlern gelernt zu haben, allerdings ist bei WP genau der OOP Ansatz das, was nun den Speicher kostet. Es ist derzeit schneller, kleiner und effizienter Arrays zu nehmen als Objekte, das wird sich frühestens mit PHP 6 ändern. Der Patch für die Sprachdateien entfernt OOP Code und macht alles wieder traditionell, was den Gewinn u.a. ausmacht.

  5. 5. Dieter

    Kommentar vom 28. Juli 2009 um 07:20

    @codestyling
    Danke für Deine Erläuterung, warum WP 2.8.x mehr Speicher benötigt und für Deinen mo.php-Patch. :god:

    Deine Ausführungen zum OOP Code lassen mir die kleine Hoffnung, dass irgendwann auch mal wieder der PHP-Speicherbedarf etwas sinken könnte.

    Zum immens großen Marktanteil von WordPress dürften neben seiner Bereitstellung als Open-Source und der berühmt-berüchtigten 5-Minuten-Installation auch die große Anzahl an vielfältigen Plugins und Themes beigetragen haben. Dadurch ist es möglich WordPress ganz den individuellen Bedürfnissen und Wünschen anzupassen. :hurra:

  6. 6. Ute

    Kommentar vom 28. Juli 2009 um 10:52

    @codestyling s9y gibt es seit 2002, WP seit 2004. S9y hat daher sicher nicht aus WP-Fehlern gelernt. ;)

    Der Ansatz ist einfach anders, statt unzählige Plugins für ein und dieselbe Funktion zuzulassen, gibt es nur je eins, welches dann jedoch so eingebunden wird, dass es sicher und stabil läuft.

    Damit eignet sich s9y nicht für Spielkinder, die unzählige Features ausprobieren wollen. Es ist auch eher eine reine Blogsoftware und hat nicht den Anspruch alles zu können.

    Insofern sind die Systeme für viele keine Konkurrenten.

  7. 7. codestyling

    Kommentar vom 28. Juli 2009 um 11:13

    @Ute: WP entstand als Branch aus b2, s9y ist neu gegossen worden.
    b2 wayback june 2001
    WP wayback may 2003
    s9y wayback june 2003

    Wenn man b2 als WP ansieht, dann wurde daraus schon gelernt.

    Ohne Zweifel hat s9y Vorteile, aber die Selbstbeschränkung steht der viralen Verbreitung eben auch im Weg, denn Otto Normalo kann nicht einfach etwas umsetzen, was er sich einbildet. Dazu muss er entweder programmieren können oder jemanden dafür bezahlen.
    Bei WP kann man das in den Communities größtenteils umsonst bekommen.

  8. 8. Dieter

    Kommentar vom 28. Juli 2009 um 11:15

    @Ute
    Ich habe mich mit Serendipity (s9y) noch nicht beschäftigt.

    Wenn ich Dich richtig verstanden habe, dann ist es für mich hier keine Alternative, denn
    – ich bin ein Spielkind (das die Vielzahl der Plugins und Themes ausprobiert) und
    – ich setze WordPress nicht nur als Blogsoftware, sondern eben auch als CMS ein.

    So gesehen wäre die Konkurrenz von WordPress für mich eher bei CMS, die auch Blogfunktionalitäten zur Verfügung stellen.
    Aber den Einarbeitungsaufwand dafür scheue ich derzeit.

  9. 9. Ute

    Kommentar vom 28. Juli 2009 um 11:27

    @Dieter ich weiß es nicht, du bist zwar Spielkind, legst aber Wert auf sauberen Code und Geschwindigkeit. Bezogen auf CMS und Blogfunktionalität könnte Drupal noch eine Alternative sein…

    Wer weiß, falls du mal wieder ein neues Projekt startest, könnte es einen Versuch wert sein auch anderes anzuschauen…

  10. 10. Dieter

    Kommentar vom 28. Juli 2009 um 12:08

    @Ute

    du bist zwar Spielkind, legst aber Wert auf sauberen Code und Geschwindigkeit

    Jepp! Valider Code und gute Performance sind bei mir zentrale Entscheidungskriterien für die Software, Plugins und Themes.

    Bezogen auf CMS und Blogfunktionalität könnte Drupal noch eine Alternative sein…

    Ich habe schon mal an Typolight oder XOOPS gedacht. Ganz wichtig ist mir zudem ein Theme auf YAML-Basis. Für Drupal und Typolight gibt es das.

    Wer weiß, falls du mal wieder ein neues Projekt startest, könnte es einen Versuch wert sein auch anderes anzuschauen…

    Man(n) soll ja nie nie sagen, aber ich bekomme ja schon aktuell meine Projekte nicht oder kaum gebacken. Sollte ich ein Projekt aktualisieren, dann würde ich Drupal und Typolight auf jeden Fall als Alternativen prüfen.

  11. 11. Ute

    Kommentar vom 29. Juli 2009 um 13:33

    @codestyling
    Mein Traum ist, dass es einfach Module gibt und nicht eine komplette Software.

    Ich hätte gern die Navi x, den Adminbereich y, das Theme z usw. Denn es gibt unzählige Systeme, die jedoch alle nicht genau so sind, wie ich es will.

    Unterm Strich habe ich immer nur die Wahl zwischen den Vor- und Nachteilen, die mir am wichtigsten sind.

    Jede Software „erfindet das Rad neu“ statt Gutes zu behalten und nur Nachteiliges neu zu entwickeln, werden so neue Fehler eingebaut.

    Bis sich mein Traum erfüllt, bleibt es dabei, dass jeder für sich entscheiden muss, welche Software den eigenen Bedürfnissen am nächsten kommt.

  12. 12. Peter

    Kommentar vom 3. August 2009 um 22:14

    > Ich habe schon mal an Typolight … gedacht

    TYPOlight ist ein tolles CMS, aber in erster Linie hierarchische, seitenbasierte Websites gedacht. Einen Blog kann man damit nicht wirklich betreiben .

    Drupal ist eine eierlegende Wollmilchsau. Der Einstieg ist „die Hölle„, aber danach kann man, wenn man den Drupalianern Glauben schenkt, damit alles machen.

    Beide Systeme sind m. E. kein Ersatz für WordPress als Blog. Das ist eine andere Liga. Ersatz für WP wären wohl eher Textpattern, Expression Engine oder S9Y.

  13. 13. Dieter

    Kommentar vom 4. August 2009 um 00:03

    @Peter
    Im Interview auf hyperkontext.at hast Du ja schon verraten, dass Du Typolight ausführlich getestet hast. Gibt es denn bei den wohl rd. 200 Plugins kein Plugin mit guter Blogfunktionalität?

    Für Drupal gibt es ja schon ein paar Bücher und eine YAML-Integration. Damit sind schon mal für mich wichtige Kriterien erfüllt. Allerdings schreckt mich da ab, dass es wohl relativ viel Ressourcen verbraucht und dann schnell langsam werden soll. Und wenn Du schon auf die Aussage „Der Einstieg ist die Hölle“ verlinkst, dann ist das schon eine Warnung für mich.

    Ersatz für WP sind aber die anderen Blogangebote nicht, denn für die gibt es nicht viel Literatur, keine YAML-Integration (die Seite für YAML mit der Expression Engine ist wohl seit über einem Jahr nicht erreichbar), nicht soviele Plugins und die Kombination aus CMS mit Blog ist dort wohl auch nicht so einfach wie mit WP zu realisieren.

    Wäre da noch Typo3, aber die Lernkurve dafür soll mir zuviel Ausdauer erfordern und ich habe keine Lust eine eigene Skriptsprache erlernen zu müssen.

    Da werde ich also wohl doch lieber bei WordPress bleiben. Kann dann ja dafür hin und wieder über die häufigen (Sicherheits-) Updates und nicht behobenen Problemchen (Speicherverbrauch im Backend, Pingback-Problem etc) mein Leid klagen.

  14. 14. WordPress und der Speicherverbrauch » Peruns Weblog

    Pingback vom 7. September 2009 um 22:53

    […] erste Link führt zum Beitrag von Dieter Welzel. Dort werden zwei Gründe aufgeführt warum eine WordPress-Installation verhältnismäßig viel […]

  15. 15. Sebo

    Kommentar vom 4. Oktober 2009 um 18:42

    Jo genau diese Probs kenne ich auch, hatte sogar mal nen richtig fetten Absturz, es lag an der Speicherreservierung. Zum Glück gibt es ja jede Menge Plugins für WP

  16. 16. Dieter

    Kommentar vom 4. Oktober 2009 um 19:52

    @Sebo
    Ich kenne kein Plugin, das das hier beschriebene Problem des hohen Speicherverbrauchs behebt.
    Kennst Du eins?

    Lediglich zur Ermittlung des Speicherbedarfs im Administrationsbereich (Backend) gibt es ein paar gute Plugins wie beispielsweise das im Blogbeitrag verlinkte WP System Health.

  17. 17. Daniel

    Kommentar vom 23. Februar 2010 um 11:07

    Also ich habe zwar ein Webhosting-Paket mit mehr Arbeitsspeicher, bzw. wo ich mehr davon freischalten lassen kann..allerdings habe auch ich gemerkt, dass da irgendwas nicht stimmt.
    Ich finde aber nach wie vor, dass WordPress das perfekte CMS für die „Sterblichen“ ist. Drupal, TYPO3 & Co. sind zwar größer und können letztendlich ein bisschen mehr, allerdings sind sie auch viel komplexer und bei weitem nicht so benutzerfreundlich wie WordPress.

    Oder seht ihr das anders?

  18. 18. Dieter

    Kommentar vom 23. Februar 2010 um 12:34

    @Daniel
    Habe mal Typolight angetestet und den Eindruck, dass der Einstieg in dieses CMS für mich zu aufwändig ist.
    WordPress ist einfach einfach. ;-)

  19. 19. WordPress: Wider dem Katastrophen-Gerede | Webseiten-Infos.de

    Pingback vom 21. Dezember 2011 um 05:01

    […] (Update) ein Wechsel des Hosters notwendig werden kann (siehe hierzu meine Blogbeiträge “Ursache des enormen Speicherbedarfs gefunden!“, “Umzug zu einem anderen Webhoster” und “In eigener Sache: Umzug zu […]

  20. […] nicht auf WordPress 2.8.x aktualisieren kann (siehe hierzu meinen Blogbeitrag “Ursache des enormen Speicherbedarfs gefunden!“), behält die kritische Sicherheitslücke. Für diese Fälle gelten meine oben gemachten […]

Kommentar schreiben (Datenschutzerklärung)

Kommentarformular





Erstkommentare und Kommentare mit Links werden moderiert.

Übersicht der Tastaturkürzel für Smilies

Abonnieren ohne einen Kommentar abzugeben

 

Durch die weitere Nutzung der Seite stimmst Du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen