求助：实验《动手测试单机百万连接》只能达到 102610 个连接
xing393939 · xing393939 · 2023-01-03 16:14:56 +08:00 · 2374 次点击这是一个创建于 688 天前的主题，其中的信息可能已经有所发展或是发生改变。
我按照《动手测试单机百万连接》教程在 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