Hết thời gian chờ NGINX sau hơn 200 kết nối đồng thời


12

Đây là của tôi nginx.conf(Tôi đã cập nhật cấu hình để đảm bảo rằng không có PHP liên quan hoặc bất kỳ nút thắt nào khác):

user                nginx;
worker_processes    4;
worker_rlimit_nofile 10240;

pid                 /var/run/nginx.pid;

events
{
    worker_connections  1024;
}

http
{
    include             /etc/nginx/mime.types;

    error_log           /var/www/log/nginx_errors.log warn;

    port_in_redirect    off;
    server_tokens       off;
    sendfile            on;
    gzip                on;

    client_max_body_size 200M;

    map $scheme $php_https { default off; https on; }

    index index.php;

    client_body_timeout   60;
    client_header_timeout 60;
    keepalive_timeout     60 60;
    send_timeout          60;

    server
    {
        server_name dev.anuary.com;

        root        "/var/www/virtualhosts/dev.anuary.com";
    }
}

Tôi đang sử dụng http://blitz.io/play để kiểm tra máy chủ của mình (tôi đã mua gói 10 000 kết nối đồng thời). Trong 30 giây chạy, tôi nhận được 964lượt truy cập và 5,587 timeouts. Thời gian chờ đầu tiên xảy ra ở 40,77 giây trong thử nghiệm khi số người dùng đồng thời ở mức 200.

Trong quá trình thử nghiệm, tải máy chủ là ( topđầu ra):

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               20225 nginx     20   0 48140 6248 1672 S 16.0  0.0   0:21.68 nginx                                                                  
    1 root      20   0 19112 1444 1180 S  0.0  0.0   0:02.37 init                                                                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                               
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0      

Vì vậy, nó không phải là vấn đề tài nguyên máy chủ. Sau đó là gì?

CẬP NHẬT 2011 12 09 GMT 17:36.

Cho đến nay tôi đã thực hiện các thay đổi sau để đảm bảo rằng nút cổ chai không phải là TCP / IP. Đã thêm vào /etc/sysctl.conf:

# These ensure that TIME_WAIT ports either get reused or closed fast.
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1
# TCP memory
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

Một số thông tin gỡ lỗi khác:

[root@server node]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 126767
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

NB worker_rlimit_nofileĐược đặt thành 10240cấu hình nginx.

CẬP NHẬT 2011 12 09 GMT 19:02.

Có vẻ như tôi càng thay đổi nhiều thì càng tệ, nhưng đây là tập tin cấu hình mới.

user                nginx;
worker_processes    4;
worker_rlimit_nofile 10240;

pid                 /var/run/nginx.pid;

events
{
    worker_connections  2048;
    #1,353 hits, 2,751 timeouts, 72 errors - Bummer. Try again?
    #1,408 hits, 2,727 timeouts - Maybe you should increase the timeout?
}

http
{
    include             /etc/nginx/mime.types;

    error_log           /var/www/log/nginx_errors.log warn; 

    # http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/
    access_log              off;

    open_file_cache         max=1000;
    open_file_cache_valid   30s;

    client_body_buffer_size 10M;
    client_max_body_size    200M;

    proxy_buffers           256 4k;
    fastcgi_buffers         256 4k;

    keepalive_timeout       15 15;

    client_body_timeout     60;
    client_header_timeout   60;

    send_timeout            60;

    port_in_redirect        off;
    server_tokens           off;
    sendfile                on;

    gzip                    on;
    gzip_buffers            256 4k;
    gzip_comp_level         5;
    gzip_disable            "msie6";



    map $scheme $php_https { default off; https on; }

    index index.php;



    server
    {
        server_name ~^www\.(?P<domain>.+);
        rewrite     ^ $scheme://$domain$request_uri? permanent;
    }

    include /etc/nginx/conf.d/virtual.conf;
}

CẬP NHẬT 2011 12 11 GMT 20:11.

Đây là đầu ra của netstat -ntlatrong quá trình thử nghiệm.

https://gist.github.com/d74750cceba4d08668ea

CẬP NHẬT 2011 12 12 GMT 10:54.

Chỉ cần làm rõ, iptables(tường lửa) tắt trong khi thử nghiệm.

CẬP NHẬT 2011 12 12 GMT 22:47.

Đây là sysctl -p | grep membãi rác.

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608
net.ipv4.route.flush = 1
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_max = 8388608
net.core.wmem_default = 65536
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

CẬP NHẬT 2011 12 12 GMT 22:49

Tôi đang sử dụng blitz.iođể chạy tất cả các bài kiểm tra. URL tôi đang kiểm tra là http://dev.anftime.com/test.txt , sử dụng lệnh sau:--region ireland --pattern 200-250:30 -T 1000 http://dev.anuary.com/test.txt

CẬP NHẬT 2011 12 13 GMT 13:33

nginxgiới hạn người dùng (đặt trong /etc/security/limits.conf).

nginx       hard nofile 40000
nginx       soft nofile 40000

Bạn đang lưu trữ này? Không có cân bằng tải hoặc bất cứ điều gì như vậy ở phía trước của máy chủ? Một cái gì đó từ ISP có thể phát hiện ra nó là một cuộc tấn công DDoS và đẩy nó xuống?
Bart Silverstrim

Vâng, đây là máy chủ của tôi. ovh.co.uk/dclus_servers/eg_ssd.xml Không có gì có thể đẩy lùi cuộc tấn công DDoS. Tôi cũng đã tăng worker_processeslên 4.
Gajus

Chỉ cần liên hệ với OVH để kiểm tra kỹ xem có chứng khoán cấp mạng nào được triển khai trên máy chủ của tôi không. Không, không có.
Gajus

loại dữ liệu nào bạn đang phục vụ từ đây? html, hình ảnh, vv?
pablo

