Probleme mit großen FTP-Uploads auf eigenen Webserver

[red-polo]

Tach!

Problem steht eigentlich schon im Betreff... Habe einen vServer (mit Root-Zugriff) laufen und Probleme mit dem FTP-Upload.

Problembeschreibung:

Zugriff per FTP, SFTP und SSH auf Webserver klappt so weit problemlos (sowohl als root als auch als user).

Uploads in homoerotischen Dosen von bis zu 5MB klappen ohne Probleme.

Schwierig wirds erst bei anständigen Uploads von größerem Umfang

--> Hier fängt der Upload wie gewohnt an, wird dann nach einer Weile (schwankend) immer langsamer bis er stehen bleibt und bricht schließlich mit Fehlermeldung ab.

Kann's daran liegen dass die Linux-Distribution zu alt, also veraltet ist, so dass sie nicht mehr mit den aktuellen Standards konform geht???

Server: Debian Linux 3.1, hat also schon ein paar Järchen auf dem Buckel.

Das Problem tritt unabhängig von Client-Computer (Mac OS X oder Windoof) und verwendetem FTP-Programm auf.

[Bluenote]

sexy, wenn du fachchinesierst

wahrscheinlich steht nur ein bettpfosten auf der leitung oder du hast mit deinen schlepphoden ein kabel gezogen

b

Bearbeitet 4. August 2009 von Bluenote

[red-polo]

sexy, wenn du fachchinesierst

wahrscheinlich steht nur ein bettpfosten auf der leitung oder du hast mit deinen schlepphoden ein kabel gezogen

b

Solltest du nicht eher beim Stammtisch sein als hier auf deine Tastatur zu sabbern, weil dir bei meinem Schreibstil einer abgeht...?

[Bluenote]

Solltest du nicht eher beim Stammtisch sein als hier auf deine Tastatur zu sabbern, weil dir bei meinem Schreibstil einer abgeht...?

ich muss hier wache halten, leider ... aber für dich hab ich immernoch ein paar tasten über die ich drücken kann

b

[diabolo]

Schiebst Du ganze Verzeichnisse auf den Server, oder sind es einzelne, große Dateien, die er nicht mag?

[red-polo]

sowohl als auch... wir reden hier von mehreren hundert MB bis in den GB-Bereich.

[Lacknase]

FTP ist von den genannten Protokollen das "schnellste". Verschlüsselung (in SFTP und SSH) macht Overhead und klaut also Bandbreite.

Aber mal zur Ausgangslage: An Debian kann es an sich kaum liegen. Was aber denkbar wäre, ist, daß Du ein Quota auf dem Server hast oder der Speicher (RAM+SWAP) begrenzt ist oder die Bandbreite bei gleichzeitigem FTP-Zugriff bei dem zuerst gekappt wird, der am längsten dranhängt. Das wird irgendwann der mit dem dicksten Upload sein. Bitte starte doch mal einen solchen dicken Upload, warte, bis die Leitung "steht" und dann logge Dich parallel via SSH ein und teile dann doch mal folgendes hier mit:

[1] Was sagt "df -h"?

[2] Was sagt "quota"?

[3] Was sagt "vmstat -s"?

[4] Was sagt "memstat" in der letzten Zeile?

Schließlich wäre es interessant zu erfahren, welcher Provider den Server hostet und welches "Leistungspaket" Du da gemietet hast. Nicht minder uninteressant wäre eine Info zum verwendeten Client - aktives oder passives FTP?

[red-polo]

Wenn die Leitung steht krieg ich auch kein Feedback mehr über SSH und werde zum gleichen Zeitpunkt rausgeschmissen wie der FTP-Transfer die Fehlermeldung auswirft.

Welcher Provider: Server4You

Welches "Leistungspaket": vSERVER Entry X2, mit 500GB Datentransfer/Monat

Verwendeten Client: bei mir CyberDuck 3.2.1, bei den anderen irgendwelche Windows Freeware-Proggies

aktives oder passives FTP: Standard (lt. Eintrag, also vermutlich so was wie automatisch)

EDIT1: Es sind keine FTP Quota limitiert/eingetragen und damit auch nicht überschritten. Auch vom inkludierten Traffic-maximum bin ich weit entfernt.

EDIT2: Derzeit habe ich generell Schwierigkeiten beim Login als angelegter FTP-User, als root hingegen keine Probleme beim einloggen.

Bearbeitet 5. August 2009 von red-polo

[Lacknase]

"System Preferences → Network → Use Passive FTP Mode (PASV)" sollte eingeschaltet sein. Einfach mal testweise aktivieren. Was ich noch vergessen habe: Betreibst Du einen Router? Falls ja: Ist der Ident-Port (113) offen?

Zur Server-Technik:

Als ich vom Quota sprach, meinte ich das System-Quota. Du kannst als ftp-Nutzer auch nicht mehr auf die Platte schieben als die selber noch als frei anbietet. Nur mal so als Beispiel. Und es wäre nicht das erste Mal, daß bei irgendeiner Wartung / Einrichtung / Umrüstung eine Null "vergessen" worden wäre. Wenn Du den nächsten root-Login schaffst, wäre deswegen die Beantwortung der Fragen nach der Systemauslastung sehr hilfreich.

