upload grosser dateien scheitert - warum ? HILFE!!

[laminar]

ich habe eine php anwendung, die es ermöglichen soll dateien von 500MB bis 1GB
über den browser upzuloaden - in php4.01 und redhat.7.1 umgebung.
in der php.ini habe ich nur die werte für post_file_size und max_file_size hochgesetzt;
memory_limit und max_execution_time sind unverändert bei 8MB und 300 Sekunden, weil ich denke, dass sich diese werte nur auf das aussführende script beziehen...
(bin mir aber nicht sicher, was da genau wie läuft..)

naja, jedenfalls stoppt der upload meist so nach einer guten stunde und rund 100 MB;
ich sehe mit IE gar nichts; andere haben wohl eine "timeout" meldung bekommen, deren
genauen text uch aber nicht kenne...

nun die frage woran das liegen kann:

server konfiguration ?
php ?
probleme browserseitig ?
oder ...?

[Gaert]

Schätze es ist wirklich die max_execution time!

[Pingu]

siehe hier: http://www.php.net/manual/de/features.file-upload.common-pitfalls.php

-= Pingu =-

[laminar]

aber das liefert auch keine neue, plausible erklärung;
post_max und upoad_max stehen auf 999M

execution_time und memory_limit beziehen sich nur auf das script

[Pingu]

Original geschrieben von laminar
execution_time und memory_limit beziehen sich nur auf das script
Falsch, die beziehen sich nicht nur auf das Script. Insbesondere execution_time hat auch mit der Upload-Zeit zu tun. Ich denke die starten Ihren Watchdog schon, wenn der Request anfängt, also die ersten Bytes des Files eintrudeln und nicht erst, wenn wirklich das Script gestartet wird.
Bei memory_limit wäre ich mir auch nicht sicher, ob die erst die Datei in den Speicher laden, dann auf Platte auslagern und dann das Script starten oder ob sie gleich in die Datei schreiben. Dazu steht an keiner Stelle im Manual etwas. Also immer vom worst case ausgehen.

Außerdem ein 500MB File ist ja auch ein bißchen groß. Ist für sowas nicht FTP besser geeignet?

-= Pingu =-

[laminar]

sind leider allle nicht klar definiert;
max_execution_time bezieht sich angeblich auf die CPU-nutzung, oder soll in relation dazu stehen...

ich habe 300 sekunden - das reicht erwiesen für 80-120 MB (also eine gute stunde) im schnitt -
aber ich glaube wie gesagt nicht dass es daran liegt und ich mit 600 doppelt soviel hochladen kann..

ftp teste ich gerade, habe aber auch nichts gefunden, inwieweit sich das anders verhält...

[Gaert]

max_execution_time definierst du warscheinlich falsch....

Damit ist die Zeit gemeint für die dein Webserver für das Skript aufwendet nicht die CPU Zeit!

Nach 300 Sekunden sollte dein Skript also vom Server beendet werden....

Mit FTP hat Pingu warscheinlich nicht die FTP Funktionen gemeint sondern einen FTP server, den du zusätzlich laufen lässt!

[laminar]

niemand weiss nun wirklich ob eine max_execution_time von 300 sekunden der grund dafür ist, dass die uploads nach einer stunde und rund 1oo mb nicht weitergehen...

ftp über ftp programm ist nicht das was ich brauche; es muss über den browser gehen, weil es eine kundenanwendung ist, die eben so funktionieren soll...

kurios, dass niemand wirklich weiss, was der grund ist. und das nicht nur in diesem forum...

[sepp2k]

Probier doch einfach mal die max execution time auszuschalten. Dann weißt du obs daran liegt

[laminar]

mit:
set_time_limit(0);
verblüffenderweise lief der upload auch gleich viel länger ca. 3 stunden und 300 mb;
diese erkenntnis kombiniert mit den anderen, führt zu der ansicht, dass die sache
an einem nicht reproduzierbaren fehler scheitert, der nichts mit mir zu tun hat...

[Pingu]

Es könnte jetzt natürlich noch sein, daß jetzt noch irgendwo ein Timeout vom Apache kommt, oder vom darunterliegenden TCP/IP Stack. Ich glaube nicht daß es hierbei ein reines PHP Problem ist. Ansonsten kannst Du Dich ja auch mal direkt an die Entwickler wenden mit 'ner Support e-mail.
Denn 500 MB sind ja auch 'ne ganze Menge, die ganz schön Zeit brauchen.

-= Pingu =-

[laminar]

ich habe nur keine ahnung, wo ich noch suchen soll... es ergibt sich einfach kein einheitliches bild.

schon alleine das ich keine fehlermeldung finde ist merkwürdig;
normalerweise müsste das ganze geschehen doch irgendwo protokolliert werden
(error_log und messages zeigen nix eindeutiges, was dazu passen würde)