原 GreenPlum数据库SQL查询卡慢，报错或告警 Interconnect encountered a network error, please check your network

现象

环境：GreenPlum 6.25.3 ， centos 7.6

查询用户自建的表，会卡住很久，最后报错：

但是，查询系统表不报错。

另一个系统的报错：

这里的100是由参数控制的：

另外，查询失败的报错信息中反复出现其他segment向118.88.23.6发包失败的信息，怀疑UDP发包到118.88.23.6节点后，该节点组包失败。

可能的原因

1、防火墙

2、udp修改为tcp

3、网卡的mtu配置过大

4、/etc/hosts文件配置错误

5、若是偶发现象，则可能是丢包引起的，需要修改参数（推荐）

解决

防火墙问题

udp修改为tcp

1、之前某条SQL很慢，将udp调整为tcp后，速度快了很多，说明在udp重传方面占用了很多的时间。

若因为网络问题或配置问题导致udp丢包严重，则可以修改为tcp类型：

udp严重依赖于IP分片，通过如下的命令分析该值是否有所增加，若增加很快，则建议修改为tcp模式，修改后需要注意测试SQL执行速度是否正常，是否有很简单的SQL却执行很长时间的情况（在Navicat中很快，在其它web中很慢）：

网卡的mtu配置过大（默认为1500）

需要配置小一点：

较大的 mtu 比如 9000 也是可以, 但这样有风险, 如果用于互联机器的某个设备, 比如交换机/路由器不支持这么大的 mtu, 那么会导致机器之间无法互联互通。

降低gp_max_packet_size

先将 gp_max_packet_size 降低到 mtu, 一般 1500 以下。

通过降低 gp_max_packet_size 控制下计算节点发送数据包的大小来避免 IP 分片, 但这样相当于由计算节点自身软件来完成 IP 分片了, 与可能会 offload 到网卡硬件实现的 IP 分片相比, 降低 gp_max_packet_size 的同时性能表现也会急剧下降. 而且现行的 Linux 发包优化技术, 像 TSO, GSO 都是尽可能地将分片放在网络栈的最底层来做, 这样可以显著降低网络栈上层之间交换数据包的数量从而来得到不错的性能提升。

/etc/hosts文件配置错误

在初始化GP系统的时候，有一个特别的报错：

当时没处理，就直接初始化系统了，结果初始化完成后，系统表查询正常，但是用户新建的表不能查询，一直卡住。。。

仔细查看主机的/etc/hosts文件，发现有个地方很特别，就是“127.0.0.1 localhost sdw5”

坑。。。。

果断修改为“127.0.0.1 localhost ”，不能添加sdw5，最后初始化GP系统，最后建表查询正常了。。。这个问题耗了好几天。。。

若是偶发现象，SQL时快时慢，则可能是丢包引起的（推荐）

排查网络性能问题，是否有丢包现象。

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。