Folgendes Problem habe ich seit der Umstellung des Betriebssystems von OS/2 auf Windows XP. Beim DL von Dateien größer des in der PHP.INI angegebenen Wertes für memory_limit (aktuell bereits auf 64M erhöht) gibt es folgenden PHP Fehler:
Allowed memory size of 67108864 bytes exhausted (tried to allocate 1048577 bytes) in ...\dl_mod\classes\class_dlmod.php on line 1406
while (!feof($handle))
{
$buffer = fread($handle, $chunksize);
echo $buffer;
if ($retbytes)
{
$cnt += strlen($buffer);
}
}
Was läuft da schief?
Außerdem wird die zu DL Datei wohl jedes mal direkt in den Speicher geladen um gesendet zu werden, anstelle dies direkt von der HDD zu tun. Das verlangsamt den Start des DLs nur unnötig, außerdem kenne ich dies von OS/2 nicht. Absicht oder liegt's an meiner Konfiguration des Apache?
Als Serversoftware läuft hier das aktuelle XAMPP 1.6.3a.
Aktualisiere mal den MOD.
Ich habe den Speicherverbrauch in einer der letzten Versionen gesenkt, so daß der Load deutlich schneller und sicherer von statten geht.
Und btw:
Wieviele Kategorien und Downloads hast Du denn aktuell?
oxpus hat geschrieben:Aktualisiere mal den MOD.
Ich habe den Speicherverbrauch in einer der letzten Versionen gesenkt, so daß der Load deutlich schneller und sicherer von statten geht.
Jupp, das werde ich heute Abend tun. Jetzt falle ich aber erstmal in die Federn...
Und btw:
Wieviele Kategorien und Downloads hast Du denn aktuell?
Nicht wirklich viel. Es sind 2 Haupt- und ca.20 Unterkategorien mit noch nur ca. 1000 Dateien.
Das sollte mit der 5.2.2 gehen.
Ich habe den seinerzeit so umgebaut, daß per default nur das Nötigste geladen wird, da die Details nur an einer Stelle gebraucht werden.
Wenn es jetzt immer noch klemmt (64 MB sind dabei schon eine Menge Speicher), dann schaue ich nochmal drüber.
Moment!
Zeile 1406 der class_dl_mod.php hat nichts mit der Vorbereitung des MODs zu tun, sondern mit dem senden der Datei an den Client (Browser).
Schalte mal die Download Methode um, bzw. verringere die Chunks für die Downloads.
Der MOD versucht über 64 MB Datei auf einmal zu laden, daß ist heftig viel!
oxpus hat geschrieben:Zeile 1406 der class_dl_mod.php hat nichts mit der Vorbereitung des MODs zu tun, sondern mit dem senden der Datei an den Client (Browser).
Ahja.
Schalte mal die Download Methode um, bzw. verringere die Chunks für die Downloads.
Das habe ich eben ohne Erfolg getan. Ebenso erfolglos habe ich in der php.ini die memory_limits zurück auf 16MB gesetzt. D.h.alle Dateien größer/gleich 16MB können nun nicht mehr runter geladen werden.
Der MOD versucht über 64 MB Datei auf einmal zu laden, daß ist heftig viel!
Warum denn das? Das leuchtet mir nicht ein. Die memory_limits Angabe ist doch die Obergrenze und nicht das was immer genutzt werden soll, oder liege ich da mal wieder falsch?
Nachtrag:
Kann es sein, das ich einfach nur einen Fehler in der php.ini habe? Welche(r) Parameter währen in diesem Fall zu überprüfen?
Und die "alte" Download Methode klappt hier auch nicht?
Komisch, die sendet doch "stur" komplett an den Browser, mit einer Methode, die auch auf allen anderen Seiten grosse Downloads ermöglichen...
Zuletzt geändert von oxpus am Mi 05.Sep, 2007 08:42, insgesamt 2-mal geändert.
Welche(r) PHP Parameter in der PHP.INI hat denn noch Einfluss darauf?
Eigentlich nur die Speichergrösse, wobei diese bei der Funktion readfile(); keinen Einfluss haben sollte.
Daher verwunderst, daß auch die alte Funktion nicht geht.
Ich kann aber auch nochmal nachschauen, ob es andere Möglichkeiten gibt, Downloads bereitzustellen.
Vielleicht per Direktaufruf, sofern möglich...
Mal schaun, vielleicht kommt mit die Tage nochmal eine Erleuchtung für extra grosse Dateien über dem bestehenden PHP-Limit hinaus.
Welche(r) PHP Parameter in der PHP.INI hat denn noch Einfluss darauf?
Eigentlich nur die Speichergrösse, wobei diese bei der Funktion readfile(); keinen Einfluss haben sollte.
Daher verwunderst, daß auch die alte Funktion nicht geht.
Unter OS/2 hat's ja auch definitiv funktioniert. Kann evtl. auch der Apache der Verursacher dafür sein? Unter OS/2 hatte ich nämlich eine andere Serversoftware laufen.
Hm, wäre eine Idee.
Wenn es der Apache ist, muss ich dringend an der Download Routine was ändern, denn der wird ja sehr oft eingesetzt.
Und dazu ist es immer unklug, an den Einstellungen des Indianers rumzuschrauben, nur, um ein PHP-Script zum Laufen zu bekommen...
Aber:
Wenn ich die Download Methode auf Direktzugriffe umstelle, muss man auswählen, was mit der Datei passieren soll.
Wenn es z. B. PDF-Dateien sind, werden die eher angezeigt, als mit der jetzigen Methode.
Naja, schaun wir mal, was ich aus dem Interpreter an dieser Stelle rausquetschen kann...
oxpus hat geschrieben:Hm, wäre eine Idee.
Wenn es der Apache ist, muss ich dringend an der Download Routine was ändern, denn der wird ja sehr oft eingesetzt.
Was läuft denn bei dir als Server?
Aber:
Wenn ich die Download Methode auf Direktzugriffe umstelle, muss man auswählen, was mit der Datei passieren soll.
Was ich auch gut finde. Das tut man dann doch eh immer nur 1x pro Dateityp.
Wenn es z. B. PDF-Dateien sind, werden die eher angezeigt, als mit der jetzigen Methode.
Du meinst da springt gleich der AdobeReader an? Das ist dann aber ein Problem des Browsers bzw. dessen Bedieners. :roll:
Naja, schaun wir mal, was ich aus dem Interpreter an dieser Stelle rausquetschen kann...
oxpus hat geschrieben:Ja, schon klar, aber leider darf ich mich nicht klonen
Dann schreibe ich mal meinen Bundestagsabgeordneten an, für einen entsprechenden Gesetzesvorschlag...
Spaß beiseite. :roll:
Heute schrieb mir einer meiner User, das viele Dateien nach dem DL auch kaputt sind. Das lies sich durch das Umstellen auf die alte DL Methode zwar beheben, ist aber nicht schön. Da es vorher unter OS/2 funktioniert hat, muss also auch hier der Apache der "Schuldige" sein.