[ljungi]

Servus,

bekommen immer folgende Fehlermeldung, die an sich keinen Sinn ergibt, sobald eine .jpg-Datei, die größer als 1,3 MB ist, hochgeladen wird. An und für sich meint er ja, dass er 8448 Bytes sammeln will, aber 18 MB überschritten wurden.

Fatal error: Allowed memory size of 18874368 bytes exhausted (tried to allocate 8448 bytes) in /srv/www/htdocs/ld-network/html/modules/imgupload/upload.php on line 40

Dies kommt aber immer nur, wenn ein .jpg-Bild hochgeladen wird. ist es eine .gif oder .png, dann geht alles normal. Im folgenden noch der banale Code:

PHP-Code:

if($_FILES['uploadSource']['type'][$i]=="image/jpeg" || $_FILES['uploadSource']['type'][$i]=="image/pjpeg") {
                $imgA       = imagecreatefromjpeg($oldscreen);
            }elseif($_FILES['uploadSource']['type'][$i]=="image/gif") {
                $imgA       = imagecreatefromgif($oldscreen);    
            }elseif($_FILES['uploadSource']['type'][$i]=="image/png") {
                $mgA       = imagecreatefrompng($oldscreen);    
            } 


Ist irgendwoher bekannt, dass .jpg mehr Ressourcen verbraucht?
Ich meine: 18 MB cache für ein Script sind schon enorm, fast zu viel.

Irgendwelche Ideen?

Greets
Ljungi

[Ben]

Hm, aus dem Tutorial hier habe ich gelernt:

Dateigröße <> Datenmenge

Hm .. jo.

[robo47]

Wie CIX88 in dem Text schreibt, die Dateigröße ist total egal, es geht im Endeffekt um die Auflösung der Datei die umgesetzt werden muss.

[ljungi]

Und warum isses dann bei einer png-Datei nicht so? Die Auflösung bei pngs ist doch wesentlich höher als bei jpgs?

[robo47]

es geht hier um 3 faktore: höhe, breite, farbtiefe und da sollte es unabhängig davon sein ob das bild ein GIF, ein PNG oder ein jpeg ist, aussnahmen stellen VIELEICHT, da bin ich mir aber nicht sicher, weil gdlib das ja intern eh alles sehr stark aufbläst, gifs dar, wenn sie nur 256 farben nutzen und 8bit-pngs

[Waq]

Zitat von ljungi

Und warum isses dann bei einer png-Datei nicht so? Die Auflösung bei pngs ist doch wesentlich höher als bei jpgs?

Im Gegenteil, da JPEG im Gegensatz zu PNG und GIF keine verlustfreie Kompression ist, kann es bei gleicher Dateigrösse wesentlich höhere Auflösungen erreichen, die nach dem Entpacken dann natürlich bei PHP in den Speicher passen müssen.

[CIX88]

Ich meine: 18 MB cache für ein Script sind schon enorm, fast zu viel.

