本文主要是介绍南大通用数据库-Gbase-8a-学习-43-SQL长时间处于Writing to net状态排查,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
一、问题截图
二、排查思路
1、Gbase8a SQL有几种状态
2、问题导致原因猜想
3、观察服务端(集群端)网络情况
4、观察客户端网络情况
5、排查客户端程序处理数据慢
5.1、send
(1)声明
(2)作用
(3)参数
(4)返回值
(5)阻塞条件
5.2、recv
(1)声明
(2)作用
(3)参数
(4)返回值
(5)阻塞条件
5.3、优化思路
6、查看计算节点
7、gccli执行SQL
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(单位:字节) |
最大值 | 4L*1024L*1024L*1024L(单位:字节) |
详细介绍 | 1、设定单个报文或任何中间字符串(intermediate string)的最大长度,单位是字节。 2、报文消息缓冲由 net_buffer_length 参数进行设定,一般情况下,数据包的通讯缓冲区初始化为 8K字节 。 但其最终可以按需增长至max_allowed_packet 参数设定的大小。 3、这个参数值一般不需要设置的太大。较小的通讯缓冲区设置值可以捕获大的数据包,而那些大的数据包通常是由于异常引起的。 4、此参数的默认值较小,在使用了 BLOB 列或长字符串的场景中,应该增大其值至能容纳最大 BLOB 数据的长度。协议本身限定此值最大为 1G,参数只接受 1024 整数倍的数值,非 1024 的整数倍将会被自动圆整至离其最近的1024 整数倍的数值。 |
这篇关于南大通用数据库-Gbase-8a-学习-43-SQL长时间处于Writing to net状态排查的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!