南大通用数据库-Gbase-8a-学习-43-SQL长时间处于Writing to net状态排查

阳光九叶草LXGZXJ

已于 2024-03-15 10:01:07 修改

阅读量1k

点赞数 26

分类专栏： # Gbase-8a-学习文章标签：学习数据库 c语言开发语言 sql unix

于 2024-03-15 10:00:02 首次发布

本文链接：https://blog.csdn.net/qq_45111959/article/details/136713349

版权

Gbase-8a-学习专栏收录该内容

45 篇文章 24 订阅

订阅专栏

8、调整参数max_allowed_packet

一、问题截图

今天我发现一个有趣的现象，用户执行一条长达17287秒（差不多5小时）的SQL，这个SQL并没有特别复杂，我用红箭头指出了特殊点：

1、SQL处于Writing to net状态。（这个状态持续了4个多小时）

2、查询的是INFORMATION_SCHEMA.COLUMNS系统表。

3、没有加过滤条件。

二、排查思路

1、Gbase8a SQL有几种状态

状态	含义
init	表示SQL进入准备执行阶段，开始执行计划。
deleting from main table/updating main table	准备对主表进行删除或更新操作。
end/query endSQL	SQL到达结束状态，准备清理资源。
Creating tmp table	查询过程中，正在创建临时表。
Sending data	读取数据向发起段发送查询结果。
closing tables	关闭打开的表。
Evaluating	执行计划评估。
Executing by step	执行计划中的每一步。
Preparing metadata	取得本查询所涉及表的可用节点信息。
Sending task to gnodes	发送任务给数据节点。
Clear tmp tables	查询完成，开始清理临时表。
Writing to Net	向客户端发送数据包。
checking permissions	检查权限。
commit	提交数据。
killed	被杀死。
logging slow query	审计日志在保存慢SQL信息。
Rolling back	数据回滚。

2、问题导致原因猜想

我们看到了Writing to Net的意思是向客户端发送数据包，会不会是网络的问题导致。我们可以提出一下几个猜想。

猜想	是否为问题原因
服务端网络负载高	未验证
客户端网络负载高	未验证
客户端程序处理数据慢	未验证

3、观察服务端（集群端）网络情况

Writing to Net的意思是向客户端发送数据包。会不会是网络负载较高，我这边是万兆网卡，理论可以达到10000Mbit/s，1Mbit（兆位） = 0.125Mb（兆字节），也就是1250Mb/s，nmon观察网络情况在33Mb/s上下浮动，排除是服务端网络问题。

猜想	是否为问题原因
服务端网络负载高	否
客户端网络负载高	未验证
客户端程序处理数据慢	未验证

4、观察客户端网络情况

客户端服务器我这边没有权限，只能建议客户帮忙排查了，哈哈哈。

猜想	是否为问题原因
服务端网络负载高	否
客户端网络负载高	权限问题，建议客户帮忙验证。
客户端程序处理数据慢	未验证

5、排查客户端程序处理数据慢

为什么我会有这样的想法呢，最近在学习网络编程相关的知识，会不会客户端程序处理逻辑有关，相关概念可以参考之前的博客《Unix环境高级编程-学习-05-TCP/IP协议与套接字》，服务端send数据，客户端recv数据，我们来简单介绍一下这两个函数，以及他们的阻塞条件。

5.1、send

（1）声明

ssize_t send(int __fd, const void *__buf, size_t __n, int __flags)

（2）作用

向套接字__fd所指向的地址发送缓冲区__buf中长度为__n的数据。

（3）参数

参数名	描述
__fd	套接字文件描述符。
__buf	缓冲区。
__n	发送的数据长度。
__flags	标志，这个在具体在其他篇幅讲。

（4）返回值

名称	描述
成功	返回发送的字节数。
失败	-1

（5）阻塞条件

当要发送的消息长度大于套接字当前可用缓冲区时, send将阻塞。

5.2、recv

（1）声明

ssize_t recv(int __fd, void *__buf, size_t __n, int __flags);

（2）作用

从套接字__fd接收长度为__n的数据放入缓冲区__buf中。

（3）参数

参数名	描述
__fd	套接字文件描述符。
__buf	缓冲区。
__n	接收的数据长度。
__flags	标志，这个在具体在其他篇幅讲。

（4）返回值

名称	描述
成功	返回接收的字节数。
失败	-1

（5）阻塞条件

recv函数会一直阻塞到接收缓冲区里有一个字节或一个完整的UDP数据报为止。

5.3、优化思路

我们平时一般的开发思路是单进程单线程从缓冲区中接收到数据，开始处理数据，处理完发送消息给服务端我收到消息，发送端再发数据，如果处理数据时间较长，是不是可能会出现类似状况呢。

如果需要改进，我的思路是开启两个线程，一个线程用于接收数据并将数据放入一个队列中，放入之后和客户端说我收到数据了，另一个线程从队列中拿数据进行处理，这样就不会一直等待。

6、查看计算节点

之前查看了一下计算节点，发现没有类似任务，刚开始还觉得这是都算完了，后来想了想，计算节点就不会有这个任务，因为管理节点和计算节点的DDL是同步的，只需要在拿到任务的管理节点计算即可。也不是个别计算节点慢导致的。

7、gccli执行SQL

我们可以用Gbase8a自带的客户端工具gccli放到本地来执行SQL，gccli具体使用方法可以参考之前的博客《南大通用数据库-Gbase-8a-学习-32-gccli客户端》，这样可以屏蔽网络的问题。

我手动执行了一下，差不多两分钟左右，gccli没有额外的数据处理过程，只是将数据fetch出来进行展示，上面程序处理慢的问题概率又大了几分。

猜想	是否为问题原因
服务端网络负载高	否
客户端网络负载高	权限问题，建议客户帮忙验证。
客户端程序处理数据慢	有一定可能。

8、调整参数max_allowed_packet

参数适当调大后，效果不明显，已经调回原值。

说明	通信时最大的包长度。即服务器和客户端通讯时，发送和接收的数据包或字符串的最大长度。
默认值	64 * 1024 * 1024（单位：字节）
最小值	1024（单位：字节）
最大值	4L1024L1024L*1024L（单位：字节）
详细介绍	1、设定单个报文或任何中间字符串(intermediate string)的最大长度，单位是字节。 2、报文消息缓冲由 net_buffer_length 参数进行设定，一般情况下，数据包的通讯缓冲区初始化为 8K字节。但其最终可以按需增长至max_allowed_packet 参数设定的大小。 3、这个参数值一般不需要设置的太大。较小的通讯缓冲区设置值可以捕获大的数据包，而那些大的数据包通常是由于异常引起的。 4、此参数的默认值较小，在使用了 BLOB 列或长字符串的场景中，应该增大其值至能容纳最大 BLOB 数据的长度。协议本身限定此值最大为 1G，参数只接受 1024 整数倍的数值，非 1024 的整数倍将会被自动圆整至离其最近的1024 整数倍的数值。