南大通用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,这个需要联系厂商解决。