Upload frisst RAM auf

M

Mario1981

New Member
Hallo

ich bin es wieder :p

Ich hab folgendes Problem. Habe ein Forum (wbb) auf meinem Vserver und es läuft auch alles soweit.

Wenn ich im Forum nun eine grosse Datei hochladen will, steigt Stück für Stück der RAM an bis auf ca 780mb.
Nach dem das erreicht ist bekomme ich im Browser die Meldung "Verbindung wurde zurückgesetzt" und der Upload ist fehlgeschlagen.Hab mal Testweise eine kleine Datei versucht da geht es aber auch da steigt der RAM Stück für Stück.

Ich hab 786mb Gesamt Ram auf dem VServer.

In der php.ini hab ich alles eingestellt also daran dürfte es nicht liegen.

Ich kann mir nicht erklären warum das so ist.

Gibt es vielleicht eine Lösung dafür??

Wäre für jede Hilfe dankbar

Gruss
Mario
 
Last edited by a moderator:
Steigt der RAM oder steigt die Summe aus Cache, Buffer und RAM?
Code: 
free -m | grep "total\|+
Hast du einen Dienst dazwischen? ClamAV z.B. (Wird z.B. gerne von Suhosin genutzt)?
 
Wenn ich free -m | grep "total\|+ eingebe passiert nichts?

Ihr mal mit top

Zustand normal

top

Code: 
top - 18:14:16 up 3 days, 41 min,  1 user,  load average: 0.00, 0.01, 0.01
Tasks:  45 total,   2 running,  43 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    786432k total,   262664k used,   523768k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      15   0  1980  692  596 S    0  0.1   0:00.41 init
 1408 root      15   0  1692  620  492 S    0  0.1   0:00.85 syslogd
 3493 root      18   0  8616 2076  936 S    0  0.3   0:00.33 sendmail-mta
 3513 root      25   0  1832  432  352 S    0  0.1   0:00.00 courierlogger
 3514 root      18   0  2048  644  520 S    0  0.1   0:00.00 authdaemond
 3522 root      18   0  1832  436  352 S    0  0.1   0:00.00 courierlogger
 3523 root      15   0  1936  604  520 S    0  0.1   0:00.01 couriertcpd
 3528 root      18   0  1832  432  352 S    0  0.1   0:00.00 courierlogger
 3529 root      15   0  1936  604  520 S    0  0.1   0:00.00 couriertcpd
 3530 root      15   0  2052  580  320 S    0  0.1   0:00.00 authdaemond
 3531 root      15   0  2052  580  320 S    0  0.1   0:00.01 authdaemond
 3532 root      15   0  2268  864  568 S    0  0.1   0:00.03 authdaemond
 3534 root      15   0  2268  864  568 S    0  0.1   0:00.00 authdaemond
 3536 root      15   0  2268  880  584 S    0  0.1   0:00.03 authdaemond
 3657 root      15   0  2256 1100  880 R    0  0.1   0:00.14 top
 3738 polw      18   0  7852 5552 1256 S    0  0.7   0:00.04 policyd-weight
 3744 polw      15   0  7720 5208  920 S    0  0.7   0:00.05 policyd-weight
 5153 postgrey  18   0 11156 8068 2592 S    0  1.0   0:00.02 postgrey
 5912 www-data  15   0 14568 3044 1168 S    0  0.4   0:00.00 apache2
 7688 nobody    15   0  7832 1800  660 S    0  0.2   0:00.40 proftpd
 7960 www-data  18   0 14708 3272 1348 S    0  0.4   0:00.00 apache2
 9908 root      15   0  8016 2620 2164 S    0  0.3   0:00.03 sshd
