Code Styling Project » memory size of xxx bytes exhausted

memory size of xxx bytes exhausted - es nervt langsam gewaltig

codestyling | 22. September 2010 | 00:58

Seit Erscheinen der Version 3.0 von WordPress verstärken sich wieder die Anfragen und Hilferufe zum Thema: Mein Speicherlimit ist überschritten! Auch mir ging es in einigen Tests wieder so und auch mein Plugin Codestyling Localization schlägt zunehmen hart an dieser Grenze an, wenn es WordPress selbst oder ein besonders großes Plugin bearbeiten soll.
Also bin ich mal wieder zur Recherche übergegangen und Seiten gelesen, hab einige Tests durchgeführt und dabei Erstaunliches gefunden.

Netzrecherche und Unglaubliches bei PHP selbst

Das PHP als reine untypisierte und interpretierte Sprache mit Focus auf massive Textmanipulation ausgelegt ist, sollte ja eigentlich jedem klar sein. Deswegen erwarte ich auch kein Umgang mit dem Speicher wie in hoch optimierten C oder C++ Programmen. Was ich allerdings in einem Fehlerreport aus dem PHP Trac gelesen hab, ließ mich erstmal in den Stuhl zurückfallen. Das man so mit Speicher umgeht nur um auf Speed zu kommen, ist schon ein starkes Stück. Hier der Link zum englischen Eintrag PHP Trac #41053, den ich hier nochmal so gut es geht auf deutsch erläutere.

Fangen wir mit dem Beispielcode aus den PHP Trac Eintrag mal an:

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
function getMemoryUsage()
{
    return round(memory_get_usage() / (1024*1024), 1)." MB";
}
function printMemoryUsage()
{
    print("Memory = ".getMemoryUsage()." <br>\n");
}
printMemoryUsage();
 
$end = 1000000;
$array = array();
printMemoryUsage();
for($i = 0; $i < $end; $i++)
{
    $array[$i] = 0;
}
printMemoryUsage();
?>
timing: 0.063s

PHP
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20	<?php function getMemoryUsage() { return round(memory_get_usage() / (1024*1024), 1)." MB"; } function printMemoryUsage() { print("Memory = ".getMemoryUsage()." <br>\n"); } printMemoryUsage(); $end = 1000000; $array = array(); printMemoryUsage(); for($i = 0; $i < $end; $i++) { $array[$i] = 0; } printMemoryUsage(); ?>
timing: 0.063s

Was macht denn nun der Testcode im Detail? Eigentlich nicht viel, außer:

Speicherverbrauch ausgeben können
in einer Schleife ein Array zu füllen mit Schlüssel als fortlaufende Nummer und Wert 0
die Schleife erzeugt 1000000 (eine Million) Wertepaare, die Zahl (integer) auf 0 abbildet
es ist unter einem 32bit System getestet worden

Naiv würde ich folgende Rechnung anstellen: Ich hab also 2 integer Zahlen 32bit mit je 4 Bytes und das 1000000 mal = 2 * 4 * 1000000 = 8000000 (acht Millionen) Bytes Netto Speichermenge. Dazu rechne ich rund 10% Overhead für die Hashverwaltung, macht rund 9 Millionen Bytes oder 8,5MB.

Nun die tollen Ergebnisse mit PHP 5.1.1:

PHP
1
2
3
Memory = 0 MB
Memory = 0 MB
Memory = 57.5 MB
timing: 0.039s

PHP
1 2 3	Memory = 0 MB Memory = 0 MB Memory = 57.5 MB
timing: 0.039s

… und zur Krönung noch die von PHP 5.2.1:

PHP
1
2
3
Memory = 0.1 MB
Memory = 0.1 MB
Memory = 99.4 MB
timing: 0.046s

PHP
1 2 3	Memory = 0.1 MB Memory = 0.1 MB Memory = 99.4 MB
timing: 0.046s

