Hologres 诊断与优化快速入门

作者：赵红梅 Hologres PD

摘要：在这次分享中，将向大家展示如何利用一系列诊断与调优工具，实现对 SQL 和数据库异常的全方位诊断，从而提升实例稳定性。

Hologres 诊断与优化实践总结

我的介绍将分为五个部分：首先，在事前阶段，讲解如何利用监控指标实现实时监控和预防措施。其次，事中探讨团队如何通过活跃日志发现运行中的问题，并及时采取措施止损，以避免业务问题的恶化。接下来，在事后阶段介绍如何通过深入分析和结合可视化工具来诊断当前的性能瓶颈。此外展示如何通过表管理工具实现成本治理，以及如何利用特定的诊断工具来提升系统的稳定性。 内容大纲如下：

1. Hologres 诊断与优化的实践

2. 事前：通过监控指标实时监控实例异常

3. 事中：通过活跃 SQL 日志快速定位长 SQL

4. 事后：通过慢 Query 日志+Query 洞察诊断慢 Query

5. 事后：通过慢 Query 日志+Query 洞察治理错 Query

6. 稳定治理：SQL 诊断报告长期治理 SQL

7. 稳定性治理：表 Meta 诊断报告治理 Meta 问题

8. 成本治理

事前：实例实时监控

了解监控指标

首先事前团队需要预先审视业务，目的是提前发现并解决潜在问题，以防止问题在生产环境中恶化。建议采用监控指标并设置相应的告警机制来执行这一操作。Hologres 提供丰富的监控指标来帮助业务及时发现实例异常。访问管控台，选择相应的实例，进入监控信息页面，您将看到 Hologres 提供的大约五类监控指标，每一类都对应不同的业务属性。关于监控指标的详细使用见文档。

资源和 Query 类监控

资源与 Query 运行状况监控指标主要用于监控团队在实际操作中资源的利用率以及运行状况。包含 CPU 使用率、内存使用率等，可以实时监测到实例资源的使用。

• CPU 监控：以实例的 CPU 使用率为例，它反映了实例中 CPU 的整体使用情况。如果 CPU 使用率随着 Query 波动，这通常意味着 CPU 运行状况良好。然而，如果 CPU 使用率持续处于满载状态，这表明资源可能已经不足，此时需要团队及时优化实例中的 SQL 或对资源进行扩容。接下来是 Worker 节点的 CPU 使用率监控，它旨在报告每个 Worker 节点的 CPU 使用情况。从图表中可以看到，如果每个 Worker 的 CPU 使用率相对均匀，这通常表明运行状况是健康的。但是，如果某个 Worker 的 CPU 使用率达到 100%，而其他 Worker 的使用率很低，或者大部分 Worker 的 CPU 使用率都很高，唯独某个 Worker 的使用率偏低，这说明资源利用并不均衡。在这种情况下，团队需要检查是否存在数据倾斜问题，或者 Worker 节点的分布是否均匀。

• 内存监控：在内存相关的监控指标上，可以看到实例整体的内存使用情况，也能看到不同模块的内存使用，例如 Query 使用内存、meta 内存等，方便业务对内存水位持续性监控和治理。

• QPS 和 RPS 指标：可以综合的反映实例的读写情况，但需要注意的是，实例能支撑的 QPS 和 RPS 与实例规格、Query 复杂度等因素有关，建议根据实际情况进行压测

• Query 延迟：包括 Query 在每个阶段的延迟（Optimization 阶段、Start Query 阶段、Get next 阶段）可以根据阶段的耗时来评估 Query 的运行情况，并针对性优化。同时也提供 Query 的整体延迟和 P99 延迟，以综合反映实例中所有 Query 运行的延迟。但需要重点关注“本实例正在运行中 Query 最长的时长”，可以反映实例中是否出现运行时间较长的 Query，及时结合 holoweb-活跃 Query 找到该 Query，并做治理，防止实例中资源长期打满，影响其他的任务运行。

• 失败 Query：它主要监控实例在过去一段时间或实时中是否有失败的 Query。如果在某段时间内失败的 Query 数量增加，这可能表明实例出现异常，团队需要及时介入处理

I/O 和存储类监控

• IO：反映 Query 在运行过程中与底层存储的 IO 交互情况，不涉及网络的 I/O，通过 IO 的吞吐情况，判断数据的处理。

