GBase 8a集群调度服务gclusterd占用大量CPU和磁盘资源的几种情况

GBase 8a集群的调度服务gclusterd负责对外连接，解析SQL和调度下发任务，并返回结果集。从职能设计上不会消耗大量的CPU和磁盘资源。本文介绍几种可能发生的特殊情况。

大量并发SQL

这个最好理解，SQL多，就算每个占用资源少，但多了也一样承担不起。不过一般都会有多个调度节点，做一下负载均衡就好了。当然如果并发太多，还是要考虑下合理性，控制下前端的连接池数量。

扫描了集群层的本地表，特别是TABLES,Views

information_schema.tables表是一个内存表，每次使用时，如果没有明确的表名字条件，就会出现全库扫描。比如

select * from information_schema.tables

如果表很多，几十万以上，则需要从磁盘上读取每个表的结构文件进行解析，花费大量的磁盘IOPS。

解决方案就是对于experss表，可以访问gbase.table_distribution表。 具体建议可以参考： GBase8a 集群查看或判断库里有哪些表，或某张表是否存在

访问了加载历史结果表

information_schema.load_result和 information_schema.cluster_load_result。该表记录了加载的历史结果，为内存表。实际存储为外部文件。如果文件较大(加载次数多，保留周期长），则会占用大量的IO资源来读取。

解决建议是定时归档该文件，比如只保留最近1天的。

参考：GBase 8a集群通过SQL查询加载历史记录日志

调用了服务器端游标

该功能是在服务器端生成一个临时表，来支持游标的向前和向后操作。如果结果集很大，则会出现需要在调度节点写入大量数据的情况。 建议采用流模式读取，不要使用服务器端游标。

请参考JDBC的一个常见案例。GBase 8a采用流模式处理JDBC大结果集，避免内存不足 OutOfmemoryError: GC overhead limit exceeded