Mal davon abgesehen, daß es in PHP 5.2.2 dann wieder so aussieht, wie in PHP 5.1.2, sind mir 58 Megabyte ein dicker Happen, den sich hier PHP gönnt, um diese Daten abzulegen.

Es folgte auch umgehend eine Erklärung aus dem PHP Team, warum das so ist. Die interne Strukturierung der Variablen von PHP können jederzeit alles sein und müssen umwandelbar sein. Deswegen belegt ein simpler Integer Wert auf diese Weise laut Angaben und meiner eigenen PHP C Code Analyse tatsächlich schlaffe 68 Byte.

Wenn also jede einzelne Variable einen Overhead von 64 Byte + Nutzdaten (String ist ja meist mehr als nur 4 Byte integer) hat, dann kann man sich leicht selbst ausrechnen, wie viele Variablen man in den Speicher bekommt, bevor das memory limit überschritten wird. Und dabei haben wir noch nicht mal den Programmcode selbst mit berechnet!

Noch schlimmer wird das bei 64bit Systemen, denn die C Strukturen von PHP sind nicht korrekt im Speicher ausgerichtet, wie IA64 Architekturen das gern hätten. Dort wird also noch zusätzlich Speicher “gepaddet” und ein Eintrag kann dann schon mal 80 Byte oder größer werden. Deswegen verschlingt also PHP auf 64 Bit Systemen auch deutlich mehr Speicher als auf 32bit. Wie 64bit Programmierung aussieht und wo die Fallstricke sind, kann man hier nachlesen: Data Alignment when Migrating to 64-Bit Intel® Architecture.

Das Unverständnis der Hoster bei 64 Bit Systemen

Liebe Hoster, wenn ihr den Kunden einen 64bit Server mit 64bit PHP anbietet, dann reichen nun mal nicht die 32M oder 40M aus. Die interne Architektur von PHP ist noch nicht komplett an 64bit Systeme so angepasst, das sie vollends speichersparend ist. Außerdem sind die Pointer im C Code wirklich doppelt so groß, weswegen ausführbarer Code und im Speicher erzeugte Strukturen auch deutlich mehr Platz brauchen.
Also entweder den Kunden die Wahl lassen oder ausreichend Speicher zur Verfügung stellen, alles andere ist Selbstbetrug und Verarschung.

WordPress Core Team und die Sorglosigkeit beim Umgang mit Speicher

Ich hab auch ein paar Sätze an die Jungs zu vergeben. Ihr macht schon einen guten Job, Fehler und Bugs bauen wir alle irgendwo ein und bis zu Ende denken die wenigsten ein neues Feature. Aber ihr sollte nicht blind und taub eure Augen und Ohren vor den Bedürfnissen der Community verschliessen, die euch groß gemacht hat.

