【发布时间】:2024-01-21 10:47:01
【问题描述】:
有两个 C++ 进程,每个进程中有一个线程。该线程处理来自 32 个传入 TCP 连接的网络流量(Diameter),对其进行解析并通过 32 个传出 TCP 连接转发拆分消息。让我们将此 C++ 进程称为 DiameterFE。
如果只有一个 DiameterFE 进程在运行,它可以处理 70 000 条消息/秒。
如果两个 DiameterFE 进程正在运行,它们每个可以处理 35 000 条消息/秒,因此总共可以处理 70 000 条消息/秒。
他们为什么不按比例缩放?什么是瓶颈?
详情:
每个 Diameter 前端进程有 32 个客户端 (seagull) 和 32 个服务器 (seagull),在不同的主机上运行。
为这两个进程提供了一个专用主机 - 2 个 E5-2670 @ 2.60GHz CPU x 8 个内核/插槽 x 2 个硬件线程/内核 = 总共 32 个线程。
10 GBit/秒网络。
平均 Diameter 消息大小为 700 字节。
看起来只有 Cpu0 处理网络流量 - 58.7%si。我是否必须为不同的 CPU 显式配置不同的网络队列?
第一个进程 (PID=7615) 占用 89.0 % CPU,它在 Cpu0 上运行。
第二个进程 (PID=59349) 占用 70.8 % CPU,它在 Cpu8 上运行。
另一方面,Cpu0 加载在:95.2% = 9.7%us + 26.8%sy + 58.7%si,
而 Cpu8 仅在 70.3% = 14.8%us + 55.5%sy 时加载
看起来 Cpu0 也在为第二个进程工作。有非常高的 softirq 并且仅在 Cpu0 = 58.7% 上。为什么?
这是按下键“1”的顶部输出:
top - 15:31:55 up 3 days, 9:28, 5 users, load average: 0.08, 0.20, 0.47
Tasks: 973 total, 3 running, 970 sleeping, 0 stopped, 0 zombie
Cpu0 : 9.7%us, 26.8%sy, 0.0%ni, 4.8%id, 0.0%wa, 0.0%hi, 58.7%si, 0.0%st
...
Cpu8 : 14.8%us, 55.5%sy, 0.0%ni, 29.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
...
Cpu31 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 396762772k total, 5471576k used, 391291196k free, 354920k buffers
Swap: 1048568k total, 0k used, 1048568k free, 2164532k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7615 test1 20 0 18720 2120 1388 R 89.0 0.0 52:35.76 diameterfe
59349 test1 20 0 18712 2112 1388 R 70.8 0.0 121:02.37 diameterfe
610 root 20 0 36080 1364 1112 S 2.6 0.0 126:45.58 plymouthd
3064 root 20 0 10960 788 432 S 0.3 0.0 2:13.35 irqbalance
16891 root 20 0 15700 2076 1004 R 0.3 0.0 0:01.09 top
1 root 20 0 19364 1540 1232 S 0.0 0.0 0:05.20 init
...
【问题讨论】:
-
修复此问题的方法是将内核升级到 2.6.32-431.20.3.el6.x86_64 。
之后网络中断和消息队列分布在不同的 CPU 之间。
标签: linux networking tcp scalability softirq