GaussDB通信性能问题定位总结

举报
Caesar.D 发表于 2021/03/16 10:26:50 2021/03/16
【摘要】 在GaussDB各类问题场景中,通信性能差很有可能成为影响查询效率、用户体验的一大瓶颈,通常其无报错、偶现发生、长期阻塞等。本文将介绍几种常用手段,用于排查其间可能存在的问题,从而快速定位恢复。文中涉及的参数、视图详情可参考产品文档。

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   总结

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

    附件下载

  • 附件.rar 2.59MB 下载次数:11
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200