NGINX обслуживает большие файлы mp4 крайне неэффективно

8

В настоящее время я использую nginx / 1.0.15 на ОС Centos 6.6. Сервер имеет следующие характеристики:

  • Процессор Intel® Rom Atom ™ C2750 @ 2,40 ГГц (8 ядер)
  • 32 ГБ оперативной памяти
  • 5 x 6000 ГБ 7200 об / мин (Raid 10)

Проблема

Сервер имеет скорость соединения 1 Гбит / с, однако он достигает максимальных значений и создает узкие места после 400-500 Мбит / с. Служба начинает снижаться примерно при 100 соединениях ... и скорость с сервером резко падает (несмотря на то, что пропускная способность остается 50%)

Сервер NGINX предназначен исключительно для обслуживания статических файлов .mp4. Каждый файл обычно 400-1200 МБ (в среднем 700 МБ)

Я перепробовал много разных конфигураций, и почти все они дают мне одинаковые результаты ... Я очень расстроен ..

Загрузка сервера также никогда не проходит 0,3.

Есть ли что-то явно неправильное или ошибочное в моей конфигурации? Все может помочь.

Конфигурации

/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;
    }
}
Kennysmoothx
источник
1
Есть какая-то конкретная причина быть таким устаревшим? Стабильная версия сейчас 1.8.
Пой
@poige Я обновил nginx до 1.8 стабильной этим утром
Kennysmoothx
@poige Также, когда я смотрел на iotop, я заметил, что большинство, если не все, мои рабочие процессы nginx обычно разрываются до 1918 кбит / с. Это ограничение буфера у меня может быть?
Kennysmoothx
Смотрите мой профиль для контактной информации.
Пой
@Kennysmoothx делятся выводом sysstat и ifstat во время потоковой передачи файлов
Анатолий

Ответы:

5

Лучшим началом может быть набор следующих правил:

  1. отключить ведение журнала и accept_mutex
  2. включить sendfile
  3. установить sendfile_max_chunk

Конфигурация:

events {
    accept_mutex off;
}

access_log off;
sendfile on;
sendfile_max_chunk 512k;

Новый пул потоков функций Nginx (1.7.11 или новее) может быть очень полезен в вашем случае:

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

На тестовых примерах это значительно помогает вам увеличить пропускную способность с 1 Гбит / с до 9 Гбит / с. Девять раз! У вас есть только 1 Гбит / с, но это позволяет использовать все это.

Подробнее см .: https://www.nginx.com/blog/thread-pools-boost-performance-9x/

Анатолий
источник
Я пробовал это сегодня и, к сожалению, никаких улучшений ... Я заметил, что мои рабочие процессы nginx, кажется, достигают максимума со скоростью чтения 1918kb / s, есть идеи, что это за предел?
Kennysmoothx
@Kennysmoothx это менее вероятно, Nginx, потому что вы пытались почти все, чтобы сконфигурировать его для эффективной работы с большими файлами
Анатолий
@Kennysmoothx это древнее, но вы когда-нибудь находили решение? Я бы обвинил ваш хостинг, они могут быть перепроданы, поэтому вы не достигаете 1 Гбит / с. Попробуйте другой хостинг с тем же конфигом, посмотрите, что вы получите.
Майкл Роджерс
4

Хорошее первое место, с которого стоит начать, - это фактические файлы .mp4, где обычно есть значительные области для улучшения.

Поэтому, прежде чем теряться в настройке NGINX или Apache, сначала настройте файлы .mp4.

Для этого поста кинематографический это как кино или телешоу, где требуется смена каждого кадра. Другими словами, попытка перекодировать фильм типа «The Croods» до 1 кадра в секунду (кадр / сек) снизит качество до невидимого.

И не кинематографический - это снимки экрана, такие как вебинары, которые мы публикуем в Udemy.

Сначала рассмотрим аудиокомпонент файла. Если аудио компонент в основном говорит, то используйте ffmpeg для перекодирования файла, в который вы копируете видеопоток (без изменений) + конвертирование стереопотока в моно. Для многих файлов .mp4 (не кинематографических) примерно 1/3 размера файла фильма составляет видео + 1/3 - левый аудиоканал + 1/3 - правый аудиоканал. Переход со стерео на моно может значительно уменьшить размер файла.

