NGINX Phục vụ các tệp mp4 lớn cực kỳ kém hiệu quả


8

Tôi hiện đang chạy nginx / 1.0.15 trên HĐH Centos 6.6. Máy chủ có thông số kỹ thuật sau:

  • CPU Intel (R) nguyên tử (TM) C2750 @ 2.40GHz (8 lõi)
  • Ram 32GB
  • 5 x 6000 GB 7200 vòng / phút (Raid 10)

Vấn đề

Máy chủ có kết nối 1Gbit / s, tuy nhiên, nó đứng đầu và tắc nghẽn sau 400-500 mbit / s. Dịch vụ bắt đầu giảm ở khoảng 100 kết nối .. và tốc độ với máy chủ giảm đáng kể (mặc dù vẫn có băng thông 50%)

Máy chủ NGINX hoàn toàn phục vụ các tệp .mp4 tĩnh. Mỗi tệp thường là 400-1200 MB (trung bình 700 MB)

Tôi đã thử nhiều cấu hình và hầu như tất cả chúng đều cho tôi kết quả như nhau .. Tôi vô cùng thất vọng ..

Tải máy chủ cũng không bao giờ vượt qua 0,3.

Có bất cứ điều gì sai trái hoặc sai lầm trong cấu hình của tôi? Bất cứ điều gì có thể giúp đỡ.

Các cấu hình

/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;
    }
}

1
Bất kỳ lý do cụ thể để được lỗi thời? Phiên bản ổn định bây giờ là 1.8.
poige

@poige Tôi đã cập nhật nginx lên 1.8 ổn định vào sáng nay
Kennysmoothx 14/07/2015

@poige Ngoài ra tôi nhận thấy trong khi xem iotop, hầu hết nếu không phải tất cả các quy trình nhân viên nginx của tôi thường bùng nổ lên đến 1918 kb / s Đọc. Đó có phải là giới hạn đệm tôi có thể có?
Kennysmoothx 14/07/2015

Xem hồ sơ của tôi để biết thông tin liên lạc.
poige

@Kennysmoothx chia sẻ đầu ra của sysstat và ifstat trong thời gian truyền tệp
Anatoly

Câu trả lời:


5

Khởi đầu tốt hơn có thể là tập hợp các quy tắc sau:

  1. vô hiệu hóa đăng nhập và accept_mutex
  2. cho phép sendfile
  3. đặt sendfile_max_chunk

Cấu hình:

events {
    accept_mutex off;
}

access_log off;
sendfile on;
sendfile_max_chunk 512k;

Nhóm luồng tính năng Nginx mới (1.7.11 hoặc mới hơn) có thể thực sự hữu ích trong trường hợp của bạn:

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

Trên các mẫu thử nghiệm, nó giúp bạn tăng băng thông từ 1Gbps lên đến 9Gbps ​​một cách đáng kể. Chín lần! Bạn chỉ có 1Gbps nhưng nó làm cho tất cả được sử dụng.

Xem thêm chi tiết: https://www.nginx.com/blog/thread-pools-boost-performance-9x/


Tôi đã thử điều này ngày hôm nay và thật không may là không có sự cải thiện nào .. Tôi đã nhận thấy rằng các quy trình nhân viên nginx của tôi dường như đứng đầu ở tốc độ đọc 1918kb / giây, bất kỳ ý tưởng nào giới hạn đó có thể là gì?
Kennysmoothx 14/07/2015

@Kennysmoothx ít có khả năng Nginx hơn vì bạn đã thử hầu hết mọi thứ để định cấu hình nó để phục vụ các tệp lớn một cách hiệu quả
Anatoly

@Kennysmoothx này là cổ xưa, nhưng bạn đã bao giờ tìm thấy một giải pháp? Tôi sẽ đổ lỗi cho việc lưu trữ của bạn, họ có thể đang giám sát đó là lý do tại sao bạn không đạt tới 1Gbps. Hãy thử một lưu trữ khác với cùng một cấu hình xem những gì bạn nhận được.
Michael Rogers

4

Nơi đầu tiên tốt để bắt đầu là với các tệp .mp4 thực tế, nơi thường có các khu vực cải tiến lớn.

Vì vậy, trước khi bị mất điều chỉnh NGINX hoặc Apache, trước tiên hãy điều chỉnh các tệp .mp4 của bạn.

Đối với bài đăng này, điện ảnh giống như một bộ phim hoặc chương trình truyền hình trong đó yêu cầu mỗi thay đổi khung hình. Nói cách khác, cố gắng truyền lại mã phim như "The Croods" thành 1 khung hình / giây (khung hình / giây) sẽ làm giảm chất lượng xuống không thể xem được.

Và phi điện ảnh đề cập đến các ảnh chụp màn hình như Webinars phần mềm khóa học của chúng tôi được đăng lên Udemy.

Đầu tiên, hãy xem xét thành phần âm thanh của tập tin. Nếu thành phần âm thanh chủ yếu là nói, thì hãy sử dụng ffmpeg để truyền lại mã tệp nơi bạn sao chép luồng video (không thay đổi) + chuyển đổi luồng âm thanh nổi thành đơn âm. Đối với nhiều tệp .mp4 (không phải điện ảnh), khoảng 1/3 kích thước tệp phim là video + 1/3 là kênh âm thanh bên trái + 1/3 là kênh âm thanh bên phải. Thay đổi từ âm thanh nổi sang đơn âm, có thể giảm đáng kể kích thước tệp.

