NGINX Servindo arquivos mp4 grandes de maneira extremamente ineficiente

Question

Atualmente, estou executando o nginx / 1.0.15 em um sistema operacional Centos 6.6. O servidor tem as seguintes especificações:

• CPU Intel (R) Atom (TM) C2750 @ 2.40GHz (8 núcleos)
• Ram de 32 GB
• 5 x 6000 GB 7200 RPM (Raid 10)

O problema

O servidor tem uma conexão de 1Gbit / s, no entanto, ele alcança gargalos após 400-500 mbit / s. O serviço começa a diminuir em aproximadamente 100 conexões .. e a velocidade com o servidor cai drasticamente (apesar de ter 50% de largura de banda ainda disponível)

O servidor NGINX é estritamente para servir arquivos .mp4 estáticos. Cada arquivo é tipicamente 400-1200MB (sendo 700MB a média)

Eu tentei muitas configurações e quase todas elas me deram os mesmos resultados. Estou extremamente frustrado ..

A carga do servidor também nunca passa de 0,3.

Existe alguma coisa descaradamente errada ou errada na minha configuração? Qualquer coisa pode ajudar.

As configurações

/etc/nginx/nginx.conf

user              nginx;
worker_processes  9;

error_log  /var/log/nginx/error.log;


pid        /var/run/nginx.pid;


events {
    worker_connections  51200;
    use epoll;
 }

worker_rlimit_nofile 600000;

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

#access_log  /var/log/nginx/access.log  main;
access_log off;

aio on;
sendfile        off;
tcp_nopush      off;
tcp_nodelay      on;

#keepalive_timeout  0;
keepalive_timeout  65;

output_buffers 1 3m;
#gzip  on;

