FFMPEG, Citrix i YetiShare

[Rolej 58]

Cześć.

 

Pytałem indywidualnie kilku osób tu na forum, zasięgnąłem pomocy w suporcie Yetishare oraz na tamtejszym forum - cisza.

 

Otóż kolega poprosił mnie bym mu postawił Yetishare (legalnie oczywiście) wraz z konwerterem filmów AVI, etc. --> MP4. Wszystko pięknie działa. Zwirtualizowałem mu to, zainstalowałem wszystko. Teraz jestem na fazie testów. Uploadując jakikolwiek film powyżej 400MB (od około godziny trwania wzwyż) to sama VMka dostaje już na starcie load 5.40 4.96 3.02 gdzie na samej "matce" to load jest w granicach 0.21 0.15 0.14. Osobiście rozkładam ręce - zmiana parametrów komendy FFMPEG w skrypcie PHP owszem pomogła, ale zbiła film do jakości nie tylko niezadowalającej ale wręcz odstraszającej (w dobie filmów 4K to wiadomo, 360p i niżej to patologia). O co może chodzić?

 

OS VM: Debian 8.2 + kernel 4.3.3 (gr + łatka od Archiego)

CPU: Intel E5-1620 4c/8t 3,6GHz (VMka ma 4VCPU)

RAM: 64GB (VM: 4GB)

Dysk: 2XHGST SATA

Wirtualizacja: Citrix XenServer

[Gość Kamikadze]

A nie ograniczyłeś zbytnio VMki? Sprawdź ile ona ma rzeczywiście CPU.

[Rolej 58]

@Kamikadze

 

przemek@web01:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
stepping        : 7
microcode       : 0x710
cpu MHz         : 3600.146
cache size      : 10240 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 1
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm
bugs            :
bogomips        : 7200.29
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
stepping        : 7
microcode       : 0x710
cpu MHz         : 3600.146
cache size      : 10240 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 1
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm
bugs            :
bogomips        : 7200.29
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
stepping        : 7
microcode       : 0x710
cpu MHz         : 3600.146
cache size      : 10240 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 1
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm
bugs            :
bogomips        : 7200.29
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
stepping        : 7
microcode       : 0x710
cpu MHz         : 3600.146
cache size      : 10240 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 1
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm ida arat epb pln pts dtherm
bugs            :
bogomips        : 7200.29
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

 

 

W rzeczy samej - 4.

[Gość Kamikadze]

A mają po 100% tego CPU?

 

 

http://support.citrix.com/article/CTX117960

[Rolej 58]

No to tak:

 

xe vm-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx VCPUs-params:mask=3
xe vm-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx VCPUs-params:cap=100
xe vm-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx VCPUs-params:weight=512

Po wklepaniu tego zauważyłem znaczne zmniejszenie loadu i obciążenia procesora na VM (jeden sukces), jednak to nie pomogło w przypadku skrócenia pracy FFMPEG. Co byście w tym jeszcze zmienili? A może macie jakieś inne pomysły co do tego?

[Misiek08 285]

Inny preset, kombinowanie z wartościami ustawiającymi ilość wątków (nie zawsze n, czy n-1 gdzie n to liczba wątków procesora jest najlepsza w wirtualnych środowiskach). Jeżeli load jest ok, to znaczy że kwestia samego ffmpeg już. Sam load też ilością wątków obniżysz, ale wtedy czas idzie w górę.

[Rolej 58]

Preset zmieniałem. Przyśpieszając, owszem robiło to szybko ale jakość była jeszcze gorsza. Na forum yetishara sugerowali mi kupno chmury obliczeniowej. Aż tak trzeba na ten problem spoglądać, że trzeba chmurę mu kupić?

Edytowano Styczeń 15, 2016 przez Rolej (zobacz historię edycji)

[Misiek08 285]

Encoding i transcoding trwa i zabiera dużo zasobów. Jeżeli zależy Ci na jakości, a formaty są tak "odległe" to niestety wymaga to mocy.

 

Jedyne co mnie dziwi to wywoływanie ffmpeg'a z PHP. Jeżeli to jest bezpośrednie wywołanie po uploadzie to jednak jest to zrobione słabo, bo powinna być kolejka, którą zajmuje się w najgorszym wypadku skrypt w cron'ie.

 

Co do kupowania chmury - oczywiście, że byłoby świetnie skalować sobie w jakiejś chmurce instancje pod aktualny ruch i obrabiać kolejkę większą mocą, ale procesor, który masz już też jest całkiem ok i powinien sobie radzić. Nie daj się tylko namówić na usługi Amazona, bo każdy tam pakuje, a potem płacze, że to wszystko kosztuje. Niestety cennik x10 mają na wszystko.

 

btw. Ciekawe czy byliby chętni na usługi takie jak Amazona (wszystkie API/usługi z kompatybilnym API), ale nie Amazona i znacznie tańsze

[Kszysiu 136]

xe vm-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx VCPUs-params:cap=100

Właśnie ograniczyłeś wydajność procesora do jednego rdzenia/wątka procesora fizycznego;)

Ustaw 400, a najlepiej usuń ten parametr.

 

Pokaż najlepiej `xe vm-param-list uuid=blablabla` to może coś podpowiem... Jaki SR? thin provisionowany w plikach czy LVM?

 

Nie będziesz widział load'u generowanego przez vm'kę w dom0 - system hosta w xenie też jest wirtualką, do tego o ograniczonych parametrach (kilkaset MB ram, i pewnie 4vcore)

 

Która wersja Xenservera?

[Insider 43]

btw. Ciekawe czy byliby chętni na usługi takie jak Amazona (wszystkie API/usługi z kompatybilnym API), ale nie Amazona i znacznie tańsze

 

Byś zaczął działać, a nie tylko snujesz plany.

[bybunny 540]

btw. Ciekawe czy byliby chętni na usługi takie jak Amazona (wszystkie API/usługi z kompatybilnym API), ale nie Amazona i znacznie tańsze

 

Chętni zawsze są jak coś jest tańsze. Powiem nawet więcej tańsze nie znaczy gorsze ale idąc dalej by było lepsze nie znaczy że trafi do wszystkich. Jest dużo firm które posiadają potężne zasoby ale dostęp do nich jest ograniczony przez rozsądek.

 

Edytowano Styczeń 27, 2016 przez SiXwishlist (zobacz historię edycji)