Jedes Grafikprogramm erstellt vom Bild eine umkomprimierte Version von Bild, also ein Roh-Bild wenn man es so nennen kann.
Es ist praktisch ein Duplikat des geladenen Bildes.
Da spielt auch weniger das Bildformat eine Rolle, sondern jedes einzelne Pixel mit seiner Farbtiefe.
Bei einigen Grafikprogramm wird das als Info sogar angezeigt.
(http://www.cix88.de/d/tut_gdlib.gif)

Natürlich nur solange, wie sich die Bild-Daten im Speicher befinden.
Erst wenn das Bild gespeichert wird, wird das Bildformat gewählt und entsprechend erfolgt die Komprimierung.

Die GDlib macht es genauso, nur schlimmer

[MrNiceGuy]

Zu beachten ist wohl auch, dass jede Variable, jede geladene Klasse oder Funktion, sowie die PHP-Scripte selber den Speicher füllen. Jede Variable, die nicht wieder gelöscht wird, bleibt bis zum Ende des Scriptes bestehen. Ebenso auch Bilder, die geladen werden. Wenn man zwischendurch den Speicher also nicht mal wieder frei gibt, indem man nicht mehr benötigte Variablen löscht, kommt es auch bei großen Cache schnell zum Überlauf.

[WarrenFaith]

Garbage-Collector hilft bei Java, bei PHP muss man selbst noch mitmachen richtig?

[robo47]

hmm naja, also wenn ich ne funktion habe dann ist am Funktionsende das an variablen was nur intern genutzt wurde ja wieder wech und da man meist ja eh über funktion/klassen arbeitet kommt so nicht unbedingt so viel overhead zusammen oder?

http://www.robo47.net/public/php/speicherverbrauch.php

[MrNiceGuy]

@Robo: Da wäre ich mir nicht so sicher, zum Beispiel bleiben fopen etc. bis zum Ende des Scriptes bestehen oder halt bis zum fclose. Ebenso meine ich ist es auch mit Graifken, egal, ob Funktion oder nicht, es sollte vor dem Ende einer jeden Funktion aufgeräumt werden, ist meiner Meinung nach sauberer.

Für mich ist jedenfalls vorstellbar, dass die Variablen im Hintergrund gehalten werden, wenngleich sie auch nur intern in der Funktion benutzt wurden und erst beim erneuten Aufruf gelöscht werden, das ist aber nur eine Vermutung, die ich nicht belegen kann...

[robo47]

Zitat von MrNiceGuy

@Robo: Da wäre ich mir nicht so sicher, zum Beispiel bleiben fopen etc. bis zum Ende des Scriptes bestehen oder halt bis zum fclose. Ebenso meine ich ist es auch mit Graifken, egal, ob Funktion oder nicht, es sollte vor dem Ende einer jeden Funktion aufgeräumt werden, ist meiner Meinung nach sauberer.

http://www.robo47.net/public/php/speicherverbrauch2.php

Also ohne fclose bleiben da reste übrigt.

Zitat von MrNiceGuy

Für mich ist jedenfalls vorstellbar, dass die Variablen im Hintergrund gehalten werden, wenngleich sie auch nur intern in der Funktion benutzt wurden und erst beim erneuten Aufruf gelöscht werden, das ist aber nur eine Vermutung, die ich nicht belegen kann...

dann würde ja mein Script nach dem Funktionsaufruf trotzdem noch ca 1,4 MB belegt haben oder ? Also für Resourcen und andere Sachen kann das stimmen, aber ich denke für "normale" Variablen eher nicht.

[MrNiceGuy]

Wie gesagt, belegen kann ich es nicht, aber vorstellbar wäre es in meinen Augen dennoch. Die Erklärung dafür ist auch garnicht mal soweit hergeholt finde ich: Wenn man erst beim Aufruf einer Funktion die Daten löscht, spart man sich am Ende einer Funktion die Schreibzeit im Speicher, um diesen wieder frei zu geben. Könnte also um ein µ schneller sein das Ganze.

Wie gesagt: Nichts handfestes und wahrscheinlich wird es auch so nicht gehandhabt, aber vorstellbar bleibt es dennoch

EDIT: Dein Test-Script zeigt ja schon, dass ich mit Resources nicht unbedingt unrecht hatte... Und ich meine, dass es auch mit Bildern so ist. Ich hatte mal ein Script zum Kleinrechnen von Bildern das unmengen an Speicher brauchte. Nach dem Einfügen der "Zerstörung" des Bildes (obwohl die selbe Variable immer überschrieben wurde und eigentlich der Speicher hätte freigegeben / überschrieben werden müssen) ist der Speicherhunger deutlich zurückgegangen.

[CIX88]

Vielleicht etwas OT, weil es nicht zum eigentlichen passt, aber eigene Versuche haben ergeben, das PHP5 mehr Speicher verbraucht als PHP4.
Kann das einer Bestätigen oder bin ich besoffen ?

[Bleistift]

Naja... Kann ich mir schon vorstellen. PHP5 kann ja auch einiges mehr (OOP...). Hast du Zahlen?

[CIX88]

Nein keine genauen Zahlen, aber bei einfachen Scripten waren es ca. 30-70kb mehr.
Bei arbeiten mit der GDlib waren teilweise Unterschiede von 500kb !
Gemessen mit memory_get_usage(), selbe Scripte, einmal mit PHP4 und einmal mit PHP5.

[Waq]

Bei PHP wird bei grösseren Versionswechseln schonmal der Memory-Manager grundlegend umgebaut, um Speicherfragmentierung usw. zu beeinflussen. Da kann sich schonmal der Speicherverbrauch ändern. Hat die 5.2er nicht wieder nen neuen?

[ljungi]

Hi,

danke für die zahlreichen Antworten!

Dass PHP alle Vars in den Cache speichert, die im Script benutzt werden, im Grunde eigentlich alles in den Cache wandert, war mir klar.

Leider haben wir immer noch keine wirkliche Lösung für das Problem gefunden.

Haben nun einfach ne Option "kein Thumbnail erstellen" eingebaut, die der User nutzen kann, falls das Bild zu groß ist. Ich weiß, nicht das Wahre, aber der Server hat nur 1024 MB Ram... ^^

[robo47]

die frage ist WIE OFT wird das genutzt ? wenns ein eigener Server ist, kannst du ja max-ram runtersetzen und nur für das Script hochsetzen ? wirst ja merken ob es dazu kommt, dass der RAM wirklich irgendwann voll ist

[Bleistift]

Ich würde das nicht dem User überlassen. Prüfe das doch selber.