1 问题现象

图1. sql部分执行计划

通常情况下，此类问题是由客户感知到某业务突然变慢发现的，通过打印执行计划可以看到，Stream算子的执行时间占大部分，如图1所示，则为通信性能问题。

2 排查一：网卡多队列

通常情况下，每张网卡有一个队列，所有收到的包从这个队列入，内核从其中取数据处理，如果取数据不及时，则会存在丢包的情况。

一个CPU处理一个队列的数据，这个叫中断，默认是CPU0处理，一旦流量特别大，此CPU负载很高，性能存在瓶颈。所以需要配置网卡多队列，即一个网卡有多个队列，收到的包根据TCP四元组信息hash后放入其中一个队列，后面该连接的所有包都放入该队列，每个队列对应不同的中断，使用irqbalance将不同的中断绑定到不同的核，充分利用了多核并行处理特性，提高了效率。

可使用gs_check -i CheckMultiQueue命令进行排查，若此项未通过，则可使用gs_check -i CheckMultiQueue --set命令修复。

也可使用脚本工具get_irq_affinity.sh检查，如图2，从右向左看，每一位表示一个16进制，第一位的1表示在第1个核上，即CPU0，2表示在第2个核上，4表示第3个核上，以此类推。此网卡共绑定了5个核，可以使用ethtool命令查看，如图3，可设置的最大队列为64，当前设置队列为8。

图2. 网卡多队列检查结果

图3. ethtool命令查看队列情况

同样，set_irq_affinity.sh脚本用于进行相应的绑定，使用ethtool命令调整队列的大小，如图4，再进行绑核，-d指定网卡，-c指定绑定的核序列号，可连续，也可不连续，如图5。

图4. 设置网卡队列大小

图2. 设置网卡多队列

3  排查二：网络流量

对于一些高并发、大数据量通信的场景，网卡带宽可能是瓶颈。使用ethtool + 网卡名可以看到网卡的规格，同时使用sar -n DEV 1命令或gsar脚本观察网络流量情况，若达到上限，则需要从业务侧考虑降低并发等。

若此时流量与网卡上限相差很大，可以尝试使用speed_test工具压测，观察流量是否存在瓶颈。如图6、7，此时万兆网卡发送速度已至上限。

图6. speed_test压测情况

图7. sar命令查看网络流量

如果无法达到上限可观察是否存在重传/丢包现象，若存在，可根据《GaussDB网络重传丢包故障定位总结》排查。

4 排查三：通信库内存

由于通信库内存配置引发的性能问题是排查的一个重要方向。在各个DN节点上，其通信内存受参数comm_usable_memory限制，其默认值是4000MB，其主要包含两大方面，一是为数据结构分配的，另一个是逻辑连接的buffer。

对于数据结构分配的内存，受参数comm_max_datanode和comm_max_stream控制，计算公式为256byte * comm_max_datanode * comm_max_stream。若这两个参数设置过大，则buffer可申请的内存会变小。当一条sql执行计划中含有多个stream算子时，会根据DN情况产生对应的逻辑连接，每个连接分配一个buffer，初始默认值为2MB，如果此时内存是瓶颈，则会不断的削减buffer的大小，直到8KB为止。

当有数据流通过的时候，接收端8KB大小的buffer很容易就被占满，这个时候流控线程会通知对端的发送线程进行休眠，等待应用将数据取走后，有足够大小的buffer了，再通知对端继续发送。如图8，通过strace追踪发送线程与内核之间的交互可以看到，每一次发送端发送8192byte的数据后都会等待被唤醒，其间耗费了大量的时间，导致通信的性能慢。

图8. strace追踪发送线程热点图

因此，对于内存充足的设备，可适当的调大comm_usable_memory，同时减小不必要的参数comm_max_datanode的大小，对于comm_max_stream进行合理的评估后再进行修改。如图9、10，可以看到通信库内存为4000MB，此时已使用了4701MB，查看comm_max_datanode和comm_max_stream均为4096，计算得到数据结构分配内存为4096MB，已超过最大限制，但通信上并不会对此报错，只是通过减小buffer限制内存的使用。由于此集群只有80个DN，comm_max_datanode明显设置不合理，将其改为128，并适当的调大comm_usable_memory的值后，通信性能恢复正常。此外，数据进入buffer前会占用部分内存空间，为保障效率，没有每次都进行回收，而是由参数comm_memory_pool控制，此值可设置为comm_usable_memory的一半。

图9. pv_total_memory_detail视图

图10. 参数comm_max_datanode和comm_max_stream

5 排查四：系统调用

对于一些CPU、内存、网卡、流量均正常的场景，使用strace追踪一下进程的系统调用是一个办法。strace -p lwtid -tt -T -o strace.log，将交互信息输出到文件里，可以看到每一次通信上的所有调用，进而分析问题。

6   总结

对于通信性能问题，本文提供了几种常用方法，但实际中并不限于这几方面，对于整个链路，包括交换机、路由器、网卡等都是可能因素。因此，还需不断学习、思考、探索，问题最终都将迎刃而解。