☰

nginx - 负载测试下 connect() 上游失败

tag-icon • tag-icon nginx reverse-proxy port load-testing resources
nginx - 负载测试下 connect() 上游失败

我一直在对wrk我的 nginx 反向代理->我的 web 应用程序设置进行一些负载测试，我注意到当我获得 1000 多个并发连接时，nginx 开始返回 502 和以下错误消息：

2015/04/17 20:45:26 [crit] 6068#0: *1116212677 connect() to \
127.0.0.1:3004 failed (99: Cannot assign requested address) \
while connecting to upstream, client: xxx.xxx.xx.165, server: \
foo.bar.com, request: "GET /my/route HTTP/1.1", upstream: \
"http://127.0.0.1:3004/my/route", host: "foo.bar.com"

命令wrk是：

wrk -t10 -c500 -d5m "https://foo.bar.com/my/route" -H "Accept: application/json"

我正在尝试弄清楚这里可能出了什么问题。我的 Web 应用程序正在监听 nginx 在端口 3004 上代理的请求。nginx 是否用完了端口？Web 应用程序是否无法处理这么多请求？请求是否超时？我对此不太清楚，希望对此有更深入的了解。

答案1

已经在这里回答了：https://stackoverflow.com/questions/14144396/nginx-proxy-connect-to-ip80-failed-99-cannot-assign-requested-address

该消息表明您已经用完了本地套接字/端口。

尝试增加网络限制：

echo "10240 65535" > /proc/sys/net/ipv4/ip_local_port_range
sysctl net.ipv4.tcp_timestamps=1
sysctl net.ipv4.tcp_tw_recycle=0
sysctl net.ipv4.tcp_tw_reuse=1
sysctl net.ipv4.tcp_max_tw_buckets=10000

或者，您可以尝试 unix 套接字，看看它是否有帮助。

答案2

网络套接字概述 通过 TCP 建立连接时，会在本地和远程主机上创建套接字。远程 IP 地址和端口属于连接的服务器端，客户端必须先确定它们，然后才能发起连接。在大多数情况下，客户端会自动选择要用于连接的本地 IP 地址，但有时由建立连接的软件选择。最后，本地端口是从操作系统提供的定义范围中随机选择的。该端口仅在连接期间与客户端关联，因此被称为临时端口。连接终止后，临时端口可供重复使用。

解决方案 启用保持连接

使用 keepalive 指令启用从 NGINX 到上游服务器的保持连接，定义每个工作进程的缓存中保留的到上游服务器的最大空闲保持连接数。超过此数量时，将关闭最近最少使用的连接。如果没有保持连接，您将增加更多开销，并且连接和临时端口的效率都会很低。

http {
    upstream backend {
        server 10.0.0.100:1234;
        server 10.0.0.101:1234;
 }

    server {
        # ...
        location / {
            # ...
            proxy_pass http://backend;
            proxy_bind $split_ip;
            proxy_set_header X-Forwarded-For $remote_addr;
        }
    }

    split_clients "$remote_addr$remote_port" $split_ip {
        10%  10.0.0.210;
        10%  10.0.0.211;
        10%  10.0.0.212;
        10%  10.0.0.213;
        10%  10.0.0.214;
        10%  10.0.0.215;
        10%  10.0.0.216;
        10%  10.0.0.217;
        10%  10.0.0.218;
        *    10.0.0.219;
    }
}

更多的 ：https://www.nginx.com/blog/overcoming-ephemeral-port-exhaustion-nginx-plus/

相关内容