Probleme mit FFmpeg / PHP/ 70 Load / iowait

bombaldi

New Member
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 für jede Antwort ;)
 
Last edited by a moderator:
Kann es ganz einfach sein, daß du zu wenig CPU Leistung hast? Das Umrechnen von Videos stelle ich mir nicht ganz so einfach und schnell vor.
 
Nene....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....
Habe ja schon mit nice eine niedrigere Prioritaet fuer die FFMPEG prozesse vorgegeben, allerdings hilft das dem Apache nicht...

Freue mich nach wie vor ueber jede Antwort
 
Last edited by a moderator:
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....
Habe ja schon mit nice eine niedrigere Prioritaet fuer die FFMPEG prozesse vorgegeben, allerdings hilft das dem Apache nicht...

Freue mich nach wie vor ueber jede Antwort

Ich sehe das Problem, daß ihr die ganzen ffmpeg Aufrufe synchron macht, d.h. jeder Request, der ffmpeg aufruft, wartet, bis der ffmpeg fertiggerechnet hat.

Daß ganze hat ein paar Nachteile:
  • Jeder Aufruf blockiert einen Apache Prozess/Threads. Viele Aufrufe blockieren viele Apache Prozesse/Threads, die dann halt nix anderes tun als warten.
  • Du kannst keine Obergrenze für eine maximale Anzahl an parallelen ffmpeg Instanzen definieren.
  • Dir kann irgendwann der Speicher ausgehen (zuviele ffmpegs)

Ein Vorschlag: Bau deine Anwendung so um, daß die Umrechnung im Hintergrund stattfindet. Der Apache-Request stellt einen Auftrag in eine Queue, die von einem Hintergrund-Prozess überwacht wird, der auch dann die ffmpeg-Instanzen passend startet.
 
Back
Top