☰

使用 Nginx 作为负载均衡器，随机请求会挂起一段时间，然后吞吐量就会变得很慢

tag-icon • tag-icon nginx
使用 Nginx 作为负载均衡器，随机请求会挂起一段时间，然后吞吐量就会变得很慢

我目前有以下 Nginx 配置。它大部分时间都运行良好。出于某种原因，有一定比例的请求需要很长时间，但它们不会丢失。可能最多几分钟。

然后它们通过，以每秒 5-10kbs 的速度发送文件，而正常请求可能会达到每秒几兆的速度，并在几秒钟内开始。

任何有关调试此问题的帮助都将不胜感激。

user sysadminguy;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 25000;
events {
        worker_connections 1080;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##
        access_log off;
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

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

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
        #limit_req_zone $binary_remote_addr zone=mylimit:100m rate=10r/m;
        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";
        ##
        # Virtual Host Configs
        ##
        upstream backend {
            least_conn;
            server 1.1.1.2:3292 fail_timeout=10s weight=1;
            server 1.1.1.3:3292 fail_timeout=10s weight=1;
            server 1.1.1.4:3292 fail_timeout=10s weight=1;
            server 1.1.1.5:3292 fail_timeout=10s weight=1;
            server 1.1.1.6:3292 fail_timeout=10s weight=2;
            server 1.1.1.7:3292 fail_timeout=10s weight=2;

       }
        server {
            listen      80;
            server_name server1.example.com;
            location / {
                return 301 https://$server_name$request_uri;
            }
        }
        server {
            listen 443 ssl http2 default_server;
            server_name server1.example.com;
            ssl on;
            ssl_certificate /etc/letsencrypt/live/server1.com-0001/fullchain.pem; # managed by Certbot
            ssl_certificate_key /etc/letsencrypt/live/server1.com-0001/privkey.pem; # managed by Certbot

            location = / {
                 return 301 https://example.com;
            }


            location / {
                #limit_req zone=mylimit burst=20;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_read_timeout 3600;
                proxy_request_buffering off;
                proxy_buffering off;
                proxy_pass http://backend;

             }

            location /nginx_status {
                 # Turn on stats
                 stub_status on;
                 access_log   off;
                 # only allow access from 192.168.1.5 #
                 #allow 192.168.1.5;
                 #deny all;
             }
        }
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

答案1

尝试keepalive_timeout通过将该值设置为 来禁用它0。

您的配置中最让我印象深刻的是这一行：

keepalive_timeout 65;

根据 Nginx 官方文档，默认值为keepalive_timeout是 65 秒。但根据我的经验，任何 Web 服务器（Nginx、Apache 甚至 IIS）的保持活动设置都应该在 2 到 3 秒左右。

知道我将设置该值以0有效地禁用 Nginx 中的保持活动功能，如下所示：

keepalive_timeout 0;

然后重新启动 Nginx 并查看是否解决问题。

理解保持活动设置的最佳方式是，保持活动仅在服务器上才有价值，在服务器上，与 Nginx 的一个连接将一次向客户端浏览器传递大量相关资产。

想象一下一个图片库页面，里面有几十张图片。设置一个较高的 keep alive 设置可能帮助通过一个 Nginx 连接干净高效地一次性传送所有这些图像。

这是理论。在实践中，最好禁用保持活动设置，或者简单地将其设置为足够低的值以便实用。知道你可能想要尝试将该值设置为 2 秒左右，如下所示：

keepalive_timeout 2;

重启 Nginx 并查看效果如何。应该与将该值设置为 一样高效0。

话虽如此，或许fail_timeout配置的值也upstream与该问题有关。

但深入研究一下您的配置，我看到了以下设置：

upstream backend {
    least_conn;
    server 1.1.1.2:3292 fail_timeout=10s weight=1;
    server 1.1.1.3:3292 fail_timeout=10s weight=1;
    server 1.1.1.4:3292 fail_timeout=10s weight=1;
    server 1.1.1.5:3292 fail_timeout=10s weight=1;
    server 1.1.1.6:3292 fail_timeout=10s weight=2;
    server 1.1.1.7:3292 fail_timeout=10s weight=2;
}

根据我自己的经验，该fail_timeout设置不应该如此10s，而应该0如此配置：

upstream backend {
    least_conn;
    server 1.1.1.2:3292 fail_timeout=0 weight=1;
    server 1.1.1.3:3292 fail_timeout=0 weight=1;
    server 1.1.1.4:3292 fail_timeout=0 weight=1;
    server 1.1.1.5:3292 fail_timeout=0 weight=1;
    server 1.1.1.6:3292 fail_timeout=0 weight=2;
    server 1.1.1.7:3292 fail_timeout=0 weight=2;
}

重新启动 Nginx 并查看其工作原理。根据您的描述，后端池中的每个节点似乎都会等待 10 秒才会失败。因此，例如，如果存在一些整体网络连接问题，则该池中的节点可能要等到 60 秒后才能访问（每个节点 6 次 10 秒延迟）。

如果由于某种原因，最终导致出现 503（服务不可用）错误，那么也许可以为fail_timeouthas value 设置一个实际值。也许将其设置为 3s，然后看看效果如何？

总的来说，我认为keepalive_timeout背景是这里的核心问题。fail_timeout 可能起到一定作用，但我对更深层次的设置了解不够，无法对此做出判断。

相关内容