Probleme mit FFmpeg / PHP/ 70 Load / iowait

bombaldi

bombaldi

Grünschnabel
Hallo liebe Community,

Wir haben ein kleines Problem mit unserem Debian Server und braeuchten dringend einen Ratschlag :)

Ich fang einfach mal an:
Auf unserem Server laeuft ein 'Konvertierungsdienst', der user hat die moeglichkeit ein video in einem beliebigen Format hochzuladen und unser
Dienst wandelt das ganze dann in ein anderes Format um.
Realisiert wird das ganze mittels php welches dann ffmpeg als syscall aufruft.


Eines der Probleme ist im Grunde die extrem hohe Last die dabei verursacht wird.

Hier ein kleiner Auszug:

top - 00:52:27 up 5 days, 4:20, 2 users, load average: 55.95, 62.50, 67.76
Tasks: 392 total, 23 running, 369 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.7%us, 0.6%sy, 97.3%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23126 www-data 23 3 15632 8048 1236 R 19 0.4 1:21.91 ffmpeg
26995 www-data 23 3 14020 6932 1412 R 19 0.3 0:14.70 ffmpeg
27587 www-data 23 3 14004 6884 1412 R 19 0.3 0:04.39 ffmpeg
27733 www-data 23 3 14000 6928 1412 R 19 0.3 0:02.11 ffmpeg
27756 www-data 23 3 14848 7464 1240 R 19 0.4 0:01.01 ffmpeg
27110 www-data 23 3 15020 7552 1240 R 17 0.4 0:08.91 ffmpeg
27538 www-data 23 3 14020 6876 1412 R 17 0.3 0:03.49 ffmpeg
24740 www-data 23 0 15008 7572 1240 R 11 0.4 0:46.81 ffmpeg

Jedenfalls ist der Apache momentan nur noch ganz schlecht zu erreichen (trotz priority handling mit nice)
Irgendwas bringt das Scoreboard auf lauter Waiting Eintraege:

Total accesses: 389300 - Total Traffic: 12.7 GB
CPU Usage: u486.39 s236.38 cu18438.5 cs0 - 79.1% CPU load
16.1 requests/sec - 0.5 MB/second - 34.3 kB/request
62 requests currently being processed, 63 idle workers

__W_W__WW_WW__WWW_W_W_WW_.......................................
_______W__W_WWW_WK______W.......................................
_WK___WW_K_WW_C__KWWK___W.......................................
................................................................

0-0 2967 4/1631/2467 W 4992.43 13144 0 6.2 43.60 67.91 84.58.191.105 my.hostname GET /convert.php?status=convert&cid=f55f412f45 HTTP/1.1
0-0 2967 7/901/1997 W 3483.69 15427 0 0.3 44.95 65.03 87.123.146.148 my.hostname GET /convert.php?status=convert&cid=ab69dc156a HTTP/1.1
0-0 2967 0/3350/4113 _ 7484.53 331 0 0.0 83.91 98.49 64.107.105.173 my.hostname GET /favicon.ico HTTP/1.1
0-0 2967 1/533/1097 W 808.54 19290 0 6.0 11.30 21.59 88.72.241.95 my.hostname GET /convert.php?status=download HTTP/1.1
0-0 2967 2/981/1882 W 1817.84 17982 0 6.7 22.33 29.04 84.62.202.204 my.hostname GET /convert.php?status=convert&cid=7710140f9e HTTP/1.1
0-0 2967 0/2548/3525 _ 7484.47 345 0 0.0 66.53 90.97 71.198.255.254 my.hostname GET /image/footer.png HTTP/1.1
0-0 2967 0/2878/3571 _ 7484.73 200 65 0.0 80.36 88.89 74.125.16.6 my.hostname GET / HTTP/1.1
0-0 2967 2/1215/2465 W 5553.09 11955 0 6.1 49.54 95.74 84.176.243.36 my.hostname GET /convert.php?status=convert&cid=8799296cf2 HTTP/1.1
Gibt es neben mod_status noch irgendwelche detailiertere Moeglichkeiten solche Fehler schnell zu finden?

