使用集群前必读：性能管理要求
GaussDB(DWS)数据库系统的性能管理在整个系统中起着很关键的作用，为了避免集群频繁出现资源（CPU/IO/内存/磁盘空间等）过载情况，需要对集群内的业务和整体资源进行设限和管控，并定期进行主动运维，提前进行扩容规划等。
例如，在新业务上线前，需要对现有资源进行评估和压测，防止新业务上线后占用大量资源影响集群整体性能。后期随着存量业务数据量的增长，集群磁盘空间和IO使用也会逐渐增加，需要定期进行老化数据和脏数据的清理。
本章节主要介绍集群性能基线，为用户和运维人员介绍常见业务场景下的性能管理要求，提前评估集群容量，防止集群出现资源过载。
GaussDB(DWS)集群性能基线
本节主要介绍GaussDB(DWS)各项资源的推荐值和风险值。
当集群资源水位超过推荐值后，运维人员需要及时介入处理，防止节点异常、主备切换等故障场景下的性能降级。
当集群资源水位超过风险值后，集群会有很高的过载风险，应禁止继续上线新业务。
此时，需要通过业务优化或错峰调度等手段尽快降低集群整体负载，必要时可以进行集群拆分或扩容防止影响整体性能。
|
性能指标 |
建议值 |
超过建议值的影响 |
推荐措施 |
风险值 |
超过风险值的影响 |
推荐措施 |
|---|---|---|---|---|---|---|
|
CPU使用率 |
60%以下 |
在主备非均衡或集群降级状态下，部分节点的CPU使用率有过载风险，引发性能降级。 |
建议配置资源池进行资源隔离，参考GaussDB(DWS)资源负载管理。通过topsql抓取高CPU语句进行业务优化，参见监控并诊断GaussDB(DWS)集群TopSQL。 |
80% |
出现严重的CPU争抢，导致Stream等算子执行时间劣化，集群整体性能受到严重影响。 |
通过业务错峰、业务拆分、业务优化、集群扩容等手段降低高峰期CPU负载。 也可以设置资源池CPU限额与配额，参见高CPU系统调优方案。 |
|
CPU倾斜率 |
15%以下 |
出现计算倾斜，导致部分语句无法充分发挥分布式下的最佳性能。 |
建议通过异常规则、配置熔断参数等手段对倾斜语句提前熔断；日常对此类业务进行优化整改。 |
30% |
高峰期容易出现单节点CPU过载，木桶效应导致集群整体劣化，无法充分发挥其他节点性能。 |
建议通过异常规则、配置熔断参数等手段对倾斜语句提前熔断；日常对此类业务进行优化整改。 |
|
IO使用率 |
60%以下（机械硬盘） |
在主备非均衡或集群降级状态下，部分节点的IO使用率有过载风险，引发性能降级，机械硬盘尤其容易出现非均衡状态下的IO过载。 |
使用iowatcher工具抓取IO高的业务，通过索引、分区剪枝、行列存整改等常用方法，降低磁盘IO使用率。 参见降低IO的处理方案。 |
90%（机械硬盘） |
出现比较严重的IO争抢，导致表扫描等算子执行时间劣化，集群整体性能受到影响。 |
建议对高IO语句优化和错峰，机械硬盘集群建议替换为固态硬盘保证IO性能，提前规划集群扩容减少单节点IO吞吐量。 |
|
IO读写时延 |
400ms以下 |
进行数据读写时性能出现波动，查询时间不稳定，出现偶发性能劣化。 |
使用iowatcher工具抓取IO高的业务，通过索引、分区剪枝、行列存整改等常用方法，降低磁盘IO使用率，读写时延会随之降低。 参见降低IO的处理方案。 |
1000ms |
数据读写性能明显劣化，实时入库业务出现积压，整体性能出现劣化。 |
排查是否出现磁盘坏道、raid卡故障等硬件故障；同时建议对高IO语句、高下盘语句、高并发语句进行优化整改，进行业务错峰和业务拆分。 |
|
动态内存使用率 |
80%以下 |
当业务流量突增或复杂灵活查询执行时，会有内存不足报错的风险。 |
配置异常规则和内存熔断；对高内存业务进行优化整改。 降内存方法可参见降低内存的处理方案。 |
90% |
出现CCN排队，业务出现内存不足报错，有进程OOM风险。 |
配置异常规则和内存熔断；对高内存业务进行优化整改； |
|
磁盘空间使用率 |
70%以下 |
SQL下盘量较大，磁盘使用率超过90%时，有只读风险。 |
配置下盘熔断，低峰期进行数据清理和脏页清理，提前进行扩容规划。 更多可参见磁盘使用率高处理方案。 |
80% |
出现SQL下盘后只读风险增加。 |
配置下盘熔断，低峰期进行数据清理和脏页清理，提前进行扩容规划。 |
|
磁盘空间倾斜率 |
15%以下 |
倾斜磁盘超过90%的风险变高。 |
进行存储倾斜整改。 |
20% |
存储倾斜引发CPU、IO、内存倾斜，影响集群整体性能；倾斜磁盘超过90%的风险变高。 |
进行存储倾斜整改。 |
GaussDB(DWS)常见性能管理场景和建议
本节主要介绍常见的性能管理场景和建议手段，在业务上线和日常运维过程中，应当对性能容量进行充分评估，防止集群出现性能过载。
|
常见场景 |
性能风险 |
评估手段 |
建议措施 |
|---|---|---|---|
|
新集群上线 |
新集群在业务上线前的性能容量未知，有性能不达标风险。 |
需在业务上线前对集群进行充分压测，并双轨运行至少一个业务周期，关键业务/链路的qps、时延、最大并发量、最大响应时间等性能指标能够得到充分测试，从而确保新集群的性能容量能够得到充分评估。 |
参考GaussDB(DWS)资源负载管理配置动态资源管理并划分业务资源池，提前配置异常规则，配置熔断参数。 |
|
新业务上线 |
与集群现有业务出现资源争抢，新业务并发、资源消耗不合理时容易造成资源过载导致整体性能劣化。 |
新业务在测试环境得到充分测试，根据测试结果预估cpu消耗、执行时间、业务并发量等指标，分析新业务执行计划，确保执行计划最优。 |
当集群性能容量超过风险值时，应禁止新业务上线；当性能容量较为充裕时，新业务应通过资源池进行资源隔离，根据测试结果配置合理的熔断参数，并准备回退方案，确保出现问题后可快速回退。 |
|
灵活查询性能管理 |
灵活查询的SQL类型多样，执行效率和资源消耗差异很大，极端情况下可能会出现某一个“烂SQL”将整个集群性能拖垮的情况。 |
可根据topsql统计灵活查询的cpu消耗、内存消耗、执行时间、并发量等信息。 |
灵活查询用户应划分到独立于其他业务的资源池内，并进行CPU、内存等资源限制，并配置异常规则和熔断策略，及时拦截“烂SQL”，同时，建议遵循权限最小化原则，限制灵活查询用户的权限，禁止管理员用户作为灵活查询用户主账号。 |
|
存量业务增长 |
存量业务的数据量、并发量等持续增长，会造成集群资源使用率越来越高，不及时治理有过载风险。 |
定期统计存量业务的脏数据、倾斜率、analyze时间、分区个数、资源消耗情况等指标。 |
每周对集群进行定期巡检，定期对脏页率高的表进行脏数据清理，对统计信息不及时的表及时analyze。 |
