WP 2.8: Und noch einmal "Out-of-Memory"

[codestyling]

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 ?

[Suleitec]

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

[codestyling]

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 ...

[Suleitec]

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

[codestyling]

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.

[jottlieb]

Da die Indizien ja stark dafür sprechen, dass es an der 32 Bit / 64 Bit Geschichte liegt, sollte man nun versuchen, das weiter zu verifizieren.

[marX]

Ich habs im Blog schon geschrieben:

Zitat von /me

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.

Wenn ich ncoh was weiteres testen kann dann sagt einfach bescheid. Ich hab nur grade kein 32bit-System zum Gegencheck da, aber wäre notfalls schnell installiert.

Achja, im Blog noch vergessen:
Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.1 with Suhosin-Patch

(Note to self: PHP 5.3 installieren... )

[codestyling]

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.

[marX]

Zitat von codestyling

Das ist ja 8MB Unterschied.

Eigentlich sogar 11, laut memory_get_peak_usage(). Ohne Sprachdatei ist kaum ein Unterschied zwischen memory_get_usage() und memory_get_peak_usage().

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

Wie gesagt, Standardtheme und keine Plugins. Allerdings eine Dev-Version von PHP mit Xdebug. Keine Ahnung ob das für den Unterschied ne Rolle spielt... Und WP 2.9 (SVN latest).

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.

Ja, ist mir hier im Forum auch schon über den Weg gelaufen. Das Problem ist wohl die Error-Reporting-Einstellung in der wp-settings, wobei 2.7.1 die E_DEPRECATED-Konstante beachtet (aber vermutlich nicht der geänderte Wert für E_ALL...).

Aber Ubuntu hat eh noch keine Pakete für 5.3.

[codestyling]

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).