Im error log finde ich auch jede Menge von diesen Eintraegen:
[Thu Jul 03 23:00:17 2008] [info] [client 91.0.xxx] (104)Connection reset by peer: core_output_filter: writing data to the network
[Thu Jul 03 23:00:17 2008] [info] [client 84.128.xxx] (32)Broken pipe: core_output_filter: writing data to the network
[Thu Jul 03 23:00:26 2008] [info] [client 93.135.xxx] (104)Connection reset by peer: core_output_filter: writing data to the network
[Thu Jul 03 23:00:26 2008] [info] [client 93.135.xxx] (32)Broken pipe: core_output_filter: writing data to the network
[Thu Jul 03 23:00:27 2008] [info] [client 84.162.xxx] (104)Connection reset by peer: core_output_filter: writing data to the network
[Thu Jul 03 23:00:55 2008] [info] [client 78.48.xxx] (104)Connection reset by peer: core_output_filter: writing data to the network
Laut mehrfachem Googlen stellte sich heraus dass dass bei den anderen immer mit fehlerhaften (vhost)Settings in der Config zu tun hat..ich denke aber das ist bei uns nicht der Fall, der Fehler tritt selbst bei einer unveraenderten Apache config auf bzw bei einer "frischen" apache config.
Und nein, es liegt auch nicht an dem EnableSendfile = OFF wie in der apache doku beschrieben. Den Fehler habe ich auch schon oefters auf meinen anderen beiden Servern gesehen wo vollkommen andere Sachen laufen, mir ist aber nach wie vor unklar wie man das nun deuten soll.


Also vermutlich liegt es wohl eher am Script, bzw an der Art wie PHP ffmpeg aufruft.

Das script ruft über "proc_open()" das Konvertierungskommando auf.
Wer diese Funktion kennt weiß das sie über 2 Pipes den Output der Funktion wieder gibt.
Über die Funktion "fread()" lesen wir dann also diese Pipes aus.
Danach parsed nur noch ein Regex die notwendigen Daten raus und die Arbeit ist getan.
Über eine While schleife wird das ganze dann wiederholt.
Um den Status nun aber auch an den User zu geben verwende ich "file_put_contents()".
Mit dieser Funktion erstelle ich eine XML-Datei mit den Daten die der User dann sehen soll.
Diese Daten werden dann anschließen über Ajax ausgelesen.

Beim Convertscript öffne ich dabei den FFmpeg Prozess mit „proc_open()“ und lese dann den Status aus.
Das ganze geschieht mit proc_open() weil wir eine Progressbar eingebaut haben die dem user anzeigt : 'x % fertig'

Wir sind uns natuerlich nicht sicher ob dieser Weg so so intelligent ist...ich wuerde mich ueber Verbesserungsvorschlaege natuerlich freuen.


Danke ;)
 
Mal ganz dumm nachgefragt:

Seid ihr sicher, dass der Server auch >5 Videos gleichzeitig konvertieren kann?
Habt ihr das mal getestet?

Ich kann mir sehr gut vorstellen, dass der CPU/Platte einfach die Puste ausgeht, bei so vielen gleichzeitigen Aufgaben...

Gruß
 
Darum gehts doch ueberhaupt nicht :( Die CPU laeuft einfach auf Vollast, das ist bei 2 ffmpeg prozessen schon der FAll, und das wird auch bei 200 so sein.
Wir haben schon nen Quadcore, hätten wir 4 quadcore's würden die auch alle ständig 100% Cpu Load verursachen

Die Festplatte ist schnell genug, sonst waere die cpu auf %wa (afaik)


Unsere Frage bezieht sich auf die art wie wir ffmpeg aufrufen, und warum die Apache prozesse auf W stehen.
Es wird doch wohl irgendwie moeglich sein das ganze vernuenftig zu "throttlen" / limiten, so dass der Apache trotz 100% CPU Load halbwegs erreichbar ist und nicht alle Prozesse auf W stehen....

Freue mich nach wie vor ueber jede Antwort ;)
 