• 存储：反映实例中真实的数据存储

流量和 Framework

流量和 Framework 主要会反映 Query 运行过程中与网络等的交互情况。

• Endpoint 流量：反映了不同网络的流量情况情况，包括公网、VBC 网以及经典网等，它记录了数据流入和流出的状况，流量的使用可以反馈带宽是否到达极限，从而影响数据写入或读取的速度。

• Framework：反映 shard 多副本、以及实例副本的延迟，一般来说延迟在毫秒级都是正常，如果延迟较高，说明实例异常需要及时处理。请重点关注“FE replay 延迟(milliseconds)”指标，延迟已经累积到小时级别，表示实例中 worker 有卡住的情况，需要及时处理

• Gateway：Gateway，作为计算组中的一个特殊组件，其主要职责是进行 SQL 分发和路由控制。因此，监控 Gateway 的 CPU、内存以及网络流量的使用情况，可以反映 Query 处理速度和规模，团队应定期检查这些资源的使用情况，以判断是否需要扩容。

Serverless 和资源弹性

• Serverless Computing：实时观测在 serverless 中运行的 Query 延迟、排队情况等，及时治理

• Computing Resource：监控分时弹性的使用情况

Binlog 和 Analyze

• Auto Analyze：反映实例中每个 DB 内表的统计信息缺失情况，以判断 auto analyze 的准确率，及时手动更新表的统计信息

• Binlog：主要是监控 Binlog 的使用情况，包括吞吐和 wal sender 连接数，从而判断消费 Binlog 是否出现瓶颈

监控告警最佳实践

如果要对监控指标告警，可以点击报警-报警设置，根据业务情况设置阈值告警。Holo 推荐常用的监控指标告警如下：

监控 CPU 使用率：监控实例的 CPU 使用率和 Worker 节点 CPU 使用率，如果 CPU 使用率长时间保持在 100%，则表明资源严重不足，此时需要考虑扩容或优化团队运行的业务。其次，关注 Worker 节点的 CPU 使用率，这有助于观察资源是否被均匀利用。

监控 Query 延迟：通过监控 Query 延迟，可以实时监控是否有延迟上涨，以此判断实例负载情况

监控失败 Query：通过失败 Query 可以监控到当前实例中任务运行情况，如果连续失败，可能存在实例异常，需要及时处理

监控“本实例/Serverless 最长的 Query 运行时长”：可以了解当前是否有运行时间较长的 Query，如果长时间运行，会导致资源占用，影响其他 Query

事中：活跃 SQL 日志快速定位长 SQL

可以以通过活跃 SQL 日志快速定位运行中的长 SQL。通过 Holoweb>诊断与优化>活跃 Query，查看到当前实例中正在运行的 SQL，详细的信息包括运行时长、执行引擎等，如果 CPU 已经有长时间运行且不符合业务预期的，需要结合监控页面，看 CPU 是否已经被打满，然后在活跃 Query 界面点击取消，将该 Query 取消，以避免长期占用资源，同时 CPU 也会下降，说明问题止血成功。更多操作详情见文档

事后：慢 Query 日志诊断 Query

优化慢 Query

