Und noch einmal "Out-of-Memory"

Vorsicht, jetzt wird es techisch.

Da sich laut den oben genannten Aussagen der Speicherverbrauch quasi verdoppelt hat, mal die ketzerische Frage, ob der alte Server 32Bit und der neue Server 64bit ist ?

Aus meiner täglichen Erfahrung im Bereich C++ im Enterprise Entwicklungbereich kann ich sagen, das der Speicherverbrauch für ein und dasselbe Programm nur einmal 32bit und einmal 64bit compiled nahezu mit Faktor 2 zu Laufzeit eingeht, wenn man nicht nur Strings "hortet".
PHP intern ist in C geschrieben und unterliegt somit ebenfalls einem Größenzuwachs beim Schritt von 32 zu 64 bit für Datentypen wie Zahlen, Strukturen, Arrays oder Pointer. Und davon gibts haufenweise intern bei der Ausführung eines (oder mehrerer) PHP Scripte.

Dies würde sehr passend die Verdopplung erklären. Kannst du dies bestätigen, das du von 32 auf 64 bit Platform umziehst ?

Bevor ich mir die Finger verbrenne, werde ich morgen den tTech fragen. Aber da ich von einer DualCore Atlon 2 GB Ram Maschine mit Suse10.x auf einen 2x Quad Core mit 8 GB Ram und Ubuntu8.04.x umgezogen habe, bin ich mir fast sicher das es von 32 auf 64 Bit gezogen ist.

Aber der Speicherbedarf hat sich ja nicht überall verdoppelt, von 17 auf 24 MB ist ja kein verdoppeln und auch bei meinen test Blogs wars kein direktes verdoppeln.
Und bei deiner Antwort hab Gnade mit mir, sonst weint der Tech der mir dein Latein entschlüsseln muss :)

Ein Text (String) verdoppelt sich natürlich nicht, der Inhalt ist auch bei 64bit genau gleich lang. Aber die Verwaltung, wo genau der im Speicher liegt (Pointer) war 4 Byte und ist nun 8 Byte. Auch ist unter 64Bit die Speicherverwaltung sehr viel großzügiger mit Anforderungen von Speicherblöcken (Granularität) die von 4kB Seiten schon mal auf 8kB oder 64kB Seiten gestellt sein kann. Stell dir vor, du willst was mit der Größe von 30 Byte in den Speicher legen, dann landet das bei 32bit in einem 4kB Block unter 64Bit aber u.U. in einem 64kB Block. Auch wenn dann nix mehr in dem Speicher soll, hast du den gerade verbraucht. Dieser Overhead ist dann das eigentliche Problem, aber eben auch OS abhängig.
Somit wird das nie genau x2 sein aber deutlich in die Richtung gehen.

Genug techy Zeugs jetzt ... :mrgreen:

Zumindest habe ich jetzt eine Zustimmung vom tech, ich habe von 32 auf 64 bit umgezogen.
Aber wirklich bei dem Problem helfen tut des nun nicht. Sprich Server eingesetzt mit einem Vielfachen an Speicher, den Kunden weit mehr Speicher gegeben, dafür ist der Speicher viel schneller verbraten ?
Ich meine die 64 MB reichen für meine Blogs locker aus, aber ich installier auch nicht jedes Blech :)

Das Problem liegt auch teilweise beim Verständnis des Providers. Wenn man 64Bit läuft und die Speicherverwaltung des System nun mit doppelt so großen Adressen, Zahlen und Strukturen hantiert, dann sollte man auch so schlau sein und das PHP Limit entsprechend anzupassen, wenn PHP ebenfalls 64Bit ist.
Aber das ist bei einigen Providern noch im Lernprozess begriffen.

Das ist ja 8MB Unterschied. In meinem Windows System unter PHP 5.3 braucht die Sprachdatei die bekannten ~4MB. Dann müssten deine Plugins also die restlichen 4MB aufbringen ?

Und Hinweis für PHP 5.3: hab ich getestet. WP 2.8.x läuft drauf, alle WP Versionen darunter jedoch in keinem Fall! Da kommst du aus Warnings und Errors gar nicht mehr raus.

Kannst du mal xdebug deaktivieren und alle debuggin Sachen ?
Ich glaube, der "merkt" sich zu viel Stacktrace, da die neuen mopo Klassen, die Nikolays geschrieben hat, 3300 Instanzen einer Klasse anlegt und die füllt (sehr komische Programmierung, ist in WP < 2.8 ganz anders).

Zitat

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 den 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 eine Modifikation in Beta Status 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.

(auch im Blog Artikel kommentiert, ein öffentlicher Betatest sozusagen, wer will)

Mein Beitrag samt Betatest-Download ist jetzt freigeschalten und hier zu finden http://www.code-styling.de/deutsch/wordpr…auch-minimieren

Danke, das ist egal wo, nur irgendwie muß es ja mal voran gehen, deswegen sammel ich.
Welche PHP Version ist da am Laufen 5.2.9 ?
...und leere Pluralformen sind nie gut, danke für den Hinweis :)

In der Zwischenzeit gibt es jetzt eine Beta 2 zu Download, die auch 64bit Server korrekt behandeln sollte (deutsch statt englisch).
PHP 4 Verträglichkeit wurde von schnurpsel bereits getestet und arbeite auch wieder.
Link: http://www.code-styling.de/deutsch/wordpr…auch-minimieren

Ebenfalls sehr lesenswert ist die vorläufige Analyse, die ich anhand der Rückmeldungen erstellt hab. Nicht nur WordPress selbst verschwendet Speicher, ein Blick in die PHP Bugliste spricht Bände!
Link: http://www.code-styling.de/deutsch/wordpr…-erste-analysen

Hi, ich melde mich nochmal wegen einem ganz neuen Memmory Fehler. Sonst trat der Fehler bei mir nur in der Administration auf, jetzt tritt er aber auch auf, wenn ich auf meiner Seite surfe.

Fehlermeldung sieht so aus:

Fatal error:  Allowed memory size of 41943040 bytes exhausted (tried to allocate 74 bytes) in .../wp-settings.php on line 288

Laut Dashboard verwende ich 26.19 MByte von 40 MByte

Ich kann mir den Fehler nicht erklären. Hat irgendjemand eine Idee?
Dieser Fehler kommt auch erst seid ich heute auf Version WP2.8.2 Upgegradet habe.

Der Fehler kommt nur ab und zu, wenn ich auf einen Link in der Menüleiste klicke. Hier die Seite: http://anime.blogsite.org