GBase 8a数据库集群业务SQL执行慢的可能原因

GBase 8a数据库集群,用户发现业务性能变慢,绝大部分都是环境和业务SQL原因,比如服务器硬件故障,或者业务并发太高,数据量太大,或者SQL编写的方式没有优化等。

一、先排除硬件和环境原因

1、磁盘性能差

磁盘损坏

首先确认操作系统日志是否已经报错,查看/var/log/messages或者归档日志,查看是否有磁盘相关的报错,包括扇区类 sector,文件系统类 ext4 、xfs、ext3报错等。基本都包含 sda, sdb等, 或者 err字样。

举例如下:

kernel: [29652410.762413] end_request: critical target error, dev sdb, sector 9771301434
kernel: [29652404.273769] sd 0:0:0:1: [sdb]  Add. Sense: Unrecovered read error
load kernel: EXT4-fs warning (device sdb4):ext4_dx_add_entry:Directory index full!
磁盘性能问题

可以通过fio 做磁盘随机读写性能测试。如果执行期间部分节点这样,那就可能是部分机器性能不均衡导致。具体参数和参考结果,请参考

fio磁盘性能测试参数

2、内存不足

出现了SWAP. 这个可以通过在每个节点执行 free 检查。

3、网络问题

现场出现过网卡故障,导致降速成百兆的情况,或者丢包严重。已经出现过几次某台服务器网卡降速,导致整体性能下降。重启网卡后解决。

4、CPU问题

出现过CPU降频,甚至频率不定的情况。 降频可以通过去掉节能模式,启用长期性能模式解决,频率故障那个是更换了CPU。

二、业务问题

1、涉及的表数据量

表数据量很大,耗时肯定增加。

2、业务表在join等操作生成的中间结果,数据量大

比如大表关联,或者多级关联。现场出现过几万的表,在进行多个表的join后,结果集达到1万亿行的情况。

3、在等待锁。

有其他业务拿到了锁,需要等待。可以通过 gcadmin showlock 查看锁占用情况。

GBase8a MPP Cluster查看集群锁 showlock

也可以通过show detail processlist 查看当前SQL的锁情况。

GBase8a 显示集群正在跑的SQL进程show [full | detail] processlist

4、业务繁忙,占用资源高

通过 show processlist 查看当前正在跑的SQL,是不是很多。

GBase8a 显示集群正在跑的SQL进程show [full | detail] processlist

通过nmon、iostat等查看磁盘使用繁忙程度。

Linux 查看进程占用磁盘读写情况 iostat iotop pidstat

三、优化问题

1、数据倾斜

主要是分布列或者group的第一个列重复值非常高,导致数据在某1个或几个上出现倾斜,导致虽然节点很多,但性能依然很慢。

2、没有并行

包括系统并发太高,导致后面的SQL没有更多的线程可用,导致内部串行执行。具体参考数据库参数配置 gbase_parallel_degree参数。

GBase 8a数据库集群SQL并行读参数

也可能是某些算子或函数,数据库内部当前版本没有实现并行,这个需要咨询厂商判断。

3、算法选择不对

数据库内部评估采样选择算法时出现失误,比如group时。此时可以人工设置参数(通过hint)

4、笛卡尔积

这个类似业务问题,区别是这个是SQL书写问题,是可以优化的。那个是业务本身就是结果集大。

GBase 8a集群限制结果集行数,避免的笛卡尔占用大量磁盘

5、内部逻辑等待

比如在等其它进程释放锁,特别是DML 和 DQL之间。 新版本集群已经支持DQL不再卡住DML的追加(insert load)模式,但依然会阻塞update等。
或者你在delete或者drop表,但有个该表的长查询在跑,也需要等待其执行完毕。

6、网络故障

节点网络故障,会在某些情况下出现长时间等待,而默认数据库读写超时参数是100万秒。 这个需要业务根据实际情况,设置合适的超时参数。

四、BUG

1、操作系统卡死

比如系统已经无法ssh, 或者无法连接成功gbase服务。能连接但不能成功,一直卡住。

2、数据库BUG

现象和前面类似,内部BUG,这个需要联系厂商解决。

GBase 8a数据库集群业务SQL执行慢的可能原因》有1条评论

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注