Во-вторых, перекодируйте звук с помощью FDK-AAC ( https://github.com/mstorsjo/fdk-aac ), который производит файлы намного меньшего размера, чем другие кодировщики aac. В наши дни большинство современных версий ffmpeg автоматически собирают FDK-AAC. Даже Macports сейчас строит это. Одно из соображений: для того, чтобы FDK сделал свое настоящее волшебство, требуется стереодорожка + при использовании стереофонических аудиокомпрессий FDK, намного меньших, чем моно, поэтому, если вы используете FDK, придерживайтесь стерео.

В-третьих, для аудио снизить битрейт. Во многих случаях это 48k, поэтому обычно используйте -ar 44100 (ffmpeg) или для разговорной речи (low fi), подумайте о снижении до 22050.

В-четвертых, установите частоту кадров вашего видео как можно ниже. Поэтому, если вы делаете снимок экрана, кадр может меняться только один раз в 10-60 секунд, поэтому вы можете снизить частоту кадров, используя -r $ fps, много раз с 30-60 кадров в секунду до 1-5 кадров в секунду + качество остается неизменным в то время как размер файла резко падает.

Много раз я сжимаю не кинематографические файлы, где каждый 1G уменьшается до 10-20M.

В-пятых, убедитесь, что faststart mov Atom находится в передней части ваших файлов, чтобы ваши файлы могли передаваться в потоковом режиме, а не загружаться.

Мои параметры ffmpeg fdk ...

-c: файл libfdk_aac -профиль: aac_he_v2 -afterburner 1 -сигнализация явный_sbr -vbr 5 -ac 2 -ar 44100

На самом деле, вот типичная полная команда ffmpeg ...

Сценарий mp4 - это просто оболочка для ffmpeg, которая делает такие вещи, как угадать, какие аудио + видео-треки на английском (для многодорожечных файлов avi + mkv) +, а затем собрать команду ffmpeg. Интерес представляет фактическая команда, которая является остатком лет экспериментов.

Попробуйте сначала запустить файлы с помощью ffmpeg Extreme Compress, а затем посмотрите, настолько ли малы / малы веса файлов, не требуется ли настройка веб-сервера.

Области эксперимента: -r $ fps + -v: crf + -v: предустановка + -ar битрейт

Немного экспериментов даст вам настройки для наименьшего размера файла + приемлемое качество.

Многие из странных опций, таких как + genpts + очистка SAR / DAR, есть, чтобы обеспечить воспроизведение файлов .mp4 на устройствах Roku. Это хорошо сохранить, если вы каждый раз настраиваете свой собственный канал Roku, который является бесплатным способом охватить более 5 000 000 домохозяйств.

Моя команда ffmpeg ...

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

tc: diag = v:! h264: mpeg4, a:! aac: ac3 title = '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 -предустановка: v очень быстрая -tune: v фильм -уровень: v 4.1 -профиль: v high -bufsize: v 5000k -vf setdar = dar = 0, setsar = sar = 0 -x264opts colorprim = bt709 : перевод = bt709: colormatrix = bt709: полный диапазон = выкл. -r 29,97 -movflags + faststart -map 0: 1 -c: файл libfdk_aac -profile: aac_he_v2 -afterburner 1 -сигнализация явный_sbr -vbr 5 -ac 2 -ar 44100 - метаданные title = 'Foo (TC)' -потоки 0 -f mp4 -benchmark Foo-640x480-очень быстрый-crf18-max-tc.mp4.tmp mv -f Foo-640x480-очень быстрый-crf18-max-tc.mp4.tmp Foo-640х480-veryfast-crf18-макс-tc.mp4

Дэвид Фавор
источник
5
Этот ответ бесполезен, поскольку основная проблема заключается в эффективном обслуживании больших файлов с помощью Nginx.
unwichtich
2

Включение multi_accept помогло мне (видео раньше останавливалось на полпути, и посетитель не мог слушать / смотреть другую половину, очень расстраивает).

Единственное, что я установил в nginx.conf под событиями, это:

events {
worker_connections 768;
multi_accept on;
}

** Это работает сегодня LOL .... завтра мы просто должны увидеть, если это все еще играть полностью

kennyhendrick
источник