gbase8a953版本查询慢的原因（操作系统是麒麟v10sp3）

1.问题描述:集群出现查询慢问题，观察到在xx.xx.xx.xx节点有SQL积压。将节点从集群中隔离后，性能恢复正常。

2.问题分析缓慢可能的原因：Gbase8a调用操作系统内核执行删除目录操作时，处于等待操作系统反馈状态

3.排查过程：

   现场已经收集节点当时的gbased进程的pstack。根据10:06和10:07两次的pstack显示，多数线程栈停留在libc.so.6的rmdir函数中，类似的线程共有69个。libc.so.6是Linux的基础库，GBase服务调用该库的函数进行drop临时表的文件和目录清理。该现象表示程序调用操作系统内核执行删除目录操作时，处于等待操作系统反馈状态

查看操作系统messages日志，观察到节点存在大量的audit信息，并且有success=no ,key=”delete”的记录。其中4月21日至4月22日03:00之间，success=no的记录共有16w次，其中包括gbase相关信息。Success=no的记录从4月21日21:42开始出现，gbase相关信息从22:00开始出现，在其他数据节点相同时间段观察到有success=no现象，总数约200+次，但未观察到gbase相关信息现场22号早上已经将audit关闭，4月23号下午将节点重新加回集群，并进行高并发查询测试，目前未发生性能下降现象

24号使用和问题节点相同硬件和操作系统的服务器安装单节点集群，在开启audit情况下，进行高并发查询测试，观察是否可以复现问题。

补充：25日查看高并发查询测试结果，messages里大量出现success=no的日志信息，因日志文件增长过快，/var 分区被写满。后续统计，从9:15至9:48约半小时时间内，失败的日志达500w条

4.解决方案

将audit关闭或者升级