Wenn Du im übrigen Login-Probleme auf dem vServer hast, spricht das (wenn der Ident-Port aktiviert ist) für Überbuchung oder Streß mit der Datenbankanbindung. Habe in den AGBs nichts gefunden, aber hast Du irgendwo so etwas wie eine Auslastungsbegrenzungsgarantie? Debian 3.1 läßt ja - wie Du mitteiltest - auf eine ältere Installation (auf älterer Hardware) schließen. Die mag, wenn die Kiste ordentlich rangenommen wird, mit dem 100. vServer-Paket nicht mehr klarkommen. (Was vielen Providern schlicht wurscht ist. Klar.)

[red-polo]

Zur Hardware... Mainframe auf dem die vServer laufen wurde zwischenzeitlich mehrfach aktualisiert, aktuell:

Auf deine Fragen (allerdings im "Leerlauf" ohne FTP-Upload):

nachdem ich ein bichen was abgeschnitten hab damit man den Server nicht lesen kann... hier die unvollständigen Angaben.

1876909 non-nice user cpu ticks

242417740 nice user cpu ticks

526121 system cpu ticks

1218848038 idle cpu ticks

248889 IO-wait cpu ticks

...

4294967295 CPU context switches

1216233288 boot time

865723079 forks

Interessant finde ich, dass wenn ich versuche mich per ssh als FTP-Client auf dem Server anmelden funzt das gar nicht. Da spuckt er mir nur die installierte Kernel-Variante als Antwort aus...

Eine Anmeldung über das Terminal per FTP funzt dagegen ohne Probleme.

EDIT: Ich sitz hier an nem Mac (OS X 10.5.7), die "anderen" an Dosen. Problem besteht Client-unabhängig und Plattformübergreifend. Vermute das Problem daher logischerweise beim Server.

Bearbeitet 5. August 2009 von red-polo

[Lacknase]

Kann sein. Muß aber nicht. Es ist ja (zumindest nach meiner Erfahrung) überwiegend so, daß heutzutage die Mehrheit der User mit total krasser "Automatischer Sicherheitseinstellung" am Router oder bei ZoneAlarm surft. Und da werden bisweilen sowohl ICMP-Pakete als auch Ident-Anfragen verworfen (DROP), so daß der Server, der auf Antwort wartet, in ein Timeout rennt. (Die korrekte Konfiguration nach RFC sähe vor, daß man schlicht mitteilt: Port Closed. Dann fragt und wartet niemand weiter.)

Zu den Daten: Die Rechenleistung an sich scheint zeitgemäß. Von der Gesamt-Speicherangabe der Kiste darf man sich aber nicht blenden lassen. Du hast für Deine Virtual Machine 512MB reserviert. Davon sind knapp 200 in Gebrauch. Dein Dateisystem ist zur Hälfte (4GB frei). Da darf dennoch für eine 10MB-Dateidatei nix klemmen.

Kannst Du denn via WebFrontend-FTP normal hochladen? Oder hakt es da auch? Und welche Server-Software/welcher ftpd ist denn da installiert? Kannst Du den denn auf shell-Ebene mit root-Login administrieren?

Bearbeitet 5. August 2009 von Lacknase

[red-polo]

Kannst Du denn via WebFrontend-FTP normal hochladen? Oder hakt es da auch?

--> k.A., bisher nicht probiert da einfach viel zu umständlich und unkomfortabel, bzw. unpraktikabel bei größeren Datenmengen

EDIT: Per webFTP scheint es zu funktionieren, er lädt nun seit etwa 5min hoch und LittleSnitch zeigt konstante Upload-Traffic an. Einen Hochladestatus beim WebFTP gibt es aber leider nicht und Firefox zeigt nur an "Senden der Anfrage an....".

EDIT2: NEIN, tut auch nicht!

Und welche Server-Software/welcher ftpd ist denn da installiert?

--> k.A.

Kannst Du den denn auf shell-Ebene mit root-Login administrieren?

--> Voller Root-Zugriff. Theoretisch also ja, praktisch aber nein, weil zu unbedarft/unwissend. Das ist halt immer das Problem wenn man als "Laie" solche Sachen anfängt...

Bearbeitet 6. August 2009 von red-polo

[Lacknase]

Wenn das WebFrontend funktioniert, liegt es nicht am FTP-Server-Dienst. (Möchte ich eh mal ganz dezent wetten.) Richte mir doch bitte mal nur zum Test einen ganz billigen, möglichst unpriviligeierten Zugang ein. Gerne auch Account mit Quota etc. Hauptsache ein Testupload von ca. 10MB ist möglich. PMe mir bitte diese Daten. Dann finde ich den gröbsten Rest raus.

Bearbeitet 6. August 2009 von Lacknase

[red-polo]

Tut auch nicht per Web FTP.

Was ich bisher ganz vergessen hatte zu erwähnen:

Direkt nach einem Server-Reboot funktioniert alles für ein paar Stunden ganz normal. Aber das kann's ja auch nicht sein, das ich vor jedem Upload den Server neu starten muss.

Bearbeitet 6. August 2009 von red-polo

[chevy69]

ich hatte so ein ähnliches Problem mal mit Emails.

versenden von "normalen" Emails mit ein paar kB ging ohne Probleme und grössere Sachen produzierten die seltsamsten Fehler.

habe dann entgegen jeglicher Vernunft die MTU Size geändert und seitdem - ich konnte es selbst nicht glauben - hat es funktioniert.

kannst ja mal bei deinem Provider fragen, was da der Sollwert wäre.

Tut auch nicht per Web FTP.

Was ich bisher ganz vergessen hatte zu erwähnen:

Direkt nach einem Server-Reboot funktioniert alles für ein paar Stunden ganz normal. Aber das kann's ja auch nicht sein, das ich vor jedem Upload den Server neu starten muss.