Thứ hai, truyền lại âm thanh bằng FDK-AAC ( https://github.com/mstorsjo/fdk-aac ) tạo ra các tệp nhỏ hơn nhiều so với các bộ mã hóa aac khác. Hầu hết các phiên bản hiện đại của ffmpeg tự động xây dựng FDK-AAC ngày nay. Ngay cả Macports bây giờ cũng xây dựng điều này. Một điều cần lưu ý, để FDK thực hiện được phép thuật thực sự của nó đòi hỏi phải có âm thanh nổi + khi sử dụng âm thanh stereo FDK nén nhỏ hơn nhiều so với đơn âm, vì vậy nếu bạn đang sử dụng FDK, hãy gắn với âm thanh nổi.

Thứ ba, đối với âm thanh giảm bitrate. Nhiều lần đây là 48k, vì vậy, trong sử dụng chung -ar 44100 (ffmpeg) hoặc để nói (low fi) hãy xem xét giảm xuống 22050.

Forth, đặt tốc độ khung hình của video càng thấp càng tốt. Vì vậy, nếu bạn đang thực hiện chụp màn hình, một khung hình chỉ có thể thay đổi một lần trong 10-60 giây, do đó bạn có thể giảm tốc độ khung hình bằng cách sử dụng -r $ fps, nhiều lần từ 30-60 khung hình / giây xuống còn 1-5 khung hình / giây trong khi kích thước tập tin giảm mạnh.

Nhiều lần tôi nén các tệp phi điện ảnh trong đó cứ 1G giảm xuống còn 10-20M.

Thứ năm, đảm bảo nguyên tử Mov khởi động nhanh ở phía trước các tệp của bạn, để các tệp của bạn có thể được truyền phát thay vì tải xuống.

Thông số fdmp ffmp của tôi ...

-c: a libfdk_aac -profile: a aac_he_v2 -afterburner 1 -signẩy tường_sbr -vbr 5 -ac 2 -ar 44100

Trong thực tế, đây là một lệnh ffmpeg hoàn chỉnh điển hình ...

Tập lệnh mp4 chỉ là một trình bao bọc xung quanh ffmpeg, thực hiện những việc như đoán xem các đoạn âm thanh + video bằng tiếng Anh (đối với các tập tin multirack avi + mkv) + sau đó xây dựng lệnh ffmpeg. Điều đáng quan tâm là mệnh lệnh thực tế, là phần còn lại của nhiều năm thử nghiệm.

Trước tiên, hãy thử chạy các tệp của bạn thông qua nén cực mạnh ffmpeg, sau đó xem trọng lượng tệp quá thấp / nhỏ, không cần điều chỉnh máy chủ Web.

Các lĩnh vực thử nghiệm: -r $ fps + -v: crf + -v: cài sẵn + -ar bitrate

Một chút thử nghiệm sẽ cung cấp cho bạn các cài đặt cho kích thước tệp nhỏ nhất + chất lượng chấp nhận được.

Nhiều tùy chọn kỳ lạ như + genpts + xóa SAR / DAR có sẵn để đảm bảo các tệp .mp4 phát trên các đơn vị Roku. Đây là những điều tốt để giữ, trong trường hợp bạn thiết lập Kênh Roku của riêng mình, đây là cách miễn phí để tiếp cận hơn 5.000.000 hộ gia đình.

Lệnh ffmpeg của tôi ...

imac> mp4 --dr - không ồn ào foo.avi

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

cd '/Users/david/Doads/Casper.A.Spirited.Beginning.1997.DVDrip.iNTERNAL.XviD-BPDcarrier' đẹp -19 ffmpeg -fflags + genpts -i "foo.avi" v libx264 -crf: v 18 -preset: v Veryfast -tune: v film -level: v 4.1 -profile: v high -bufsize: v 5000k -vf setdar = dar = 0, setsar = sar = 0 -x264opts : transfer = bt709: colormatrix = bt709: fullrange = off -r 29.97 -movflags + faststart -map 0: 1 -c: a libfdk_aac -profile: a aac_he_v2 -afterburner 1 -signẩy tiêu đề siêu dữ liệu = 'Foo (TC)' -threads 0 -f mp4 -benchmark Foo-640x480-Veryfast-crf18-max-tc.mp4.tmp mv -f Foo-640x480-Veryfast-crf18-max-t Foo-640x480-rất nhanh-crf18-max-tc.mp4


5
Câu trả lời này không hữu ích vì vấn đề chính là phục vụ các tệp lớn một cách hiệu quả với Nginx.
unwichtich

2

Bật multi_accept làm việc cho tôi (video được sử dụng để dừng khoảng nửa chừng và khách truy cập không thể nghe / xem nửa kia, rất bực bội).

Điều duy nhất tôi đã đặt trong nginx.conf trong các sự kiện là:

events {
worker_connections 768;
multi_accept on;
}

** Nó hoạt động hôm nay LOL .... ngày mai chúng ta sẽ phải xem liệu nó có chơi hoàn toàn không

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.