当发现集群性能下降时，应该从哪些方面入手进行排查（如慢查询、资源争用、网络延迟等）？

详细排查步骤与命令

第一步：检查集群全局状态与运行模式（最高优先级）

这是排查的起点，确保集群本身是健康的。

1. 集群状态：执行 gcadmin showcluster。必须确认 CLUSTER STATE 为 ACTIVE。若非 ACTIVE，表明元数据服务（GCware）存在严重问题，集群可能已锁定，需优先修复。

    

2. 集群模式：确认 VIRTUAL CLUSTER MODE 为 NORMAL。若为 READONLY 或 RECOVERY，性能下降是预期行为。
3. 节点服务状态：检查各节点 gbased、gcluster、syncserver 是否为 OPEN。若有 CLOSE 或 OFFLINE，该节点已失效，流量会转移到其他节点造成压力。

gcadmin showcluster vc <vc_name>

第二步：分析资源使用与争用（最常见原因）

并发场景下的资源争用是性能骤降的典型原因。

1. 资源池监控：检查各资源池是否过载。

-- 查看资源池CPU、内存使用率及活跃任务数
SHOW RESOURCE POOL USAGE ON COORDINATORS WHERE vc_name='<vc_name>';

关注点：cpu_usage_percent 持续接近100%，active_task 达到 max_activetask 上限，mem_usage_mb 接近 max_memory。这表明资源池已成瓶颈。
2. 资源管控事件：查看是否有任务因资源不足被拒绝或等待。

SHOW RESOURCE POOL EVENTS WHERE vc_name='<vc_name>' AND event_time > DATE_SUB(NOW(), INTERVAL 1 HOUR);

出现大量 WAITING 或 REJECTED 事件是资源争用的直接证据。
3. 系统级资源：登录各节点，使用 top、free -m、iostat 查看全局CPU、内存、磁盘I/O使用率。重点检查内存是否耗尽导致Swap。

第三步：定位慢查询与瓶颈SQL

单个或一批低效SQL会拖垮整个集群。

1. 利用GDOM（如有）：直接使用其 “慢SQL分析” 功能，这是最快捷的方式。
2. 查询当前运行中的慢查询：

-- 查看运行时间过长的SQL
SELECT * FROM information_schema.processlist 
WHERE COMMAND = 'EXECUTING' AND TIME > 60 
ORDER BY TIME DESC LIMIT 10;

关注 STATE 字段（如 Sending data、Sorting result）和 INFO 中的SQL语句。
3. 分析慢查询日志：

• GCluster层：查看 $GCLUSTER_HOME/log/gcluster/express.log，寻找耗时长的SQL记录。
• GNode层：查看 $GBASE_HOME/gnode/log/gbase/express.log。

4. 检查锁竞争：长时间持有的锁会阻塞其他写操作。

gcadmin showlock

查看是否有 Locked 为 True 且持续时间很长的锁。

第四步：检查数据分布与存储

数据存储层面的问题会导致查询效率低下。

1. 数据倾斜：严重的数据倾斜会使少数节点负载过高。

-- 检查表在各节点的数据段大小
SELECT table_name, node_ip, SUM(segment_size) 
FROM information_schema.cluster_table_segments 
WHERE table_schema='<db_name>' 
GROUP BY table_name, node_ip 
ORDER BY SUM(segment_size) DESC;

如果某个节点的数据量远高于其他节点，需要优化表分布键。
2. 磁盘空间：检查数据节点安装目录磁盘使用率。使用率超过80%会严重影响性能，甚至导致服务不可用。

df -h /opt/gbase

3. 表碎片与空洞：频繁的增删改可能导致表碎片化。可通过GDOM健康检查报告或查询系统表发现。

第五步：检查网络与硬件

底层基础设施问题不容忽视。

1. 网络延迟与带宽：在节点间使用 ping、iperf3 测试延迟和带宽。同步日志（sync.log）异常增长常暗示网络问题。
2. 硬件故障：检查服务器硬件日志（如RAID卡、磁盘SMART状态）。频繁的 Core/Dump 文件可能指向硬件不稳定。

ls -lrt /opt/gbase/gcluster/userdata/gcluster/core.* 2>/dev/null
ls -lrt /opt/gbase/gnode/userdata/gbase/*.dump 2>/dev/null

第六步：分析日志与核心文件

当以上步骤无法定位时，深入日志。

1. 集中分析错误日志：

• system.log：记录服务启动、停止及严重错误。
• gcware.log：元数据操作日志。
• 在日志中搜索 ERROR、WARNING、timeout、slow 等关键词。

2. 检查参数配置：确认近期是否变更过关键性能参数，如 gbase_parallel_degree（并行度）、内存相关参数（gbase_heap_*）。

三、总结：排查清单与行动指南

最终建议：性能排查应结合 “监控告警（GDOM）-> 实时分析（SQL命令）-> 日志溯源” 三位一体的方法。日常应建立性能基线，当指标偏离基线时迅速启动上述流程。对于复杂问题，建议收集相关日志（system.log, express.log, 配置文件）并联系GBase技术支持。