如果要对 Query 持续性的治理和优化，可以使用[慢 Query 日志](https://help.aliyun.com/zh/hologres/user-guide/query-and-analyze-slow-query-logs?spm=a2c4g.11186623.0.0.24994a5eQgWXyB" \l "concept-2069482)结合Query洞察功能：

• 第一步：前往 holoweb>诊断优化>慢 query 日志查询当前实例的慢 SQL 列表，重点关注 duration、engine type、cpu_time 字段

• 第二步：对于运行时间较长、资源消耗较多的 SQL，单击前往 Query 洞察分析，分析单个 SQL 性能，重点关注 enginetype、readrows、readbytes

• 第三步：查看 Query 执行计划，重点关注算子：partitionselected、filter、time、rows，如下示例的 plan，东从下往上看，Read Rows 已经处理了数亿量级的数据，从 274 个分区中扫描了 60 个分区，比较多，同时也是读取的 MC 外表，因此建议优化方向是减少分区扫描或者将外表导入到内表，以提升性能

治理错 Query

如果实例中监控到 Failed Query 较多，可以通过慢 Query 日志结合 Query 洞察治理。方法如下：

• 第一步：监控指标观察 FailedQueryQPS，观察到时间 Query 对应的时间段

• 第二步：前往 holoweb>诊断优化>慢 Query 日志，图维度选择”失败 Query“，并选择对应的时间段，查找错误的 SQL

• 第三步：点击前往“query 洞察分析”>错误信息，Query 洞察会展示出详细报错，同时也会结合 AI，给出详细的报错原因和解决方案，可以根据建议对 SQL 进行治理，提升实例的稳定性。

稳定性治理：SQL 诊断长期治理

Hologres 在 Holoweb 提供一个 SQL 诊断报告，可以查看昨天以及过去的详细 SQL 运行，例如耗时占比、错误占比等，通过长期治理 SQL，来提升实例稳定性。详细使用见文档。重点关注如下几个治理项：

• 错 SQL 治理：关注失败 Query 明细，可以查看某天的失败次数，典型失败 Query，根据 Query 洞察中的错误信息和改进建议，治理错 SQL，提升实例的成功率

• 长 SQL 治理：关注 Query 耗时占比趋势，可以分析出 Query 的耗时占比，重点关注耗时较长（超过 10min）的 query 耗时占比，并通过 Query 洞察查看明细，治理慢 SQL

• 应用治理：关注 Query 应用来源占比，可以分析出发起 Query 的应用来源，当出现异常时可以及时找到对应的应用。同时建议，尽量给每个应用都配置上应用来源 application_name，不建议所有的 Query 都用统一的应用名，无法进一步排查问题

• 执行引擎治理：关注执行引擎的 Query 趋势，Hologres 中有多个执行引擎（HQE、PQE、SQE 等），其中 HQE 为自研引擎更高效，所以需要重点关注执行引擎为 SQE、PQE 的 Query 趋势，尽量减少 PQE 的 Query，以此提升 Query 性能

稳定性治理：表 Meta 诊断 Meta 问题

meta 诊断：当 Hologres 数据库中的元数据管理器（Storage Master）和 FE 节点保存的表元数据不一致时，会导致 DDL 操作报错或影响费用等。表 Meta 诊断功能，以检测当前实例中表元数据的一致性，并每周更新一次诊断结果，可以根据对应元数据问题的解决方案进行修复，以提高实例的可用性和稳定性。

Meta 诊断是自动推送的异常问题，如果页面显示空白，则说明实例无 meta 问题，不需要治理。如果出现 Meta 异常，Hologres 也提供一键修复的能力，单击一键修复，在业务低峰期执行修复 SQL，以便修复 meta 问题，提升实例问题性，详细使用见文档。

成本治理：表索引诊断报告长期治理表

随着业务的持续迭代，团队实例中的表数量可能会迅速增加，导致管理困难，或者不清楚删除哪些不必要的表，以及表的索引使用情况等，为此，我们提供了一个标准的表索引诊断报告，以评估当前实例中表的使用情况。表索引诊断报告的项目较多，详细使用可以参考文档，Hologres 比较建议对如下几项内容进行治理：

1. 存储治理：

2. 分区子表数和存储量：查看分区表的存储量，治理存储为 0 的表

3. 存储为 0 的表：及时治理存储为 0 的表，防止占用 meta 内存

4. 行存表治理：

5. 没有设置主键：无法用上索引的能力，需要重新建表并设置主键

6. Distributionkey 和 clusteringkey 不一致的行存表：不适用行存表点查场景，改成列存/行列共存

7. 表字段数治理：

8. 超过 300 列的列存表：列太多，性能开销大

9. 超过 300 列的行列共存表：列太多，性能开销大

10. 索引治理：

11. 超过 3 列的 clustering/segment/distributionkey：索引设置超过 3 列，会导致使用场景受限，无法很好的利用索引的能力

12. Binlog 表治理：

13. 开启 Binlog 的表：不建议列存表开启 binlog，性能开销大

14. BinlogTTL 大于 7 天：Binlog 太多会导致占用过多的存储，关注表存储量，及时治理

通过表属性诊断，有助于深入分析团队实例中的表、索引以及字段数量，甚至包括表属性等情况，以便进一步优化管理表，以实现长期的成本治理目标