10112 vu2000    18   0 44028 8092 5316 S    0  1.0   0:00.09 php5-cgi
10147 vu2000    17   0 44996 9488 5360 S    0  1.2   0:00.17 php5-cgi
10148 vu2000    15   0 44988 8552 4556 S    0  1.1   0:00.01 php5-cgi
11576 mario     15   0  8164 1540 1068 R    0  0.2   0:00.01 sshd
11591 mario     16   0  3280 1792 1212 S    0  0.2   0:00.00 bash
11820 root      16   0  2380 1096  864 S    0  0.1   0:00.00 su
12193 root      16   0  2788 1512 1176 S    0  0.2   0:00.00 bash
14173 root      18   0  1628  432  360 S    0  0.1   0:00.00 ispcp_daemon
16215 root      18   0  2484 1160  964 S    0  0.1   0:00.01 mysqld_safe
16258 mysql     15   0  131m  24m 5356 S    0  3.2   0:15.19 mysqld
16259 root      19   0  1628  532  460 S    0  0.1   0:00.00 logger
19471 root      18   0 12744 9264 2224 S    0  1.2   0:00.18 ispcp-apache-lo
19472 root      18   0 12748 9276 2224 S    0  1.2   0:00.22 ispcp-apache-lo
19473 www-data  18   0 14064 2404  600 S    0  0.3   0:00.05 apache2
20126 root      18   0  2036  888  704 S    0  0.1   0:00.24 cron
20259 root      15   0  5272 1040  684 S    0  0.1   0:00.00 sshd
28464 polw      15   0  7848 5228  928 S    0  0.7   0:00.03 policyd-weight
30194 root      18   0  4132 1276  972 S    0  0.2   0:02.94 ntpd
32214 root      24   0  2352  872  704 S    0  0.1   0:00.00 xinetd
32645 root      18   0 14568 4696 2880 S    0  0.6   0:00.62 apache2
32687 vu2001    18   0 44028 8092 5316 S    0  1.0   0:00.11 php5-cgi

Und hier der Zustand wenn der Upload läuft oder besser gesagt der RAM aufgebraucht ist. Dateigrösse 167mb die geladen wird

top

Code: 
top - 18:32:03 up 3 days, 59 min,  1 user,  load average: 0.05, 0.07, 0.02
Tasks:  46 total,   1 running,  45 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    786432k total,   783156k used,     3276k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25825 www-data  15   0  520m 357m 1356 S    0 46.6   0:01.52 apache2
    1 root      15   0  1980  692  596 S    0  0.1   0:00.41 init
 1393 www-data  15   0 14868 3548 1344 S    0  0.5   0:00.01 apache2
 1408 root      15   0  1692  620  492 S    0  0.1   0:00.85 syslogd
 3493 root      18   0  8616 2076  936 S    0  0.3   0:00.33 sendmail-mta
 3513 root      25   0  1832  432  352 S    0  0.1   0:00.00 courierlogger
 3514 root      18   0  2048  644  520 S    0  0.1   0:00.00 authdaemond
 3522 root      18   0  1832  436  352 S    0  0.1   0:00.00 courierlogger
 3523 root      15   0  1936  604  520 S    0  0.1   0:00.01 couriertcpd
 3528 root      18   0  1832  432  352 S    0  0.1   0:00.00 courierlogger
 3529 root      15   0  1936  604  520 S    0  0.1   0:00.00 couriertcpd
 3530 root      15   0  2052  580  320 S    0  0.1   0:00.00 authdaemond
 3531 root      15   0  2052  580  320 S    0  0.1   0:00.01 authdaemond
 3532 root      15   0  2268  864  568 S    0  0.1   0:00.03 authdaemond
 3534 root      15   0  2268  864  568 S    0  0.1   0:00.00 authdaemond
 3536 root      15   0  2268  880  584 S    0  0.1   0:00.03 authdaemond
 3738 polw      18   0  7852 5552 1256 S    0  0.7   0:00.04 policyd-weight
 3744 polw      15   0  7720 5208  920 S    0  0.7   0:00.05 policyd-weight
 5153 postgrey  18   0 11156 8068 2592 S    0  1.0   0:00.02 postgrey
 7688 nobody    15   0  7832 1800  660 S    0  0.2   0:00.40 proftpd
 9908 root      15   0  8016 2620 2164 S    0  0.3   0:00.03 sshd
