Enormer PHP-Speicherverbrauch – Ursache gefunden?!
Dank der Erfahrung unseres Teammitglieds Heiko und Versuchen des engagierten Hosters suleitec scheint die Ursache für das Problem des enormen PHP-Speicherverbrauchs (und überschreiten des Limits) mancher Blogs gefunden zu sein: 64 Bit versus 32 Bit.
Da bei 64 Bit-Servern (mit entsprechendem Betriebssystem) die Speicheradressen doppelt so groß sind und die Speicherverwaltung teilweise größere Speicherblöcke einsetzt, kann dies ursächlich für den deutlichen Mehrverbrauch an PHP-Speicher sein. Eine genaue Erklärung findet sich im Forum.
Und nun brauchen wir deine Hilfe!
Ist dein Blog auch vom Problem des übermäßigen Speicherverbrauchs betroffen (sprich du erreichst selbst ohne viele Plugins und mit einem frischen WP mit oder ohne Sprachdatei locker die 32 MB-Grenze*)? Dann hake doch bitte bei deinem Hoster nach (falls du es nicht selber weißt oder prüfen kannst), ob du auf einem 64 Bit-Server mit 64 Bit-Betriebssystem gehostet bist und hinterlasse das Ergebnis als Kommentar.
Fest steht: Sollte wirklich ein 64 Bit-System an dem Mehrverbrauch schuld sein, so kann man das weder WordPress noch den Hostern wirklich anlasten. Wobei es wünschenswert wäre, wenn letztere mit Hinblick auf das Problem, das prinzipiell alle (PHP-)Anwendungen trifft, aus Kulanz das PHP memory_limit erhöhen.
*Es gibt auch Fälle, wo eine nicht im Binary-Modus hochgeladene Sprachdatei Probleme verursachte.
Dieser Beitrag wurde am 23. Juli 2009 um 16:44 von jottlieb in der Rubrik News abgelegt.
Dieser Beitrag wurde 23587 mal aufgerufen. Neue Kommentare via RSS 2.0 
-
Trackback URI
23. Juli 2009 um 17:15
Da muss ich leider enttäuschen. Unser Server ist ein 32bit-System. Es besteht allerdings ein erheblicher Unterschied zwischen der Original- und der DE-Edition. Bei 16 MB Speicherlimit kann ich das englische WordPress 2.8.2 locker mit 15 aktiven Plugins laufen lassen, während bei der DE-Edition schon bei 5 Plugins Schluss ist. Wobei ich immernoch der Meinung bin, dass 16 MB für ein einfaches Blog locker ausreichen sollten und da in keinem Fall irgendwelche Probleme mit dem RAM auftreten sollten.
23. Juli 2009 um 17:36
@LeSpocky:
Leider nennst du keine genauen Zahlen…Ansonsten gilt: Na klar verbraucht die DE-Edition mehr Speicher, die Sprachdatei genehmigt sich, je nach Version und Serverumgebung ein paar MB. Das ist der Tribut für die Deutsche Übersetzung per gettext.
Leider begründest du nicht, warum WordPress mit 16 MB Speicher auskommen sollte. WP ist mittlerweile kein einfaches “Blog” mehr sondern wächst immer mehr zum CMS. Klar, dass da der Speicherbedarf wächst. Und 16 MB sind nicht wirklich nicht viel. Eher im Gegenteil. Vergleiche das mal mit anderen Programmen. Ein nacktes Typo3 bekommst du bei 32 MB memory_limit eigentlich garnicht zum laufen. Mein Internet Explorer verbraucht für zwei Seiten schon 55 MB, iTunes 65 MB.
23. Juli 2009 um 17:44
@LeSpocky: Ohne dein Problem zu vernachlässigen, ist das Äpfel mit Birnen vergleichen. Die Fragestellung war WP mit Sprachdateien jeweils unter 32 und 64Bit.
Was du beschreibst, ist ein zusätzliches Problem, das die Entwickler von WP neu geschaffen haben, aber nicht auf jedem Server auftritt. Die Sprachdatei wird ab 2.8.0 von WP grundsätzlich anders geladen als in älteren WP Versionen (komplett neu geschriebener Code). Dies führt u.a. zu einem erhöhtem Verbrauch von Resourcen im PHP Modul, so wie es derzeit geschrieben ist. Allerdings hängt das auch von Provider, der installierten PHP Version (compilation, nicht Version) und dem OS und seiner Einstellung.
Wir wissen auch bereits, das eine 400kb *.mo Datei locker mal 4MB PHP Speicher kosten kann (Faktor 10) aber dies ist nicht auf allen Systemen so.
Deswegen unter anderem die Forschungsarbeit, diese 4MB erklären bei Weitem nicht den Zuwachs um 20 – 30 MB bei einigen Nutzern!
23. Juli 2009 um 17:52
Einmal für mein Blog (13 Plug-ins) – auf einem 32bit-System.
PHP Runtime Boot
(boot:wp-config) 0.33 %
135.81 kB |
System Health Boot
(boot:plugin) 18.85 %
7.54 MB
Plugins Active
(hook:plugins_loaded) 32.1 %
12.84 MB
Theme / Widgets
(hook:setup_theme) 32.13 %
12.85 MB
Localization File
(hook:gettext) 39.56 %
15.82 MB
Init WordPress
(hook:init) 42.92 %
17.17 MB
Init Admin Center
(hook:admin_init) 48.88 %
19.55 MB
Rendering Dashboard
(index.php) 50.07 %
20.03 MB
Wenn du schreibst, dass der große Speicherbrauch ja normal wäre, weil sich WP immer mehr in Richtung CMS entwickelt, dann ist das meiner Meinung nach genau das Problem. WP entwickelt sich in der Tat immer mehr in Richtung eierlegende Wollmilchsau, ohne dass es die Möglichkeit gäbe, eine Lite-Version zu bekommen, die auf einige nicht benötigte Features verzichtet. Nicht jeder WP-Benutzer möchte ein CMS. Mancher möchte vielleicht nur ein einfaches Blog hosten, aber mehr Freiheiten haben als bei blogger oder was weiß ich wo.
Hier sollte man wirklich überlegen, ob man sich von der Blogsoftware unbedingt in Richtung CMS entwickeln möchte. Die separate behandlung der Probleme Speicherbedarf und Weiterentwicklung von WP geht m.E. nicht.
23. Juli 2009 um 17:55
Unser root-Server hat 512 MB Arbeitsspeicher. Mehr Speicher kostet bei dem Hoster bares Geld. Da läuft nicht nur ein Blog drauf, sondern mehrere, dazu diverse Wikis, ein komplettes Mail-System inklusive Spam-Filter und Virenscanner, ein Jabber-Server sowie einige andere Anwendungen. Der Server ist mit den Dingen nicht überfordert. Weil da dutzende Anwendungen laufen und der RAM komplett genutzt wird, hat der Admin das Speicherlimit eben auf 16 MB gesetzt, unter anderem damit der nicht allzu viel swappen muss. Jede andere PHP-Anwendung kommt damit klar, darunter auch Schwergewichte wie MediaWiki, nur WordPress treibt die Kiste ins Memory Limit. Nur weil andere auch viel Speicher brauchen und Speicher erstmal billig ist, sollte man doch nicht auf speichereffiziente Programmierung verzichten. Mehr Speicher einbauen, statt seinen Quellcode zu optimieren ist wie das Pferd von hinten aufzuzäumen.
23. Juli 2009 um 17:56
@madcynic:
Danke für deine Daten, aber du gehörst anscheinend nicht zu denen, die vom Problem betroffen sind, weshalb wir diese nicht benötigen. Und 20 MB mit 13 Plugins sind doch nun wirklich nicht viel.
@LeSpocky:
512 MB Arbeitsspeicher sind genauso wie 16 MB memory_limit Werte die vielleicht vor fünf bis zehn Jahren Stand der Technik und Standardwerte waren. Im Serverbereich ist es genauso wie im Homebereich dass immer mehr Speicher immer weniger Geld kostet und der durchschnittliche Computer im Vergleich zu vor zehn Jahren mindestens vier bis 20 mal mehr Arbeitsspeicher haben dürfte. Du beschwerst dich doch auch nicht, wenn auf einem entsprechen alten Computer keine aktuellen Programme laufen, weil Standardsoftware sich heutzutage auch nur noch selten mit solch geringen Mengen an Speichern begnügt.
Ich breche die Diskussion zu diesem Thema meinerseits hier ab und bitte auch andere, in diesen Kommentaren nicht darüber zu diskutieren.
@Alle:
Es geht hier allein um das Problem des exzessivem, nicht nachvollziehbaren Verbrauchs von Speicher welches anscheinend auf 64 Bit-Systemen auftritt.
Habt bitte also Verständnis dafür, dass themenfremde Kommentare evtl. nicht freigeschaltet oder abgewiesen werden.
23. Juli 2009 um 18:08
Um nur mal ein paar Beispiele zu nennen, was in der PHP Entwicklung so los ist, hier ein paar Sachen aus der PHP 5.2.10 Version, die gefixt wurden:
* Force a cache limit in ereg() to stop excessive memory usage #48416
* Improve memory_get_usage() accuracy #48434
Und hier das komplette Changelog von PHP 5 (alle Versione Top/Down): PHP 5 Changelog
Bitte nicht den Boten köpfen, wir programmieren weder WP noch PHP.
Einige dieser Probleme werden von unsachgemäß programmierten Plugins selbst erzeugt, siehe ereg() oder ähnlichem aus dem Changelog, das MemoryLeaks erzeugt.
Klar kann und sollte man auf Speicherverbrauch achten. Aber ein Blick in die Wirtschaft zeigt, das dies in Zeiten von .NET und Garbage Collector niemanden wirklich interessiert. Man nehme Speicher oder Cloud Computing aber Hauptsache die Software wird schnell fertig und kann verkauft werden. So ist das im wahren Leben eben, Idealismus, wie ich den noch aus handoptimierten ASM Zeiten kenne, rentiert sich leider nicht (mehr).
23. Juli 2009 um 20:00
Das ist aber eine fadenscheinige Ausrede (so wie der ganze Artikel), die man in keinster Weise so stehen lassen darf! Mir ist noch KEIN PHP-Programm untergekommen, welches soviel Speicher verbraucht. Also haltet mal den Ball flach, macht Eure Hausaufgaben und mistet WP aus! Dieser Erklärungsversuch ist eine Beleidigung für jeden guten PHP-Programmierer!
23. Juli 2009 um 20:03
@Hans: Bitte mal selber den Ball flach halten. WPD entwickelt WordPress nicht, das geschieht auf wordpress.org in der Regie von Automattic! WPD ist eine deutschsprachige Benutzercommunity!
23. Juli 2009 um 20:07
Auf meinem Testsystem läuft Ubuntu 9.04 64bit. Dazu WP 2.9 und die aktuelle Sprachdatei. Dazu Kubrick (das originale, nicht die DE-Version), keine Widgets, keine Plugins. Mit Sprachdatei: 28.5 MB (Peak: 31). Ohne Sprachdatei: knappe 20 MB.
HTH
marX
23. Juli 2009 um 20:10
Bei uns gab es in den letzten Wochen erhebliche Probleme mit der CPU-Last und mit dem Speicherverbrauch. So richtig erklären können wir es bis heute nicht. Der oben beschriebene Memory-Fehler trat ebenso auf – die CPU-Last war aber das größere Problem. htop zeigt regelmäßig 10.2 an. Um den Problemen auf den Grund zu gehen, hat uns unserer Hoster temporär auf einen stärkere Server gelegt. Letzten Endes waren es eine Anzahl von Maßnahmen, die dazu führten, dass unser Blog wieder schnuckelig läuft.
- Optimierung des Themes. Die Funktion wp_head hat eine Dauerschleife produziert. Ich mag das Theme, es scheint aber eher suboptimal programmiert. Die Erfahrung zeigt, dass diverse Plugins ebenso immer wieder Probleme machen. Ein Blick auf die Themes und die Plugins sollte man also immer haben.
- Auslagerung des Feeds auf Feedburner. Ich mag Google nicht – aber auch diese Maßnahme wurde ergriffen. Die meisten Zugriffe hat ab einer gewissen Größe der Feed zu verzeichnen.
- Optimierung der .htaccess. So klein, wie irgendwie möglich halten. Sie wird selbstverständlich bei jedem Besuch gelesen und die Aktionen dementsprechend ausgeführt. Oder, wenn die Möglichkeit besteht, die .htaccess global auf die Apachekonfiguration auslagern, wenn zum Beispiel ein eigener Server genutzt wird.
- Plugin WP-Cache installiert. Das Plugin ist Gold wert. Es kann zwar vorkommen, dass ein Besucher den noch nicht freigeschalteten Kommentar eines anderen sieht, so wurde zumindest berichtet, aber mit WP-Cache ist die Serverlast sofort wieder in den “normalen” Bereich gesunken. Alternative, wenn möglich: Apachemodul XCache installieren
Nicht geholfen hat, WordPress “nackt” neu zu installieren und nach und nach die Plugins und Themes einzupflegen.
htop zeigt mittlerweile 0.02 an, im Peak 0.6, wenn wir mal wieder “überlaufen” werden. Der Memory-Fehler tritt gar nicht mehr auf.
Aktuell bei uns:
htop 0.25 im Schnitt
16 MB PHP-Speicher
29 Plugins aktiviert.
Summary Statistics
Duration (hh:mm:ss) 90:01:57 (4 Days)
Total Hits 297,879
Total Cached Hits 18,487
Unique Visitors 23,327
23. Juli 2009 um 20:23
Ist gut, ich hab’s mal versucht, an ner besser geeigneten Stelle abzuladen: Idea: reduce memory usage.
23. Juli 2009 um 22:35
Als derjenige der den Stein ins Rollen gebracht hat, melde ich mich auch noch einmal zu Wort. :)
Ich habe WordPress in der Version 2.8.2 installiert mit 14 aktiven Plugins. Ohne die deutsche Sprachdatei habe ich keine Probleme. Sobald ich sie aktiviere, bekomme ich folgende Fehlermeldung im Dashboard:
Laut Provider (und phpinfo) stehen mir 36 MB Speicher zur Verfügung auf einem 64-Bit AMD-Server mit Linux.
Was mich allerdings nach wie vor verwundert, sind die ausgewiesenen Werte. Wenn ich wirklich 36 MB zur Verfügung habe, sollte der oben geforderte Wert von 311296 bytes eigentlich allokiert werden können. Außerdem weist das Memory-Usage-Plugin mit Sprachdatei lediglich einen Bedarf von 19.47 MB aus (ohne sind es 14.95 MB). Dürfte also auch nicht Rahmen sprengen.
23. Juli 2009 um 22:39
Ich denke das Hauptproblem liegt bei PHP und nicht beim WordPress Source Code.
So sorgt die Posix Regex Engine die für die Auswertung der Sprachdateien zuständig ist für den CPU Zeit und Speicherplatz Verbrauch. Das WordPress Sprachdateien System ist wie eine Datenbank aufgebaut. Es wird in der ganzen Datei nach dem Eintrag gesucht und das immer immer wieder.
Dafür sollte man eigentlich besser Datenbanken verwenden,wo man in einer extra Tabelle das ganze macht und dann über eine ID oder so sucht anstatt mit einer Datei
23. Juli 2009 um 23:16
Ich habe vor einiger Zeit Thomas Urban von http://www.toxa.de kontaktiert, weil er einen Performance Patch für das Lesen der Sprachdatei in der WP Trac eingebracht hat.
WP Core Member haben dafür kein Interesse gehabt, aber ich hab mir das angesehen. Nach mehreren Tests und mit meinen Hinweisen haben wir eine neue Version der Datei geschrieben, die Sprachdateien einliest. Diese bringt mein Windows System von 4 MB Verbrauch für die de_DE.mo auf 2 MB runter und ist deutlich flotter.
Diese ist allerdings Modifikation ist allerdings Beta jedoch schon genügend oft getestet. Wer diese ebenfalls (ohne Gewähr) testen möchte, kann sich bei mir melden. Ich betone nochmal den Betastand, damit keine Mißverständnisse auftauchen.
24. Juli 2009 um 00:25
@ codestyling:
würde mich dafür interessieren.
jwqlb
24. Juli 2009 um 07:27
Ganz großen Dank an Euch und insbesondere Heiko für die Ermittlung und Erklärung des Hauptproblems. Ich kann den annähernden doppelten PHP-Speicherbedarf für Webspace mit einer 64Bit-Plattform bei WP 2.8.x bestätigen. Bei meinem Webspace bei alfahosting.de hatte ich vor dem Update von WP 2.7.2 auf 2.8.1 mit rd. 45 Plugins einen PHP-Speicherverbrauch von rd. 28 bis 30 MB. Danach nun rd. 52 MB. Hier die aktuellen Werte mit dem genialen WP-Plugin WP System Health:
Platform 64Bit
Loaded Extensions zip, xmlwriter, libxml, dom, xmlreader, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, session, pcre, SimpleXML, sockets, soap, SPL, shmop, standard, Reflection, posix, mime_magic, mbstring, json, iconv, hash, gettext, ftp, filter, exif, dbase, dba, date, ctype, calendar, bz2, bcmath, zlib, openssl, cgi-fcgi, curl, gd, imap, mcrypt, mysql, mysqli, PDO, pdo_mysql, xmlrpc, xsl, ionCube Loader, Zend Optimizer
WordPress 2.8.2
Language de_DE
Memory Limit 64 MB
Checkpoints: Details »« Simple
PHP Runtime Boot
(boot:wp-config)
0 %
-n.a.- | If you want to know the pure amount of memory the PHP runtime has allocated, read the documentation about modification of wp-config.php to get a boot strip.
System Health Boot
(boot:plugin)
21.87 %
14.00 MB | Will be passed if this monitoring plugin has been loaded successful.
Plugins Active
(hook:plugins_loaded)
52.27 %
33.45 MB | Will be passed if all active plugins have been loaded successful.
Theme / Widgets
(hook:setup_theme)
52.34 %
33.50 MB | Will be passed if the Theme and Widget Factory has been initialized.
Localization File
(hook:gettext)
63.72 %
40.78 MB | Will be passed if the WordPress language file has been loaded successful.
Init WordPress
(hook:init)
71.22 %
45.58 MB | Will be passed if WordPress initialization has been finished.
Init Admin Center
(hook:admin_init)
79.01 %
50.57 MB | Will be passed if Admin Center initialization has been finished.
Rendering Dashboard
(index.php)
82.59 %
52.85 MB | Will be passed during generation of this Dashboard Overview.
Ich habe auch noch Webspace bei one.com. Dort allerdings sind bei einem Blog weniger Plugins im Einsatz und eine 32Bit-Plattform. Dort nahm der PHP-Speicherbedarf beim manuellen Update von WP 2.7.2 auf WP 2.8.2 um 4 MB zu. Wahrscheinlich ist dieser erhöhte Speicherbedarf den WP-Veränderungen bzgl. der Sprachdateien geschuldet. Die Angaben von WP System Health sehen dort wie folgt aus:
Platform 32Bit
Loaded Extensions date, libxml, openssl, pcre, zlib, bcmath, calendar, ctype, curl, dba, dom, session, filter, gd, gettext, hash, iconv, standard, json, mbstring, mcrypt, mysql, SimpleXML, SPL, PDO, pdo_mysql, pdo_sqlite, Reflection, imap, mysqli, soap, exif, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, cgi-fcgi
WordPress 2.8.2
Language de_DE
Memory Limit 24 MB
Checkpoints: Details »« Simple
PHP Runtime Boot
(boot:wp-config)
0 %
-n.a.- | If you want to know the pure amount of memory the PHP runtime has allocated, read the documentation about modification of wp-config.php to get a boot strip.
System Health Boot
(boot:plugin)
31.85 %
7.64 MB | Will be passed if this monitoring plugin has been loaded successful.
Plugins Active
(hook:plugins_loaded)
60.99 %
14.64 MB | Will be passed if all active plugins have been loaded successful.
Theme / Widgets
(hook:setup_theme)
61.06 %
14.65 MB | Will be passed if the Theme and Widget Factory has been initialized.
Localization File
(hook:gettext)
73.77 %
17.70 MB | Will be passed if the WordPress language file has been loaded successful.
Init WordPress
(hook:init)
79.95 %
19.19 MB | Will be passed if WordPress initialization has been finished.
Init Admin Center
(hook:admin_init)
89.01 %
21.36 MB | Will be passed if Admin Center initialization has been finished.
Rendering Dashboard
(index.php)
90.73 %
21.77 MB | Will be passed during generation of this Dashboard Overview.
Da es bei one.com aber derzeit lediglich 24 MB PHP-Speicher gibt, kann ich ein dort gehostetes Blog mit vielen Plugins nicht mehr auf WP 2.8.x updaten (siehe auch meinen Blogbeitrag). Derzeitiger PHP-Speicherbedarf mit WP 2.7.2 bereits 21.60 MB und damit keine 4 MB mehr für ein deutsches WP 2.8.2 frei. :-(
24. Juli 2009 um 08:18
Ich hatte 32MB Speicher auf einem Linux 64Bit System und es reichte nicht für ein WordPress ohne Plugins. Nach dem Upgrade auf 40MB Speicher geht alles wieder.
24. Juli 2009 um 08:43
Hi!
Ist zwar schon Ewigkeiten her, dass ich Probleme mit PHP Memory Limit hatte, aber vielleicht hilft euch die Info trotzdem. Hatte das damals schon mit Heiko versucht zu lösen (über Skype, falls Du Dich erinnerst). Aktuell habe ich seit einigen Monaten Ruhe. Damals wie heute kam ein 64Bit AMD-CPU und ein 32Bit-Suse auf dem Server zum Einsatz. Hoster ist all-inkl.com. Die Auslastung des Memory Limits (ich habe mehrere Websiten auf dem Server gehostet) liegt je nach Seite zwischen 30 und 50%.
Gruß
infected
24. Juli 2009 um 08:48
Hier Angaben zu 2 Installationen bei 2 Hostern.
Ist schon sehr merkwürdig das bei dem ersten Hoster (System1) trotz weniger Plugins weit aus mehr Speicher gefordert wird.
System 1 mit PHP 5.2.9, Zend 2.2.0, 64bit AMD
128 MB Memory Limit, 14 aktive Plugins, WP 2.8.2 DE-Version
PHP Runtime Boot
(boot:wp-config)
0 %
-n.a.-
System Health Boot
(boot:plugin)
9.41 %
12.04 MB
Plugins Active
(hook:plugins_loaded)
16.19 %
20.72 MB
Theme / Widgets
(hook:setup_theme)
16.2 %
20.74 MB
Localization File
(hook:gettext)
20.36 %
26.06 MB
Init WordPress
(hook:init)
21 %
26.88 MB
Init Admin Center
(hook:admin_init)
24.14 %
30.89 MB
Rendering Dashboard
(index.php)
24.5 %
31.36 MB
System 2 mit PHP 5.2.8-0.dotdeb.1, Zend 2.2.0, 64bit AMD
128 MB Memory Limit, 25 aktive Plugins, WP 2.8.2 DE-Version
PHP Runtime Boot
(boot:wp-config)
0 %
-n.a.-
System Health Boot
(boot:plugin)
1.23 %
1.57 MB
Plugins Active
(hook:plugins_loaded)
3.51 %
4.49 MB
Theme / Widgets
(hook:setup_theme)
3.54 %
4.53 MB
Localization File
(hook:gettext)
9.17 %
11.74 MB
Init WordPress
(hook:init)
10.69 %
13.68 MB
Init Admin Center
(hook:admin_init)
11.28 %
14.44 MB
Rendering Dashboard
(index.php)
11.69 %
14.96 MB
24. Juli 2009 um 09:12
Habe zwar keine Ahnung von diesen Dingen, ich versuche trotzdem mal was hoffendlich infomäßig passenden zu posten:
wp 2.8.2 (Sprachdatei von wordpresss-deutschland.org)
37 aktivierte Plugins (darunter vielleicht welche die viel Speicher verbrauchen?)
• PHP Version : 5.2.9
• Memory limit : 90 MByte
• Memory usage : 46.7 MByte
hoster: Dreamhost (nehme an, die _64 am Ende treffen das hier gewünschte?!)
Linux cyclops 2.6.29-xeon-aufs2.29-ipv6-qos-grsec #1 SMP Thu Jul 9 16:42:58 PDT 2009 x86_64
LG
24. Juli 2009 um 09:37
Also bei goneo.de wird FreeBSD 7.2 in der 64Bit-Version genutzt. Mein deutsches WP verbraucht bei 28 Plugins knapp 38MB Speicher. Das ist aber insofern unproblematisch, als dass der Hoster einem 128MB einräumt.
24. Juli 2009 um 11:25
@codestyling hätte auch interesse daran^^
24. Juli 2009 um 14:18
@jwqlb, @Markus: Mein Beitrag samt Betatest-Download ist jetzt freigeschalten und hier zu finden WordPress 2.8 – Sprachdatei Speicherverbrauch minimieren.
24. Juli 2009 um 16:36
Nach Downgrade auf 2.7.1 kann ich WordPress wieder halbwegs brauchbar in Deutsch einsetzen. Es läuft auf einem 64-Bit-Linuxserver mit PHP 5.2.4-2ubuntu5.6.
32 MB Speicher sind voreingestellt verfügbar (und nicht userseitig veränderbar), “System Health” zeigt mir nach Start des Adminbereichs (Dashboard) 27,61 MB Nutzung (86,27%) an. Das geht auch nur auf rund 76% runter, wenn ich fast alle Plugins abschalte (womit mein Blog aber nicht mehr benutzbar wäre).
Egal wie, nach dem Upgrade auf 2.8 lief praktisch gar nichts mehr, schon gar keine deutsche Sprachversion. Deswegen bin ich jetzt wieder auf 2.7.1.
Mein Zweitblog (auf demselben Server), ein Fotoblog mit ganz wenigen Beiträgen und ganz winziger Datenbank sowie wenigen Plugins, läuft noch auf 2.8.0, aber auch nur gerade so eben in deutscher Sprachversion mit einem halben Dashboard und Fehlermeldungen. “System Health” wird schon gar nicht mehr geladen, auch wenn ich alle anderen Plugins abschalte.
24. Juli 2009 um 19:10
Nach etwas googlen hat sich bei mir (Hosting bei 1&1) das Problem einfach lösen lassen:
In der .htacces Datei folgende Zeilen einfügen:
(bei Bedarf die Textdatei im WordPress-Verzeichnis am Webserver anlegen)
Zum Prüfen des Speicherverbrauchs benutze ich WP Memory Usage
MfG Otmanix
25. Juli 2009 um 00:33
Nach [1] ist das aber eine 1&1-spezifische Loesung, weil dort offenbar der php-Handler anders heisst.
[1] http://www.tcp-blog.de/x-mapp-php5-oder-applicationx-httpd-php/
25. Juli 2009 um 10:09
Wozu braucht man eigentlich diesen ständigen Updates?
Warum nicht mal ein schlankes, schnelles WordPress, mit wenig Speicherbedarf, zur Verfügung stellen?
Mit Hilfe diverser Plugins konfiguriert sich dann jeder, WordPress nach seinem Geschmack.
25. Juli 2009 um 12:06
Meine WP Blogs sind auf den angesprochenen Suleitec Server umgezogen worden und haben die Überraschung mit 64 Bit aufdeckt.
Erstaunlich fand ich folgende Reaktion von z.B. XML Sitemap Generator für WordPress 3.1.4
“Die Sitemap-Generierung dauerte 1.07 sekunden und verwendete 38.5 MB Speicher.”
Hier der Vergleichswert eines anderen Blogs mit gleicher Einstellung des Plugins auf 32 Bit:
“The building process took about 1.05 seconds to complete and used 21 MB of memory.”
25. Juli 2009 um 13:09
@Stefan:
- Weniger Bugs
- Schließen von Sicherheitslücken
- Verbesserungen
- Mehr oder weniger erwünschte Features einbauen
Ansonsten müsstest du die die Frage den Entwicklern stellen.
2. August 2009 um 19:17
Ich musste leider für die Galerie auf über 40 MB erhöhen, damit er mittelgroße Bilder per GD resized. 32 Bit, deutsche Version ..
Kommt mir etwas viel vor …
12. August 2009 um 12:44
@Martin was ist mittelgroß ?
Der Speicherverbrauch bei gd ist rein abhängig von der Auflösung des Bildes:
http://www.developers-guide.net/forums/2717,grundlagen-gdlib-und-grosse-bilder
Also 8 * Breite * Höhe Bytes
Das ist der Speicherverbrauch den 1 Bild braucht, sobald jetzt ein Thumbnail erstellen will, kommt nochmal der Speicherverbrauch für das Thumbnail dazu.
Das alles ist zusätzlicher Speicherverbrauch zu dem was WordPress selbst schon braucht.
Für ein einfaches 1024 * 768 Bild sind das dann schon 6 MB ohne was damit zu machen, für 2048 * 1536 sind es dann schon ~ 24 MB ( 25 165 824 bytes)
12. August 2009 um 16:49
Hallo,
nach dem ich meine komplette Homepage / Webseite überarbeitet habe und mich für das WordPress als Blogsystem entschieden habe, verwendete ich auf dem lokalen Testserver (32 Bit System) anfangs die Version 2.8.3 – nach dem Upload auf den 64 Bit Server mit 32 MB Memory Limit ging es gnadenlos in die Knie.
- deutsche Sprachdatei
- 15 aktive Plugins
Selbst ohne Sprachdatei und den 15 Plugins liegt der Speicherverbrauch bei aktuell 30.7 MB
Testweite machte ich mir die Freude und versuchte es mit der 2.7.1 Version.
Auf dem lokalen Testsystem mit deutscher Sprachdatei ergab einen Speicherverbauch von 22 MB, auf dem widerum wurden gleich wieder 31 MB verbraucht.
12. August 2009 um 20:07
Habe jetzt nochmal den Vergleich der aktuellen 2.8.4 (ohne Sprachdatei) angestellt:
Lokal:
PHP Version : 5.2.6 / 32Bit OS
Memory limit : 32 MByte
Memory usage : 22.16 MByte
Extern:
PHP Version : 5.2.9 / 64Bit OS
Memory limit : 32 MByte
Memory usage : 30.24 MByte
Schöne Sch…
16. September 2009 um 21:58
Hi,
ich arbeite seid einer Woche mit WordPress 2.8.4 DE, also noch alles frisch. Ich habe nur die Plugins Akismet und TPC! Memory Usage aktiviert.
Server: Linux sh8-36 2.6.24-24-server #1 SMP Tue Aug 18 16:51:43 UTC 2009 x86_64
Memory Usage: 30.16MB (94%)
Peak Memory Usage: 30.45MB (95%)
WP Memory Limit: 32M
PHP Memory Limit: 40M
Gruß
6. Oktober 2009 um 14:53
Also das gleiche Blog:
1und1 php4, deutsche Sprachdatei 32bit:
14MB
1blu, php5, ohne Deutsche Sprache, 64Bit:
20MB
mit deutscher Spracher: 28MB
das ist doch wirklich eine Sauerei, zum Glück habe ich 64MB zur Verfügung.
11. Oktober 2009 um 13:10
Nicht mal eine ganz normal frische Setup der v2.8, ohne Plugins, ohne alles lässt sich auf jedem Webspace installieren, denn es passiert schon mal, daß die Meldung “fatal Error: tried to allocate Memory…” auftaucht.
Habe schon vieles an gut gemeinten Tipps versucht; trotzdem ohne Erfolg. Was also soll ich denn tun, damit ich einfach “nur” das bisher beste System immer in seiner aktuellen Version verwenden kann? Bisher bleibe ich auf einem veraltetem WP sitzen, wo ich jede Menge Plugins verwenden kann, ohne daß mir diese kuriose Meldung auf den Bildschirm springt. Schon sehr fragwürdig, was an den neuen Versionen so viel mehr sein soll, daß die nicht mal auf normalen Servern laufen wollen…
Gruß
12. Oktober 2009 um 13:56
@Recht-Frech.de:
Was du tun kannst: Einen Webspaceanbieter wählen der genug PHP-Memory gewährt.
23. Januar 2010 um 14:51
Kann das Problem ebenfalls bestätigen.
Habe für eine Kundin ein WordPress eingerichtet und kann NextGEN Gallery aktivieren, solange die deutsche Sprachdatei aktiviert ist.
Auf meinem webspace (beim gleichen Anbieter!) funktioniert es aber.
Problem bei der ganzen Sache:
-Betriebssystem ist ein 32-bit(!!!)
-memory_limit steht auf 32mb
-Problem tritt mit WordPress 2.9.1 auf, mit 2.8.6 funktioniert alles einwanfrei.
-Es sind KEINE(!) Plugins aktiviert.
Wenn ich die deutsche Sprachdatei auslasse funktioniert es einwandfrei.
Nedo
5. März 2010 um 14:49
Hallo,
bei mir auch das gleiche Problem mit 64-bit
PHP Version: 5.2.12 / 64Bit OS
Memory limit: 32 MByte
Memory usage: 26.54 MByte
Hab schon alle Bilder in der NextGen runtergeschraubt aber eine Veränderung gab es nicht. Ein paar Plugins rausgeschmissen und es brachte höchstens 1Mb ein.
Ich bräuchte ein WYSIWYG Editor und kann keinen installieren weil dann der Error erscheint, echt beknackt.
3. April 2010 um 20:08
Habe mir gerade einen zweiten Webspace besorgt und gleich auf beiden mal eine saubere Testinstallation von WordPress 2.9.2 angelegt.
Server 1:
* PHP Version : 5.2.9 / 64Bit OS
* Memory limit : 32 MByte
* Memory usage : 20.5 MByte
Server2:
* PHP Version : 5.2.13 / 32Bit OS
* Memory limit : 35 MByte
* Memory usage : 11.4 MByte
Doppelt so viel Verbrauch ist schon heftig, oder?? Ich hoffe, da kann langfristig was dran gemacht werden.
27. April 2010 um 10:50
Kann das hier ebenfalls bestätigen.
Allerdings mit einem kleinen – aber wie ich finde wichtigen – Unterschied:
Ich habe zwei Blogs laufen, mein normales, welches ich seit Version 2.3 (oder so) betreibe. Selbstverständlich auf aktuellstem Stand. In diesem Blog laufen etwa 60 Plugins. Vom handling her alles prima. Das sage ich aus einem bestimmten Grund, zu dem ich später noch komme. Mit diesem Blog bin ich von einem Provider zum nächsten umgezogen (ich weiß nicht, was für ein System der alte Provider hatte; ob 32 oder 64bit).
Beim neuen Provider angekommen, setze ich ein frisches Blog auf und stoße bei 10 Plugins an meine Grenzen (oder die des Servers, kann man nehmen wie man will). Freundlicherweise ist man bereit das Limit von zunächst 8 auf 32 MB zu erhöhen. Als sich raus stellt, dass dies nicht reicht erhöht man auf 64 MB.
Altes, transferiertes Blog:
* PHP Version : 5.2.11 / 64Bit OS
* Memory limit : 64 MByte
* Memory usage : 51.04 MByte – 80%
Neues, aufgesetztes Blog:
* PHP Version : 5.2.11 / 64Bit OS
* Memory limit : 64 MByte
* Memory usage : 31.79 MByte – 50%
Was ich vorhin mit dem handling meinte ist folgendes: weder bei 8, 32 noch bei 64 MB Memory Limit merkte ich einen Unterschied. Umso erschreckender das er mir eine 80Prozentige Auslastung anzeigt bei 64 MB. Demnach hätte es vorher gar nicht laufen dürfen…
Ich werde das hier auch noch im Forum posten, ich persönlich habe da noch Klärungsbedarf.
30. April 2010 um 13:04
Ich schließe mich an:
* PHP Version : 5.2.12-nmm1 / 64Bit OS
* Memory limit : 32 MByte
* Memory usage : 31.65 MByte
Es war zwar kein “nacktes” WordPress, das ich installiert habe (spr. es sind bereits Artikel vorhanden und auch mehrere Plugins installiert), aber dennoch ärgerlich.
Ich hoffe, es gibt bald Hilfe für das Problem.
30. April 2010 um 13:07
PS: Zum Vergleich mein alter Server:
* PHP Version : 5.2.9 / 32Bit OS
* Memory limit : 24 MByte
* Memory usage : 16.54 MByte
10. Mai 2010 um 21:20
Das Problem scheint (wie schon erwähnt) an der Sprachdatei (de_DE) zu liegen. Zum Vergleich;
Mit englischer Sprachdatei:
* PHP Version : 5.3.1-nmm2 / 64Bit OS
* Memory limit : 64 MByte
* Memory usage : 41.82 MByte
Und die Seite mit deutscher Sprachdatei:
* PHP Version : 5.3.1-nmm2 / 64Bit OS
* Memory limit : 64 MByte
* Memory usage : 50.79 MByte
Ich nutze qTranslate um das “Backend” in Englisch zu halten, und das Theme auf Deutsch anzuzeigen. Wird sich denn an der .po und .mo was ändern?
Thomas
10. Mai 2010 um 22:19
@Thomas:
Wie im Artikel beschrieben, liegt es nicht an der Sprachdatei an sich, wir haben also keine Schuld!
11. Mai 2010 um 13:14
Sorry jottlieb, das sollte kein Vorwurf an Euch sein. Ich bin begeistert von dem, was Ihr für die WP-Gemeinde in Deutschland macht. Respekt!
Das mit dem Speicherbedarf ist aber tatsächlich ein Problem, das irgendwie gelöst werden sollte. Und die Sprachdatei zu “umgehen” ist schon mal ein Anfang – bringt bei 64MB Memory-Limit knapp 10% mehr an Ressourcen – oder anders gerechnet, ich kann 2-3 Plugins mehr installieren. :)
24. Mai 2010 um 23:04
Hallo,
bin leider auch betroffen :-( WordPress vorhin frisch aufgesetzt und da waren es dann schon 88%.
Memory Overview sagt folgendes dazu:
* PHP Version : 5.2.13 / 64Bit OS
* Memory limit : 32 MByte
* Memory usage : 31.2 MByte
Änderungen an der wp-config haben leider nichts gebracht. Hm … Was mache ich nun ? Bin grad am Aufbau aber macht das denn Sinn ?
24. Mai 2010 um 23:45
@Caro:
Spreche mal mit deinem Hoster, ob er das memory limit erhöhen kann.
25. Mai 2010 um 00:06
Hallo Jottlieb,
vielen Dank für die super schnelle Antwort. Bin gerade dabei eine Mail zu verfassen und denen mein Problem zu schildern. Hoffentlich kappt´s … Wäre schade, wenn ich WordPress jetzt gleich wieder runternehmen muß :-(
Lieben Gruß,
Caro
25. Mai 2010 um 12:34
Nur zur Info:
Mein Provider meint, ich müsse mir – um das Memory Limit zu erhöhen – dann ein größeres Paket kaufen. Was natürlich noch teurer für mich wäre.
Insofern war es das dann für mich mit WordPress. Schade, aber nicht änderbar.
25. Mai 2010 um 14:13
@Caro:
Das liegt aber, wie im Beitrag angedeutet, eigentlich nicht an WordPress.
25. Mai 2010 um 15:30
@ jottlieb
Ich habe schon verstanden, dass das nicht an WordPress liegt. Mich ärgert nur, dass ich jetzt alles soweit fertig hatte (mein Theme) und nun scheitert´s an zu wenig Memory Limit. Da könnt ich in die Tischkante beißen – oder den weitaus effektiveren Weg wählen und mein Webpaket erhöhen … *g*
Da ich auf WordPress nicht verzichten möchte, werde ich halt etwas tiefer in die Tasche greifen und mein Paket erhöhen. Gibt zwar zig andere Blogsysteme, aber irgendwie ist das eben nicht das selbe …
25. Mai 2010 um 16:50
Hallo jottlieb,
kannst Du mir mal einen Tipp geben, bitte. Ich weiß nicht genau welches Paket ich nun kaufen soll. Das mit 48MB Memory-Limit (reicht das denn aus ?) oder doch gleich das größere mit 64MB Memory-Limit ? Kenne mich leider mit der Materie so überhaupt nicht aus.
Mein Blog wird eigentlich nicht sehr umfangreich – wird eher privat gehalten. Plugins ca. 11-15 Stück … Ältere Einträge lösche ich auch jährlich regelmäßig, da ich mir das alles selbst gerne schlanker halten möchte.
Habe gestern ein Plugin nach dem anderen ein- bzw. ausgeschaltet, aber ein “Fresser” war da auch nicht bei.
Wäre super, wenn Du mir da helfen könntest denn ich möchte doch nur mein WordPress behalten können *seufz*
Danke & Gruß,
Caro
25. Mai 2010 um 17:00
Ich würde gleich das mit 64 MB nehmen, da dein WordPress ja aufgrund der Umgebungsbedingungen gleich mal locker so viel Speicher als “normal” verbraucht.
25. Mai 2010 um 17:05
Aha … Sagt mir jetzt zwar auch nichts aber wenn Du meinst, dass ich damit auf der sicheren Seite bin, dann mach ich das doch :-)
DANKE SCHÖN !
29. Mai 2010 um 00:46
Also … Ich habe jetzt auf 64MB Memory-Limit erhöhen lassen und bin dann jetzt doch schon auf 49% …
* PHP Version : 5.2.13 / 64Bit OS
* Memory limit : 64 MByte
* Memory usage : 31.08 MByte
Also ich denke das die Anderen, die dann das selbe Problem haben wie ich, wohl auch nicht drum herum kommen werden, das Memory-Limit erhöhen lassen zu müssen.
Danke nochmals jottlieb für den Tipp. Ich hoffe nur, dass ich die restlichen 51% nicht allzu schnell ausreizen werde und das noch etwas übrig bleiben wird … :-)
Liebe Grüße !
3. Juni 2010 um 02:28
wegen WPML Plug bin ich grad auch mit den memory-limits in Bezug auf Bilderuploads beschäftigt (sic!)
Gleiche Installation, gleiche Plugs incl.WPML bei
GONEO:
(FreeBSD w67.goneo.de 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #5: Wed Dec 2 13:41:13 CET 2009 root@wm1.goneo.de:/usr/obj/usr/src/sys/GONEO amd64)
40.97 MB (dashboard rendering)
1&1:
(Linux infong 2.4 #1 SMP Wed Nov 4 21:12:12 UTC 2009 i686 GNU/Linux)
25.06 MB (dashboard rendering)
Trotzdem bin ich bei 1&1 jetzt fast am Ende der Fahnenstange was die Größe der Bilderuploads angeht.
GONEO hat ja ‘n entsprechend besseres memory-limit
grüsse
3. Juni 2010 um 02:31
Sorry, noch vergessen zu schreiben:
GONEO ist mit 64bit dabei
1&1 mit 32 bit
7. Juli 2010 um 13:05
Beim Suchen nach der unerklärlichen Langsamkeit und zu hohen CPU Auslastung meines Blogs auf diese Seite gestossen und möchte euch mitteilen, woran es bei mir gelegen hat.
Es waren die Permalinks !
die dürfen nicht mit %postname% anfangen, vor allem nicht, wenn man relativ viele Posts hat.
Ich weiß, das steht auch in der WordPress Doku und alte Hasen wissen das bestimmt, aber vielleicht hilft das ja dem ein oder anderen Suchenden….
5. Oktober 2010 um 12:24
Ein paar Tipps wie sich der Speicherverbrauch systematisch reduzieren lässt habe ich unter:
WordPress Speicherverbrauch verringern
zusammen gestellt.
Über Erfahrungsberichte damit würde ich mich natürlich freuen.
Viel Erfolg damit
26. Oktober 2010 um 13:47
Ich musste eben von 48M auf 64M erhöhen (64Bit Debian) nachem ich gestern das W3 Total Cache Plugin installiert habe. Jetzt laufen insgesamt 40 Plugins, da kann ich WordPress nicht wirklich einen Vorwurf des Speicherhungers machen ;)
14. November 2010 um 15:27
Ich habe mir erst vor ein paar Tagen ein WordPress 3.0.1 mit deutscher Spracherweiterung aufgesetzt. Da war dann schon mit 3 Plugins Schluss.
Hoster angeschieben, der setzte mich davon in Kenntnis, dass ich auf einem 64Bit CentOS System mit 128MB Speicher laufe. Davon sind aber nur 32MB voreingestellt. Ich konnte zum Glück selber auf 128MB erhöhen. Nun läuft alles prima.
Finde es trotz allem hart, dass selbst eine frische, schmale Installation schon so schnell an seine Grenzen kommt.
Gruß Sebastian
19. November 2010 um 17:05
34.67MB bei 4 aktivierten PlugIns auf 64bit -
Es ist definitiv ein Problem von 64bit Servern ich habe ca. 5 verschiedene Hoster bei dennen ich WP auf 64bit laufen habe, und nur bei den 64ern ist der benötigte Speicher so hoch!
9. Dezember 2010 um 04:26
So,… nachdem ich so viel Müll zu diesem lästigen Thema gefunden habe (bei mir ging nichts mehr) hier meine lösung
einfach die datei aus der fehlermeldung öffnen und folgendes ändern
#define (‘WPLANG’, ‘de_DE’);
define (‘WPLANG’, ”);
so ist das Backend auf English aber ich kann wieder arbeiten….
war doch nicht schwer, oder ?
9. Dezember 2010 um 13:16
@Paule:
Den Tipp haben wir auch genannt, aber der behebt nicht das Problem, sondern nur das Symptom. Außerdem ist im schlechtesten Fall auch das Frontend auf Deutsch.
7. April 2011 um 23:15
Hallo,
Ich habe ständig das Problem mit dem Speicher. Ich habe nun irgendwo gelesen ich soll in der wp-config.php Die Zeile define (’WPLANG’, ‘de_DE’); mit der Zeile define (’WPLANG’, ”); ersetzen – seit ich das gemacht habe funktioniert es wieder. Was kann ich ansonsten noch tun? (Hoster 64bit System, akuell 64MB zugewiesen für mich).
Zielt die Lösung mit der mo.php auf das Selbe ab und viel wichtiger gibt es seine überarbeitete mo.php für WordPress 3.1.1.
25. Mai 2011 um 12:35
Mich wundert mein Speicherverbrauch auch. Hatte schon das Theme in verdacht, doch das ist es nicht.
Meine aktuellen Daten:
PHP Version : 5.2.12-nmm2 / 64Bit OS
Memory limit : 64 MByte
Memory usage : 48.79 MByte
Das sind 76% des Memorys in gebrauch.
Plugins habe ich nur 12 installiert.
Super Cach ist auch installiert, wie sehen die Werte wohl ohne aus?
:-(
Habe erst knapp 100 User am Tag. Was macht der Server wenn ich 1.000 Besucher oder mehr am Tag habe.
Denke und schaue mich jetzt schon nach einem guten geeigneten und bezahlbaren Server um.
Nebenbei: wenn jemand von Euch zur Wahl eines Servers einen guten Tipp hat würde ich das klasse finden.
24. November 2011 um 09:22
Als Informtiker könnte ich nach diesem dummen Vergleich glatt heulen.