Ihr könntet die Konvertierung im Hintergrund in einer Warteschlange machen. Ist mit php aber nicht so einfach.
 
Code:
Das script ruft über "proc_open()" das Konvertierungskommando auf.
Wer diese Funktion kennt weiß das sie über 2 Pipes den Output der Funktion wieder gibt.
Über die Funktion "fread()" lesen wir dann also diese Pipes aus.

Könnte das nicht mit Hilfe eines fifo realisiert werden?

Schon versucht, den ffmeg-proz. zu nicen?
 
saeckereier: Das haben wir nun als naechstes vor, aber es waere aus der sicht des Users schoener das ganze ohne sheduling / queue zu betreiben.

Aqualung: ja ;) bringt nichts, da die Apache prozesse auf W stehen, ich muss erstmal rausfinden warum
oben schrieb:
Jedenfalls ist der Apache momentan nur noch ganz schlecht zu erreichen (trotz priority handling mit nice)
Kannst du uns mal erklaeren wie du das mit fifo meinst?
 
FIFO - First in First out
Also im Prinzip das Warteschlangenmodell. Würde ich auch so machen. Die Files in ein Verzeichnis hochladen lassen und solange da was drin ist FFmpeg mit nem Cronjob oder besser mit nem Perl Skript ausführen lassen. Die FFmpg Prozesse würde ich auf alle Fälle vom Serverbetrieb abkoppeln. Die Aufgabe von nem Webserver besteht IMHO ja nicht darin Videos zu encoden sondern Content auszuliefern und Skripte zu verarbeiten.
Aus Sicht des Users ist es glaub ich ziemlich egal ob er lange auf sein encodiertes Video warten muss, weil gleichzeitig x FFmpeg Prozesse laufen oder ob er lange drauf wartet, weil sein File in ner Queue ist. Solange die Rechenkapazität voll ausgelastet ist nehmen sich beide Methoden denke ich nicht viel weg. Eher ist schlechter alles gleichzeitig zu machen, weil Prozesswechsel auch immer Zeit kostet.

Wichtig scheint mir auch die Encodierung nicht unbedingt mit PHP zu machen, weil hier oft sehr schnell die maximalen Ausführzeiten von PHP Skripten erreicht werden. (Bitte keinen Vorwurf machen wenns nicht stimmt)
 
Zuletzt bearbeitet:
ich weiß ja nicht wie der server aussieht .. aber ich hatte mal was ähnliches bei einem webserver. die mysql datenbank hat den server zum kochen gebracht, sobald ein cronjob lief.

das problem: die lüster waren total dreckig .. deswegen wurde die cpu zu heiß und hat sich deshalb runtergetaktet. könnte das hier auch so sein?

und vllt postest du mal den relevanten php-code .. vllt ist dort ja der fehler.
 
Zuletzt bearbeitet:
Du kannst 3792572395623523652394723956325230 Quadcores mit 397753256923569259235ghz haben...

die Konvertierung von Filmen wird _immer_ 100% beanspruchen... ob 1 film oder 10 gleichzeitig.

Es wird immer, egal bei welcher CPU und wie viele usw 100% beansprucht da dann das konvertieren schneller geht.

Deswegen gibt es bei den meisten Programmen zu Konvertierung die Möglichkeit die Prozess Prioritäten zu ändern. Ob hintergrund, vordergrund, langsam, schnell usw usf. (ok das hast ja schon versucht).

Dann gibt es noch möglichkeiten generell Programme mit XY Mhz laufen zu lassen. Dazu solltest du googeln.

Deswegen solltest du dich damit erst beschäftigen :)
 
Zuletzt bearbeitet von einem Moderator:

Ähnliche Themen

Rollei Mini Wifi Camcorder

NagiosGrapher 1.7.1 funktioniert nicht

Festplatte stirbt, dd funktioniert nicht

Festplatte friert ein nach suspend/resume

Ubuntu X / dbus problem

Zurück
Oben