1
Tôi nghĩ rằng nó sẽ giúp chạy một điểm chuẩn cục bộ để loại trừ cấu hình nginx. Không bạn
3molo

Câu trả lời:


2

Bạn sẽ cần kết xuất mạng của mình trong quá trình kiểm tra. Mặc dù máy chủ có thể có tải gần bằng không, ngăn xếp TCP / IP của bạn có thể được thanh toán. Tìm kiếm các kết nối TIME_WAIT trong đầu ra netstat.

Nếu đây là trường hợp, thì bạn sẽ muốn kiểm tra điều chỉnh các tham số hạt nhân tcp / ip liên quan đến trạng thái Chờ TCP, tái cấu trúc TCP và các số liệu tương tự.

Ngoài ra, bạn đã không mô tả những gì đang được thử nghiệm.

Tôi luôn kiểm tra:

  • nội dung tĩnh (tệp hình ảnh hoặc văn bản)
  • trang php đơn giản (ví dụ phpinfo)
  • trang ứng dụng

Điều này có thể không áp dụng trong trường hợp của bạn nhưng là điều tôi làm khi kiểm tra hiệu suất. Kiểm tra các loại tệp khác nhau có thể giúp bạn xác định chính xác nút thắt.

Ngay cả với nội dung tĩnh, việc kiểm tra kích thước tệp khác nhau cũng rất quan trọng để có được thời gian chờ và các số liệu khác được quay số.

Chúng tôi có một số hộp Nginx nội dung tĩnh xử lý hơn 3000 kết nối hoạt động. Vì vậy, nó Nginx chắc chắn có thể làm điều đó.

Cập nhật: Netstat của bạn hiển thị rất nhiều kết nối mở. Có thể muốn thử điều chỉnh ngăn xếp TCP / IP của bạn. Ngoài ra, tập tin nào bạn yêu cầu? Nginx nên nhanh chóng đóng cổng.

Đây là một gợi ý cho sysctl.conf:

net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

Các giá trị này rất thấp nhưng tôi đã thành công với chúng trên các hộp Nginx đồng thời cao.


XemUPDATE 2011 12 09 GMT 17:36.
Gajus

thêm cập nhật để trả lời chính do mã.
jeffatrackaid

vui lòng thêm đầu ra hoàn chỉnh hàng đầu trong quá trình kiểm tra, bạn không nên chỉ kiểm tra xem nginx đang sử dụng bao nhiêu CPU.
Giovanni Toraldo

1
thận trọng khi sử dụng net.ipv4.tcp_tw_recycle = 1, nói chung: không phải là một ý tưởng tốt. tái sử dụng là ok tho.
nặc danh-một

Tại sao không sử dụng ổ cắm Linux thay vì localhost?
BigSack

1

Một giả thuyết khác. Bạn đã tăng worker_rlimit_nofile, nhưng số lượng khách hàng tối đa được xác định trong tài liệu

max_clients = worker_processes * worker_connections

Điều gì nếu bạn cố gắng nâng worker_connectionslên, như, 8192? Hoặc, nếu có đủ lõi CPU, tăng worker_processes?


1

Tôi đã gặp một vấn đề rất giống với hộp nginx đóng vai trò là bộ cân bằng tải với một dòng máy chủ apache.

Trong trường hợp của tôi, tôi đã có thể cô lập vấn đề để liên quan đến mạng khi các máy chủ apache ngược dòng trở nên quá tải. Tôi có thể tạo lại nó với các tập lệnh bash đơn giản trong khi toàn bộ hệ thống đang được tải. Theo một bước tiến của một trong các quy trình treo, cuộc gọi kết nối đã nhận được một ETIMEDOUT.

Các cài đặt này (trên nginx và máy chủ ngược dòng) đã loại bỏ sự cố cho tôi. Tôi đã nhận được 1 hoặc 2 thời gian chờ mỗi phút trước khi thực hiện các thay đổi này (hộp xử lý ~ 100 reqs / s) và bây giờ nhận được 0.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_max_syn_backlog = 20480
net.core.netdev_max_backlog = 4096
net.ipv4.tcp_max_tw_buckets = 400000
net.core.somaxconn = 4096

Tôi không khuyên bạn nên sử dụng net.ipv4.tcp_tw_recycle hoặc net.ipv4.tcp_tw numuse, nhưng nếu bạn muốn sử dụng một đi với cái sau. Chúng có thể gây ra các vấn đề kỳ quái nếu có bất kỳ loại độ trễ nào và ít nhất là sau này an toàn hơn cho cả hai.

Tôi nghĩ rằng việc đặt tcp_fin_timeout thành 1 ở trên cũng có thể gây ra một số rắc rối. Hãy thử đặt nó ở 20/30 - vẫn còn thấp hơn nhiều so với mặc định.


0

có thể không phải là vấn đề nginx, trong khi bạn kiểm tra trên blitz.io hãy làm:

tail -f /var/log/php5-fpm.log

(đó là những gì tôi đang sử dụng để xử lý php)

điều này gây ra lỗi và thời gian chờ bắt đầu tăng:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

vì vậy, đặt thêm max_children vào fmp conf và đã xong! ; D


Vấn đề là như nhau nếu tôi có return 200 "test"trong NGINX. Điều này có nghĩa là NGINX thậm chí không đi xa đến mức gọi PHP-FPM.
Gajus

0

Bạn có quá thấp max open files(1024), hãy thử thay đổi và khởi động lại nginx. ( cat /proc/<nginx>/limitsđể xác nhận)

ulimit -n 10240

Và tăng worker_connectionslên 10240 hoặc cao hơn.


Tôi không chắc tại sao điều này đã được bỏ phiếu. Âm thanh như câu trả lời đúng cho tôi.
Ryan Angilly
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.