10112 vu2000    18   0 44028 8092 5316 S    0  1.0   0:00.09 php5-cgi
10147 vu2000    17   0 44996 9488 5360 S    0  1.2   0:00.17 php5-cgi
10148 vu2000    15   0 44988 8552 4556 S    0  1.1   0:00.01 php5-cgi
11576 mario     18   0  8164 1544 1068 S    0  0.2   0:00.18 sshd
11591 mario     16   0  3280 1792 1212 S    0  0.2   0:00.00 bash
11820 root      16   0  2380 1096  864 S    0  0.1   0:00.00 su
12193 root      15   0  2788 1516 1176 S    0  0.2   0:00.00 bash
14173 root      18   0  1628  432  360 S    0  0.1   0:00.00 ispcp_daemon
16215 root      18   0  2484 1160  964 S    0  0.1   0:00.01 mysqld_safe
16258 mysql     15   0  131m  24m 5356 S    0  3.2   0:15.32 mysqld
16259 root      19   0  1628  532  460 S    0  0.1   0:00.00 logger
19471 root      18   0 12744 9264 2224 S    0  1.2   0:00.18 ispcp-apache-lo
19472 root      18   0 12748 9276 2224 S    0  1.2   0:00.26 ispcp-apache-lo
19473 www-data  15   0 14064 2404  600 S    0  0.3   0:00.05 apache2
20126 root      16   0  2036  888  704 S    0  0.1   0:00.24 cron
20259 root      15   0  5272 1040  684 S    0  0.1   0:00.00 sshd
21906 www-data  15   0 14840 3504 1360 S    0  0.4   0:00.00 apache2
28464 polw      15   0  7848 5228  928 S    0  0.7   0:00.03 policyd-weight
30194 root      18   0  4132 1276  972 S    0  0.2   0:02.95 ntpd
32214 root      24   0  2352  872  704 S    0  0.1   0:00.00 xinetd
32326 root      15   0  2256 1100  876 R    0  0.1   0:01.04 top
32645 root      18   0 14568 4696 2880 S    0  0.6   0:00.64 apache2

ein Apache Prozess wird immer grösser. Danach ist alles wieder normal, Seite ist erreichbar usw. als wäre nie was gewesen. Er swappt nicht usw.

Wie gesagt kleine Dateien gehen, so um die 40mb, bei 80mb geht nichts mehr.

Keine Ahnung wieso das so ist
 
Last edited by a moderator:
Hallo!
Mario1981 said:
In der php.ini hab ich alles eingestellt also daran dürfte es nicht liegen.
Click to expand...
Ein Kollege würde sagen: Bist du da sicher? Welche Einstellungen sind denn das genau?
Mario1981 said:
Gibt es vielleicht eine Lösung dafür??
Click to expand...
Da du die Dateien via PHP Script hochlädts vernute ich, die Lösung könnte im Apache Logfile / Errorlog zu finden sein.

Noch etwas: Es klingt so, als wäre es ein außergewöhnlicher Umstand, dass dein Server bei einem Upload RAM verbraucht. Was glaubst du, wo die Daten zwischengespeichert werden?

mfG
Thorsten
 
Also Einstellungen in der php.ini sind

max_execution_time = 240
memory_limit = 128M
post_max_size = 500M
upload_max_filesize = 500M

Wie gesagt bei kleinen Dateien 40mb rum geht es ja.

Also in den Logs (apache error.log) steht nichts drin, zumindest für denn heutigen Tag und wir haben heute schon 2 mal was versucht hochzuladen.

Ist ja richtig das die Datei irgendwo zwischengespeichert werden müssen aber nehmen wir mal folgendes Beispiel:

Ich lade eine Datei (80mb) hoch und ich hab einen RAM Verbrauch von ca. 550mb. Die Datei ist aber noch nicht fertig hochgeladen, also wer weiß wieviel er insgesamt verbraucht.

Jetzt nehmen wir mal eine Datei (1gb), jetzt müsste ja der RAM Verbrauch ins unermessliche steigen. Bei 1gb wären das ja grob geschätzt mehr als 6gb RAM was ja nun wirklich enorm ist.

Also irgendwo kann ich mir nicht vorstellen das ein Upload von ca. 80mb so ein Haufen RAM frisst. Logisch wären ja wenn er 80mb Ram verbraucht für denn Upload.
 
Last edited by a moderator:
Also, zunächst zum Upload selbst:
Wie Thorsten schon andeutete, wir der Upload in Häppchen in einem Temp-FS gecached, der direkt im Hauptspeicher sitzt. Da der Arbeitsspeicher bekanntlich aus RAM und Swap besteht, werden diese vollgeladen, wobei natürlich der RAM präferiert wird.
Eigentlich sollte aber der Swap, sofern vorhanden, einspringen, sobald der RAM zu Neige geht.
Falls RAM und ggf. Swap voll sind, kann schlicht nicht mehr Speicher zugewiesen werden. Das mag eine Designschwäche sein, ist aber so.