PHP
1
2
3
4
5
6
7
8
9
10
11
function wp_initial_constants( ) {
    global $blog_id;
 
    // set memory limits
    if ( !defined('WP_MEMORY_LIMIT') ) {
        if( is_multisite() ) {
            define('WP_MEMORY_LIMIT', '64M');
        } else {
            define('WP_MEMORY_LIMIT', '32M');
        }
    }
timing: 0.029s

PHP
1 2 3 4 5 6 7 8 9 10 11	function wp_initial_constants( ) { global $blog_id; // set memory limits if ( !defined('WP_MEMORY_LIMIT') ) { if( is_multisite() ) { define('WP_MEMORY_LIMIT', '64M'); } else { define('WP_MEMORY_LIMIT', '32M'); } }
timing: 0.029s

(aus der Datei des Cores: default-constants.php)

Steht doch endlich mal dazu, was ihr hier in den Code gedonnert habt und stellt endlich klar, daß WordPress 3.0 in einer Standardinstallation mit Ach und Krach bei 32M läuft und WordPress Multi Site unter 64MB eine Illusion sein dürfte.

Steht auch dazu, daß ihr es den Nutzern im Ausland mit nicht eingebauten Sprachen sondern nachladbaren Sprachdateien schwerer macht und testet so etwas auch mal auf euren Systemen! Dann werdet ihr merken, daß eure Implementierung der Sprachdateienverarbeitung unter dem o.g. Speicherverbrauch von Variablen aus einer 360 kByte WordPress Sprachdatei locker mal im Speicher 4MB kostet. Mit dem Theme und jedem übersetzbaren Plugin kommt dann noch mehr hinzu, sodaß man das Ende des Speichers kommen sehen kann.

Was bedeutet das für mich persönlich?

Ich werden mich weiterhin darum bemühen, die Speicherfresser ausfindig zu machen und auch meinen eigenen Code dahingended zu untersuchen, ob ich nicht doch noch was tun kann.
Deshalb wird es auch ein Update meines Plugins geben, das dann auch unter widrigsten Bedingungen mit WordPress Sprachdateien umgehen kann.
Dazu habe ich eine Multi Site Installation künstlich auf 32M limitiert. Ohne eine deutsche Sprachdatei bin ich bereits bei 22M mit geladener Sprachdatei bereits bei über 26M und hab noch 4 - 6M Platz für die Sprachdateiverarbeitung. Normalerweise reicht das überhaupt nicht aus, wie ihr euch bereits aus dem bisher Geschriebenen denken könnt.

Deswegen gibt es dieses neue Feature beim nächsten Update und mein Plugin scannt tatsächlich unter diesen Bedingungen noch WordPress und große Plugins ein. Auch bearbeiten geht dann noch. Ich kann es zwar nicht garantieren, denn es hängt ja auch noch von der Menge der Plugins ab, die ihr zusätzlich noch laufen habt, aber solange ihr nicht gerade weniger als 4 - 6MB noch übrig habt, wird das funktionieren.

Weil ich viele Anfragen bekommen hab, was die angepasste Sprachdateiverarbeitung im Core macht (der Patch für die Po/Mo Dateien des WP Cores), will ich nur sagen, daß ich diese wieder hervorkramen werde und versuche, da noch mehr rauszuholen.

Fazit und Ausblicke

Ich werde den Speicherhunger einiger Komponenten weiter analysieren und wenn mir auffällt, daß man daran was machen könnte, werde ich es früher oder später angehen. Erwartet von mir keine Wunder, ich hab leider keine Zeit in Überfluß. Das alles mach ich nur nebenbei, aus Leidenschaft und aus Frust.
Sollte jemand Interesse haben, sich an der Jagd nach Speicherleichen zu beteiligen, lasst es mich wissen. Ich hoffe, ihr versteht, daß ich helfen will aber vielleicht nicht in eine Zeitspanne reagieren kann, die sich manche so wünschen.

Kategorien: Deutsch, WordPress (DE)
: RSS Kommentare

40 Antworten Schreib einen Kommentar

Frank

22.09.2010 | 09:11

Vielen Dank für diesen Beitrag, wie immer schon erklärt - die Ressourcen in WP waren mir nicht neu; diese erzielen im übrigen auch den http-Fehler, den viele User haben; so zumindest meine Analyse und bei einigen Hostern wird dies auch nicht anders und WP wird sich so schnell nicht umstellen; wp_initial_constants() ist ja nur der Ansatz, in einigen Funktionen dreht WP das sogar noch hoch.
Die Hinweise und Erklärungen aus dem PHP Trac - toll!
Wäre was für WPE

memory size of xxx bytes exhausted - es nervt langsam gewaltig

Netzrecherche und Unglaubliches bei PHP selbst

Das Unverständnis der Hoster bei 64 Bit Systemen

WordPress Core Team und die Sorglosigkeit beim Umgang mit Speicher

Was bedeutet das für mich persönlich?

Fazit und Ausblicke

40 Antworten Schreib einen Kommentar

Andreas G.

skye

Navigation

Suche

Neuere Beiträge ...

Ältere Beiträge ...