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表。

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

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

加载完成时将加载结果信息，没有写入到真实的表里面，而是写入到日志文件 loader_result.log 中，加载结 果信息是以’|’为列分隔符，以’\n’为行分隔符存储的普通文本文件，存放在发起 节点 gcluster($GCLUSTER_HOM/log/gcluster/)日志目录，不支持指定存放路 径。

可以通过文件，直接看到每次加载的结果。如果文件很大，后面的通过SQL的方式耗时会很长，并占用大量内存，建议用文件排查或统计。

SQL方式是通过每次加载整个文件到一个内存表(memory引擎),然后提供了SQL查询方式，所以每次查询都会重新加载入库。

建议，如果真的要对很长时间的数据进行统计分析，可以先把数据load到一个自行创建的表(express引擎)里面，然后再统计分析。

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