include /etc/nginx/conf.d/*.conf;

open_file_cache          max=10000 inactive=5m;
open_file_cache_valid    2m;
open_file_cache_min_uses 1;
open_file_cache_errors   on;

}

/etc/nginx/conf.d/default.conf

server {
    listen       80 default_server sndbuf=32k;
    server_name  _;

    #charset koi8-r;

    #access_log  logs/host.access.log  main;

    include /etc/nginx/default.d/*.conf;


    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location /Videos/ {
        root /home;
        gzip off;
        gzip_static off;

        mp4;
        mp4_max_buffer_size   300m;
    }

    location /stats {
        stub_status on;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /usr/share/nginx/html;
    }


    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

    

Answer 1

O melhor começo pode ser o conjunto de regras a seguir:

1. desabilite o registro em log e aceite_mutex
2. ativar o sendfile
3. definir sendfile_max_chunk

Configuração:

events {
    accept_mutex off;
}

access_log off;
sendfile on;
sendfile_max_chunk 512k;

O novo conjunto de threads de recursos do Nginx (1.7.11 ou mais recente) pode ser realmente útil no seu caso:

location / {
    root /home;
    aio threads;
    mp4;
}

Em amostras de teste, ele ajuda muito a aumentar a largura de banda de 1 Gbps para 9 Gbps. Nove vezes! Você tem apenas 1Gbps, mas tudo é utilizado.

Veja mais detalhes: link

    

Answer 2

Um bom primeiro lugar para começar é com os arquivos .mp4 reais, onde geralmente há grandes áreas de melhoria.

Portanto, antes de se perder na sintonia do NGINX ou do Apache, primeiro ajuste seus arquivos .mp4.

Para este post cinematográfico é como um filme ou programa de televisão, onde cada mudança de quadro é necessária. Em outras palavras, tentar retransificar um filme como "The Croods" para 1 fps (frame / second) reduziria a qualidade para unwatchable.

E não-cinematográfico refere-se a capturas de tela, como Webinars, que nosso material didático postou na Udemy.

Primeiro, considere o componente de áudio do arquivo. Se o componente de áudio estiver falando primariamente, então use o ffmpeg para retrans- codificar o arquivo onde você copiou o fluxo de vídeo (sem alteração) + converta o fluxo estéreo para mono. Para muitos arquivos .mp4 (não-cinematográfico), aproximadamente 1/3 do tamanho do arquivo de filme é de vídeo + 1/3 é o canal de áudio esquerdo + 1/3 é o canal de áudio correto. Mudar de estéreo para mono pode reduzir consideravelmente o tamanho do arquivo.

Em segundo lugar, retransifique o áudio usando FDK-AAC ( link ) que produz arquivos muito menores do que outros codificadores aac. A maioria das versões modernas do ffmpeg constrói automagicamente o FDK-AAC atualmente. Até o Macports agora constrói isso. Uma consideração, para o FDK fazer sua mágica real, requer uma faixa estéreo + ao usar compressas de áudio estéreo FDK muito menores que mono, então se você estiver usando FDK, use estéreo.

Em terceiro lugar, para áudio, reduza a taxa de bits. Muitas vezes isso é 48k, então, em geral, use -ar 44100 (ffmpeg) ou falado (low fi) considere cair para 22050.

Adiante, defina a taxa de quadros do seu vídeo o mais baixo possível. Então, se você está fazendo uma captura de tela, um quadro só pode mudar uma vez em 10-60 segundos, então você pode diminuir a taxa de quadros usando -r $ fps, muitas vezes de 30-60 fps a 1-5 fps + a qualidade permanece a mesma enquanto o tamanho do arquivo cai.

Muitas vezes, comprime arquivos não-cinematográficos, onde cada 1G reduz para 10-20M.

Em quinto lugar, certifique-se de que o átomo mov do faststart esteja na frente de seus arquivos, para que seus arquivos possam ser transmitidos em vez de baixados.

Meus parâmetros ffmpeg fdk ...

-c: um perfil libfdk_aac: um aac_he_v2 -after-queimador 1 -sinalizando explícito_sbr -vbr 5 -ac2 -ar 44100

Na verdade, aqui está um típico comando ffmpeg completo ...

O script mp4 é apenas um wrapper em torno do ffmpeg que faz coisas como adivinhar quais faixas de áudio + vídeo estão em inglês (para arquivos multitrack avi + mkv) + depois construir o comando ffmpeg. O que é interessante é o comando real, que é o resíduo de anos de experimentos.

Tente primeiro executar seus arquivos por meio da compressão extrema do ffmpeg e, em seguida, veja se os pesos dos arquivos são muito baixos / pequenos, se não é necessário nenhum ajuste do servidor da Web.

Áreas de experimento: -r $ fps + -v: crf + -v: pré-ajuste + -ar taxa de bits

Um pouco de experiência lhe dará as configurações para o menor tamanho de arquivo + qualidade aceitável.

Muitas das opções ímpares, como + genpts + limpando SAR / DAR, estão lá para garantir que os arquivos .mp4 sejam reproduzidos nas unidades Roku. Estes são bons para manter, no caso de você configurar o seu próprio Canal Roku, o que é um caminho livre para alcançar mais de 5.000.000 domicílios.

Meu comando ffmpeg ...

imac > mp4 --dr --noisy foo.avi

tc: diag = v:! h264: mpeg4, a:! aac: ac3 título = 'Foo (TC)' Foo-640x480-veryfast-crf18-max-tc.mp4

cd '/Users/david/Downloads/Casper.A.Spirited.Beginning.1997.DVDrip.iNTERNAL.XviD-BPDcarrier' nice -19 ffmpeg -fflags + genpts -i "foo.avi" -map 0: 0 -c: v libx264 -crf: v 18 -preset: v muitofast -tune: v filme -nevel: v 4.1 -profile: v high -bufsize: v 5000k -vf setdar = dar = 0, setsar = sar = 0 -x264opts colorprim = bt709: transferência = bt709: colormatrix = bt709: fullrange = off -r 29.97 -movflags + faststart -map 0: 1 -c: um perfil libfdk_aac: um aac_he_v2 -after-queimador 1 -sinalização explícita_sbr -vbr 5 -ac2 -ar 44100 -título dos metadados = 'Foo (TC)' -padrões 0 -f mp4 -benchmark Foo-640x480-veryfast-crf18-max- tc.mp4.tmp mv -f Foo-640x480-veryfast-crf18-max-tc.mp4.tmp Foo-640x480-muito-rápido-crf18-max-tc.mp4

    

Answer 3

A ativação de multi_accept funcionou para mim (o vídeo costumava parar na metade e o visitante não podia ouvir / assistir a outra metade, muito frustrante).

As únicas coisas que defini no nginx.conf sob os eventos são:

events {
worker_connections 768;
multi_accept on;
}

** Funciona hoje LOL .... amanhã só teremos que ver se ele ainda toca totalmente