Nun zum Upload mittels HTTP:
Dies ist schlicht ein No-Go für größere Dateien. Das HTTP ist dafür nicht geschaffen und sollte nur für kleinere Dateien verwendet werden. Ein Missbrauch für riesige Dateien wie hier kann nur schiefgehen, da der Overhead des Requests einfach völlig überdimensioniert ist. Es wird tatsächlich mehr Speicher für den Overhead verbraten als für die Datei selbst.
Ein Upload einer Gigabytes großen Datei benötigt also mehr Arbeitsspeicher, als gängige Server überhaupt haben.

Fazit:
Bei 1gb wären das ja grob geschätzt mehr als 6gb RAM was ja nun wirklich enorm ist.
Click to expand...
Klingt viel, ist aber so. Das HTTP ist für solche Dateien nicht ausgelegt und der Missbruach rächt sich hier.
Logisch wären ja wenn er 80mb Ram verbraucht für denn Upload.
Click to expand...
Für so eine Aussage müsste man überhaupt erst einmal verstehen, was das HTTP z.B. im Gegensatz zum FTP überhaupt tut. Aufgrund des enorm größeren Overheads ist diese Milchbubenrechnung nämlich alles andere als angemessen.


Steige lieber auf FTP um. Es gibt auch Scripts, die eine FTP-Session initiieren können. Ob nun mit Java oder Flash, da gibt es viele Mittel und Wege. HTTP ist und bleibt ein HyperText-Transport-Protokoll, nicht umsonst wurde das File-Transport-Protokoll geschaffen.
 
Das Problem ist das im Forum eine Datenbank integriert ist wo Benutzer Sachen hochladen können.

Ich hatte vorher einen Webserver da ging es, danach hab ich mir denn Platz mit jemanden geteilt der einen eigenen Server hatte auch da ging es.

Ich möchte ja nicht 1gb hochladen, max 200mb wenn überhaupt.

Also kann ich das mit dem hochladen vergessen??

Kann mir nicht vorstellen das jetzt auf einmal nicht mehr funktioniert
 
Naja, wenn man 1,5GB zur Verfügung hat und/oder Swap, ist das auch relativ problemlos möglich.
Aber auf einem 786MB-RAM-Server ohne Swap sieht das Ganze ein wenig magerer aus.
Aber mal im Ernst: Warum sollten User per HTTP 200MB hochladen können?
Und was ist das für eine Datenbank? Soweit ich weiß, sind Datenbanken doch eher Texte. Und 200MB Text sind selbst unkomprimiert schon Bücherreihen, Komprimiert ganze Bibliotheken.
 
Also ich hab ein Woltlab Burning Board und dazu gibt es die Webdisk von wbb-security.de

Naja Swap nutzt er ja nicht also fällt das ja weg.

Also gibt es keine Lösung dafür ausser dem RAM zu erhöhen.
 
Ich habe keine Ahnung, was dieses Webdisk sein soll.
Aber klar gibt es Lösungen:

a) Fast alle Kompressionsformate unterstützen geteilte Archive. 200MB lassen sich prima in 10 Häppchen á 20MB aufteilen.
b) Ein Workaround ist recht einfach realisierbar. Dazu müsste lediglich ein FTPd wie proftpd auf die DB umgestellt werden, in der die Benutzer für dein Webdisk-System eingetragen sind. Ich habe so etwas ähnliches im Einsatz.
c) Es gibt genug andere Möglichkeiten als einen einfachen HTTP-Upload. Google einfach mal nach "Flash-Upload" oder "Java-Upload".

Nochmal: Es macht wirklich absolut keinen Sinn, große Datenmengen per HTTP zu uploaden. Es ist nicht nur irrsinnig langsam (FTP ist ca. 10x schneller), es frisst auch wertvolle Ressourcen wie Traffic und, wie du ja mbemerktest, auch RAM.

Bevor ich an irgendwelche Upgrades am Server nachdenken würde, würde ich mir erstmal gründlich Gedanken über das Konzept machen. Denn HTTP-Uploads mit mehr als 20MB sind -sorry dafür- einfach Schwachsinn. ;)
 
Ok werd mal schauen wie ich das am besten lösen werde.

Am besten gar kein Upload :D

Ok ich danke erstmal, vielleicht kann der Ersteller der Webdiks mir noch was sagen.

Werd erstmal so weiter machen, gibt genug zu tun :D
 
You must log in or register to reply here.
Back
Top