一次内存引起的网络丢包问题排查
记录一下最近排查的一个问题：某台机器一上线就有丢包，同 Rack 同规格的其他机器都没有问题，由于负载都是一样的，所以问题集中到这台机器本身的问题。已经可以 100% 复现，只要一接流量，网卡就开始时不时的丢包。
初步检查：网卡的 CRC 正常，光模块正常。（这些一般是丢包的常见问题）
仔细检查网卡的计数器，发现丢包发生在 rx_prio0_buf_discard: 397172。
中间经历了很多错误的排查思路，比如这个 metric 是每一个 NIC 都有一个，但是 driver 的实现应该是用了同一个 metric，因为 2 个 NIC 的数字总是相同的。
以为是 DCB 的 buffer 不够，尝试了调大 DCB 的 buffer。
DCB 查看方式| 1234 | $ dcb buffer show dev enp94s0f1np1prio-buffer 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0buffer-size 0:20016b 1:0b 2:0b 3:0b 4:0b 5:0b 6:0b 7:0btotal-size 216288b |
发现 buffer 大了丢包反而更严重了一些，buffer 调小也是有丢包。应该是和 buffer 无关。
由于是 rx 的丢包，应该是 ingress 的处理能力不足，接下来的排查包括了：
- 查看 PCIe 的带宽，状态；
- 调整 Interrupt coalescing，让它处理更快；
……都没有效果。
中间经历了一次大促，容量足够，就暂停排查了，这周又开始继续。
好像和网卡有关的东西检查都是正常的，同事建议换一张网卡试试。换之前我使出了最后的一招：server diff.
server diff 是我排查问题作为没有思路之后的一个手段，可以简化成一段 skill：
这是一个正常的机器，这是一个异常的机器。你对比一下两个机器之间的 sysctl 参数，kernel 参数，硬件规格，看下两台机器有什么不一样的部分。
AI 发现的问题如下：
能找到的差异点（按怀疑程度排）
- 硬件/内存健康 IPMI SEL：08/31 16:46 和 16:49 两次 Uncorrectable ECC DIMMB5；mcelog 有 08/31 15:39 一条 Memory read corrected error；随后 08/31、09/02、09/03 连续多次重启。DIMM 全是 Micron 36ASF4G72PZ-3G2J3（.144 是 Samsung M393A4K40DB3-CWE），B5 序列号 2E313345，看不出被换过。 本次启动（09-03）以来 EDAC ce/ue 都是 0，但 Dell 在 UE/CE 后可能进入 ADDDC/lockstep 降级模式， 会拉低内存带宽/延迟。 保留意见：网卡在 NUMA node0（CPU1/A 组），B5 属于 CPU2（B 组），RX ring 页也在 node0， 理论上不直接受影响；但这台机器的内存子系统整体存疑。
- …
这是非常可疑的一个点，Linux 的收包链路上，NIC DMA 到内存1，路线是：
PCIe NIC → PCIe Root Port/Root Complex → IOMMU → CPU Mesh/Interconnect → LLC(L3) / Memory Controller → DRAM
内存子系统异常会显著降低 host RX path 的处理和 buffer 回收能力，可能进一步造成 NIC ingress buffer 无法及时 drain，最终表现为 rx_prio0_buf_discard。
于是我下线机器之后测试内存的带宽，我们使用的服务器有 2 个 CPU，2 个 NUMA node，于是分别测试。
测试使用 stream.c 2结果如下：
| 1234567891011121314151617181920 | $ numactl -C 2 -m 0 ./streamCopy: 10419.3 0.015583 0.015356 0.016709Scale: 11657.5 0.013985 0.013725 0.014751Add: 13445.3 0.018228 0.017850 0.018540Triad: 13297.1 0.018250 0.018049 0.018966$ numactl -C 2 -m 1 ./streamCopy: 648.4 0.251102 0.246778 0.258519Scale: 619.4 0.277245 0.258311 0.338792Add: 668.6 0.382864 0.358960 0.420878Triad: 665.1 0.378978 0.360838 0.429338$ numactl -C 3 -m 0 ./streamCopy: 13936.3 0.011795 0.011481 0.012645Scale: 8038.1 0.020416 0.019905 0.021659Add: 9287.6 0.028779 0.025841 0.049315Triad: 9252.8 0.026599 0.025938 0.027369$ numactl -C 3 -m 1 ./streamCopy: 1626.5 0.103622 0.098372 0.116646Scale: 652.1 0.258530 0.245347 0.309194Add: 710.6 0.346138 0.337722 0.377382Triad: 711.2 0.344051 0.337455 0.349108 |
（CPU 2 和 3 分别在 NUMA node 0 和 1）
可以看到，node 1 的内存，无论是同 NUMA node local 读写还是跨 NUMA remote 读写，速度只有区区 700MB，性能只有 node 0 的 1/17，确定 node 1 的内存有问题了。
进一步验证，由于我们使用的 NIC 是双网口 bond，port 1 的中断绑定到 node 0 的 CPU，port 2 的中断都绑定到 node 1 的 CPU，（这样提高 CPU 的利用率，又提供稳定的转发延迟）。所以可以通过关闭 port 2 来关闭 node 1 的使用，验证只有 node 1 的内存有问题。
关闭一个网卡之后上线，再也没有发现有丢包。
