求助：实验《动手测试单机百万连接》只能达到 102610 个连接
xing393939 xing393939 2023-01-03 16:14:56 +08:00 2650 次点击这是一个创建于 1019 天前的主题，其中的信息可能已经有所发展或是发生改变。
我按照《动手测试单机百万连接》教程在 2 台 vps （ 2 核 4G ，ubuntu 22.04 ）上做，每次都只能建立 102610 个连接，有碰到相同问题的吗？
2 台 vps 的内核配置最终是：
# sysctl net.ipv4.ip_local_port_range fs.file-max fs.nr_open net.ipv4.tcp_max_orphans net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_mem net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.ip_local_port_range = 5000 65000 fs.file-max = 1100000 fs.nr_open = 1100000 net.ipv4.tcp_max_orphans = 1000000 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_mem = 600000 800000 1000000 net.ipv4.tcp_rmem = 4096 4096 6291456 net.ipv4.tcp_wmem = 4096 4096 6291456 # ulimit -n 1000000 实验是根据教程的方案二来的，vps1 起 20 个 server 进程监听 20 个端口，vps2 起 20 个 client 一一对应，每个 client 发起 5w 个连接。
实验启动后查看连接的状态：
# ss -s Total: 102808 TCP: 102635 (estab 102610, closed 0, orphaned 0, timewait 0) # netstat -ant|awk '{print $4}'|sort|uniq -c|sort -nr 5557 172.31.27.20:8103 5553 172.31.27.20:8100 5537 172.31.27.20:8105 5253 172.31.27.20:8106 5207 172.31.27.20:8114 5196 172.31.27.20:8113 5101 172.31.27.20:8116 5096 172.31.27.20:8101 5044 172.31.27.20:8117 5040 172.31.27.20:8107 5033 172.31.27.20:8104 4999 172.31.27.20:8119 4999 172.31.27.20:8118 4999 172.31.27.20:8115 4999 172.31.27.20:8112 4999 172.31.27.20:8111 4999 172.31.27.20:8110 4999 172.31.27.20:8109 4999 172.31.27.20:8108 4999 172.31.27.20:8102 可以看到每个 server 只建立了 5000 左右的连接，离 5w 还差很远。另外此时两台 vps 执行curl baidu.com都会 hang 住，此时 vps 应该是既不能 accept 又不能 connect 。不知道哪里还需要配置才能成功。
13 条回复 2023-01-05 09:49:11 +08:00
 | 1 vhwwls 2023-01-03 16:27:37 +08:00 能上十万已经接近极限了，这个配置单台百万不太可能吧 |
 | 2 v2wtf 2023-01-03 16:29:24 +08:00 你这配置太低了 |
 | 3 cat9life 2023-01-03 16:32:00 +08:00 看起来挺有趣，不懂。系统资源占用情况吗？ |
 | 4 lookStupiToForce 2023-01-03 16:40:02 +08:00 有意思 关注一下 原文博主说他测试修改了一个星期才成功，但没说具体怎么调试的，op 你可以把你的测试也记录一下补足这个过程 |
 | 5 opengps 2023-01-03 16:42:11 +08:00 没必要继续网上测试了。 我在前东家实际业务，在职期间达到过 300 万 TCP 长连接，用了上百台低配（ 2C4G ） ecs 负载。 为什么说没必要单机高负载：因为需要更好的容灾，一台机器故障或者升级重启时候影响的客户端更少。实际发现连接数多了之后，重启客户端之后的密集连接会导致连续十多分钟的资源满载，恢复过程缓慢不是被业务上能接受的。所以限制了单台服务器平均承载不超过 2 万（虽然实际到过单机承载 5 万） |
| 6 opengps 2023-01-03 16:44:23 +08:00 另外，客户端是每个链接单独占用一个系统端口的，op 的测试方案中，看起来 2 台服务器都同时用做了客户端，端口数可能达到了上限，需要改进下客户端的模式，增加模拟客户端的服务器的数量。单独用一个服务端去承载多连接测连接数指标。 |
| 7 vhwwls 2023-01-03 16:45:16 +08:00 @opengps #5 op 应该主要考虑的不是实际用途，纯粹是出于好奇心想测试一下，我也觉得生产里面不可能让一台入口负载那么多的连接。 |
| 8 opengps 2023-01-03 16:47:45 +08:00 看漏了一句，“ps1 起 20 个 server 进程监听 20 个端口，vps2 起 20 个 client 一一对应”。 这里单机单进程 client 显然无法发起 5w 个连接，多增加几个客户端机器再测吧 |
| 9 lookStupiToForce 2023-01-03 16:47:50 +08:00 刚刚发现 op 的一个问题 原文中方案二的服务 /客户端的 fs.nr_open 都是用的 60000 ，不知道为什么 op 设置成了 1100000 |
 | 11 tinybaby365 2023-01-03 16:52:41 +08:00 需要多几个 client ，或者 client 多绑几个 ip 。 |
 | 12 zizon 2023-01-04 12:51:32 +08:00 两台 curl 都卡住估计是端口用完了... |
 | 13 xing393939 OP @opengps 我测试只用 2 个 client ，每个 client 是能建立 5w 个连接的，只是再增加一个 client 就会达到 102610 这个极限点（ 102610 不是绝对的，比如有时候是 102607 ） |
Select Language