GP网络问题分析总结 1项目背景 GP日志监测到异常报错，经排查确认系大量UDP丢包所致。本文围绕问题发现、排查过程、根因定位到最终解决的完整链路展开，详细记录了此次网络异常的处理全流程。 1机器配置鲲鹏硬件配置信息 CPU型号 2 * Kunpeng 7260 内存 16 * 32G 数据盘 10 * NVME 7T 网卡自研DPU卡 2丢包问题分析 2.1iperf测试丢包分析 2.1.1测试命令与测试结果由于怀疑udp有丢包，因此用iperf进行udp测试是否有大量丢包，测试命令如下：服务端：iperf -s -u 客户端：iperf -c xxx.xxx.xxx.xxx -u -i 2 -t 60 -l 1000 -b 2000M 测试丢包率达到64%，丢包比率确实较高，因此继续基于iperf分析丢包比率高的原因 2.1.2协议栈指标客户端：服务端：上面两张图为一次iperf测试前后客户端和服务端的内核协议栈指标，观察到只有udp层noports有增加几百个丢包，与iperf记录丢失几千万个对包相比可以忽略不计。 2.1.3驱动丢包统计查看驱动因backlog队列满了导致丢包数为0，如下图第2列 2.1.4网卡指标查看网卡侧的指标也记录无丢包记录 2.1.5服务器收发包数量由于查看服务器OS侧均未发现有大量丢包的指标增加，因此怀疑丢包可能发生在物理链路传输过程中。查看一次iperf测试发送端发包和接收端收包数量，发送端发送了约2亿个包，而接收端只收到了3千多万个包，如下面两张图所示。同时询问到当前使用的网卡为dpu卡，结合上面分析丢包可能发生在方框的节点中： 2.1.6软中断处理高与dpu卡同事交流，发现测试时接收端物理网口的接收到的包数量基本与发送端发送的报数量一致，因此确定丢包发生在dpu卡物理网口到虚拟网口之间。dpu卡同事观察相关指标确定为服务器分配的缓存不足导致发送包到服务器的时候导致丢包。继续观察服务器侧的cpu使用情况，发现软中断cpu使用较高，可能原因为软中断没有及时处理包导致缓存不足，因此导致丢包，软中断cpu使用高如下图所示。 2.1.7优化后结果 dpu卡同事提供了相关修改参数（参考4.2.2），同时结合服务器bios参数修改。接收端物理网口到虚拟网口之间的丢包已大幅减少，最终iperf丢包降低到20%+。查看剩余丢包点，分别是 1.发送端iperf发送的包未走到协议栈 2.接收端socket缓存满了 2.2GP网络建立链接中断分析进行调整后，GP集群仍然出现网络链接建立失败的报错。 2.2.1GP组网 2.2.2资源使用情况 25并发跑GP测试脚本时，观察cpu使用率较低无资源使用不足的情况，内存也不足情况。但是网络流量有异常，所有机器的网卡均只有发包流量，收包流量基本为0，所有机器均没有收到包。如下图情况 2.2.3排查端口与抓包分析检查相关端口未正常开启，查看GP集群报错信息提示的端口，查看端口均已开启，但都是tcp连接。使用命令ss -u查看连接建立情况，所有机器均没有看到有已建立的udp链接。因此，tcpdump抓包查看机器是否有在发送udp报文，抓包后发现有udp报文发送，但是有包大小为8164大于MTU。 2.2.4iperf测试抓包发现有包大小大于MTU大小后，怀疑可能与包大小有关系，同时之前的iperf测试并未测试过大于MTU的包的丢包情况。因此将iperf测试的包大小改为8164，测试后发现接收端确实也有收包流量基本为0的情况，与GP集群一致。调整机器MTU大小为9000后测试，接收端能正常收到包，网络问题解决。 3总结整个问题是由于发包大于MTU导致丢包断链，通过调整MTU为9000解决问题，目前测试GP集群已没有网络链接中断报错。