通过监控信息调优集群性能

CPU平均使用率增高

CPU平均使用率展示的是在某个时间点，多个节点的CPU平均使用率。CPU平均使用率增高，会影响集群的稳定运行，导致查询和写入的速度变慢。如果CPU平均使用率持续增高，表示集群存在较大的风险，需要尽快优化。

CPU平均使用率增高的常见原因如下：

• 查询

  查询导致的CPU使用率增高，可能是由于Bad SQL，例如SQL中包含了复杂的计算逻辑、处理大量的数据，或者JOIN没有JOIN条件，从而产生了笛卡尔积等。您可以通过一键诊断功能来定位存在问题的查询：

  • Bad SQL检测结果中，高耗时的SQL、数据读取量大的SQL、Stage个数多的SQL、最耗CPU的SQL，都可能导致集群的CPU使用率增高，需要根据自诊断结果或者执行计划进行进一步的分析。

  • 异常Pattern检测会从SQL模板的角度，对异常提交的Pattern进行检测，与Bad SQL类似，导致CPU增高的Pattern需要从数据读取量异常、消耗CPU异常、查询耗时异常等多个维度进行分析，这些异常Pattern的出现都可能导致CPU增高。

  • 如果是计算节点或存储节点CPU使用率增高的问题，可以结合一键诊断结果中的计算层检测和存储层检测中的异常算子检测来分析，异常算子中的算子详细信息和算子汇总信息中，都会从CPU消耗角度对异常算子进行了筛选和过滤。

• 写入

  写入过程也会消耗CPU资源（包括INSERT、UPDATE、DELETE、REPLACE、INSERT OVERWRITE、INSERT INTO SELECT），同样也会导致存储节点CPU使用率增高。此时需要观察删除TPS、写入TPS、更新TPS和LOAD_TPS等监控指标是否同样出现了突增。

  常见的写入导致CPU使用率增高原因如下：

  • 超长主键

    当主键非常长的时候，会导致查询的主键索引比较大，从而消耗较大的CPU资源。

  • DELETE SQL

    如果单个DELETE WHERE语句命中了较多行数据，计算引擎需要计算出所有行的主键，然后再逐个下发给存储节点进行删除操作。一个DELETE SQL操作步骤可能会放大很多倍，从而导致CPU使用率增高。

  • UPDATE SQL

    如果单个UPDATE WHERE语句命中了较多行数据，计算引擎需要计算出所有命中行的主键，并更新其对应的字段值，然后再逐个下发给存储节点进行标记旧行以及追加（Append）新行的操作。一个UPDATE SQL操作步骤可能会放大很多倍，从而导致CPU使用率增高。

  • INSERT OVERWRITE

    批量写入（Batch load）的过程中需要进行数据解析、按照聚集索引字段（如果有聚集键）进行排序（Sort）、构建主键索引和普通索引等操作，上述操作都属于CPU密集型操作（每个Shard需要一个线程进行上述工作）。目前虽然有批量写入并发数量限制（例如最多同时存在2个批量写入SQL），但是每个Shard需要一个线程进行批量写入相关操作，仍旧可能导致CPU使用率增高。

  • INSERT INTO SELECT

    短时间内大量数据写入，当后台Build任务堆积时会导致实时数据增多，此时查询如果涉及实时数据的话，数据库需要扫描大量实时数据（因为实时数据没有索引），最终导致CPU使用率增高。

• Build

  Build任务会对数据进行构建索引、建立和清除分区等操作，很可能会导致存储节点的CPU使用率增高。您可以在控制台对比CPU使用率和Build任务数的监控数据，可以较容易发现两个指标间的相关性。

  说明

  • 关于Build的介绍请参考BUILD。

  • 如何定位和分析Build导致的资源水位增高的问题，请参见Build任务数增多。

CPU最大使用率倾斜

CPU最大使用率展示的是在某个时间点，多个节点中CPU使用率最高节点的值。当CPU最大使用率和CPU平均使用率长时间相差较大时，说明集群内部存在任务处理不均匀的情况（有些节点计算量较大，有些节点计算量较小，最终导致CPU使用率倾斜）。CPU使用率倾斜严重（例如1倍以上），会较大地影响集群运行的稳定性，并且会导致资源浪费，因为分布式的查询子任务受到了CPU最大使用率的限制，而无法进一步的提升性能，只能升配解决，但是其他节点的CPU使用率并不高。

导致CPU使用率倾斜可能存在如下原因：

• 源表倾斜

  通常是建表时选择的分布键不均匀，导致不同Shard上的数据量存在较大差异。

  如下图所示，某个大表分布不均，存储节点0上的Shard_0和Shard_1中数据量较大，而在存储节点1上的Shard_2和Shard_3中数据量较小，那么当您查询这个大表时，较大概率会出现存储节点0需要处理的数据多，存储节点1上需要处理的数据少的情况，这样就会导致存储节点0的CPU使用率长期高于存储节点1的CPU使用率，最终导致CPU使用率倾斜。

  

  关于源表倾斜的诊断，请参见存储空间诊断。一键诊断也会检测占用磁盘空间较大的倾斜表，分析资源倾斜。

• 中间数据倾斜

  中间数据倾斜不同于源表倾斜。在中间数据倾斜的场景下，源表数据可能在各个Shard上是分布均匀的，但是Shard中包含的某个字段的值又是分布不均的。

  当您根据分布不均的字段来做分组聚合查询或者作为JOIN的条件，AnalyticDB for MySQL内部会根据这些字段对数据进行一次不同节点间的重分布，重新分布后，因为相关的字段值的数据会被分发到同一个节点上，就出现了字段分布不均的现象。

  如下图所示，某张表是根据a字段进行分布，因为a字段本身比较均匀，所以数据均匀地分布在不同的存储节点上，当您使用了b字段进行分组（group by b），那么存储节点1会将b字段值为b1的数据行分发到计算节点1，为确保计算节点1具有所有b字段值为b1的行，存储节点2会把b字段值为b1的数据分发到计算节点1，值为b2的数据分发到计算节点2。因此，计算节点1具有的数据行远大于计算节点2，就产生了数据倾斜，对于后续的计算任务，计算节点1就需要消耗较多的集群资源。

  

  针对中间数据倾斜导致的CPU使用率不均匀，您可以通过分析查询的Stage级别诊断结果进行问题定位。

磁盘IO吞吐增高

磁盘IO吞吐表示底层存储介质的吞吐消耗，单位MB/s。磁盘IO吞吐的最高值请参见ESSD云盘。由于该上限值是理想状态下的测试值，与集群实际的负载情况不完全相符，一般实际负载可能能够达到该标称值的80%左右。

磁盘IOPS增高

磁盘IOPS表示底层存储介质每秒的IO次数，磁盘IOPS的最高值请参见ESSD云盘。由于该上限值是理想状态下的测试值，与集群实际的负载情况不完全相符，一般实际负载可能能够达到该标称值的80%左右。

计算内存使用率增高

分析型数据库在进行大量数据计算时，会消耗较多的内存资源。消耗内存较高的SQL一般包含Aggregation算子、TopN算子、Window算子以及Join算子：

• Aggregation算子

  Aggregation算子消耗内存较高主要是因为AnalyticDB for MySQL在进行数据的分组时，会把分组信息暂存在内存中，如果分组字段唯一值较多，那么就会在分布式聚合的Final阶段消耗较多的内存资源（Partial阶段因为不需要进行全局的聚合，各个节点完成部分数据的局部聚合就可以将数据发送到下游节点，所以Partial阶段消耗的内存不大）。

• TopN算子

  AnalyticDB for MySQL在进行TopN计算时（例如SQL中有ORDER BY id LIMIT m,n），当m较大时，AnalyticDB for MySQL中的TopN算子会缓存较多数据在内存中，以完成最终的全局排序，这个过程会消耗较多的内存资源。

• Window算子

  Window算子用于计算窗口函数。为了达到语义的最终结果，和Aggregation算子类似，同样需要暂存较多的数据到内存中。

• Join算子

  AnalyticDB for MySQL支持标准的Join查询操作，系统内部实现Join过程一般使用Hash算法和Index算法，更多介绍，请参见算子。Hash算法会将小表（Build表）缓存到内存中，并在内存中为Build表构建一个Hash表，加速Join的过程。以下原因可能导致Hash表占用较多内存：

  • Build表本身较大：

    AnalyticDB for MySQL会根据统计信息评估Join操作两边的表的大小，以较小的表作为Build表，但不排除Build表仍然较大。

  • 统计信息过期或者统计信息评估不准

    当Join操作的两表不是源表，而是经过了多次的聚合、过滤、其他Join等计算后，基于源表的统计信息很难准确统计两表的大小。或者当统计信息过期，没有及时更新，也会错误选择了较大的表作为Build表，并为其构建Hash表。更多介绍，请参见统计信息。

  • Left Join

    由于语义的原因，Left Join的右表一定要用来构建Hash表，以达到正确的语义结果。如果Left Join的右表较大，就会导致本次Join操作占用较大内存。

更多这些算子的介绍，请参见算子。

当包含这些算子的SQL并发较高，或者单算子占用较高的内存，那么计算内存使用率指标就会增高，影响集群的稳定性，并且导致查询报错，常见报错如下：

• Query exceeded reserved memory limit：某个查询在单个节点上使用内存超过限制。

• Query exceeded system memory pool limit：单个字段过长或参与计算的列过多。

• Out of Memory Pool size pre cal. avaliable：物理内存池耗尽。

• The cluster is out of memory, and your query was killed：集群内存不足时，会终止当前正在运行的最大的一个查询。

如果要降低计算内存使用率，您需要对包含这些算子类型的SQL进行调优，具体操作请参见算子级别诊断结果。

Build任务数增多

Build主要完成对写入的数据进行构建索引、清理过期数据、执行异步DDL任务等，将数据从写优化转变为读优化。Build任务在某些情况下会消耗较高的存储节点CPU资源以及磁盘IO资源，可能会影响到其他操作，导致出现集群稳定性问题。关于Build指标的说明如下。

集群的Build任务数增多并影响到读写节点CPU使用率，可以从以下几个方面进行定位和分析：

• 分区表的单分区较大。单分区较大时，这类大分区被写入、更新或者删除概率较大，更容易触发分区被Build。您可以通过存储空间诊断来定位这些类型的表，进行表结构的优化。

• 过大的非分区表。当非分区表较大时，也更容易被写入、更新或者删除，也更容易触发全表Build。

• 大量的读写请求导致存储节点CPU持续较高，进而导致Build执行过慢。

节点掉线个数增多

当AnalyticDB for MySQL集群内部的节点无法提供服务时，会存在节点掉线的情况，节点掉线对于集群的稳定运行有较大的危害，会导致查询和写入变慢，也会导致查询报错。节点掉线时，您可以分析CPU使用率是否持续增高、IO相关指标是否持续打满等。

P95曲线

AnalyticDB for MySQL对CPU使用率、接入节点CPU使用率、计算内存使用率、磁盘IO吞吐、磁盘IOPS、磁盘IO使用率、磁盘IO等待时间等监控指标增加了P95监控曲线。P95指标即95%的指标小于等于该值。以计算节点CPU使用率为例，假设集群有100个计算节点，在某个时间点，将所有节点的CPU使用率按照升序排列，第95个计算节点的CPU使用率即计算节点P95 CPU使用率。

最大值、平均值与P95有以下区别：

• 最大值单纯指出数据的上限，在存在异常值或者极端值的情况下，监控指标最大值会被这些个别值所影响，不能很好地代表数据集的一般水平或典型情况。

• 平均值旨在描述数据的集中趋势，但在数据集存在异常值或倾斜分布时，也不再能准确反映数据的一般状态。

• P95则是关注的较高部分数据的表现，忽略了最极端的数据点，适合评估大部分情况下的性能或水平。

查询响应时间增长

查询响应时间指标表示查询从提交、排队到真正执行结束的时间，关于AnalyticDB for MySQL中耗时的说明，请参见监控FAQ。

当集群的查询响应时间突然增高，可能存在如下原因：

• Bad SQL

  Bad SQL会占用较多的集群资源，影响其他正常SQL的执行。

• 异常Pattern

  有时某个SQL消耗的资源并不大，但是这类SQL出现的次数较多；或者某些SQL资源消耗较大，导致整个集群处理任务的性能出现瓶颈，最终影响其他查询，使整体查询响应时间增高。

• 写入量增大

  写入量增大会占用较多的CPU资源、磁盘IO资源，触发更多的Build任务，最终会导致整体的查询响应时间增加。

您可以在控制台的监控信息页面，选择查询响应时间增高的时段，发起一键诊断，根据各项诊断结果分析具体原因。

查询等待时间增长

当查询提交到集群的接入层节点后，集群会根据接入层队列的大小设置，检查查询是否需要排队，防止同一时间段执行的SQL太多，导致集群压力增大，从而影响整体稳定性。更多介绍，请参见并发控制。

当查询的等待时间突然出现增高的情况，通常是因为集群内部执行效率降低导致，例如出现Bad SQL或者异常Pattern，导致占用了大量的集群资源。您可以通过一键诊断，查看多维度Bad SQL检测结果和异常Pattern检测结果。写入数据量增大，导致占用了较多的存储节点CPU资源和IO资源也会导致查询等待时间增高。

查询失败率增多

查询失败率仅统计失败查询的占比，不会统计查询失败原因。导致查询失败可能有多种原因，常见原因和处理方法如下：

• SQL存在问题导致查询失败

  • 语法错误

    SQL不符合AnalyticDB for MySQL官方对SQL语法的定义，通常在SQL语法解析阶段报错。例如，SQL不完整、格式错误、关键字缺失、标点符号缺失等。

  • 语义错误

    SQL符合AnalyticDB for MySQL官方对SQL语法的定义，但在语义检查时，发现数据库对象错误，在语义分析阶段报错。例如，表名错误、列不存在、GROUP BY字段缺失、函数参数类型错误等。

• 集群内部问题导致查询失败

  • 查询超时

    AnalyticDB for MySQL有默认的查询超时时间。您也可以根据实际业务需求来配置查询超时时间，如果查询执行时间超过了该时间，将会查询失败。

    说明

    • 默认查询超时时间的介绍，请参见使用限制。

    • 修改查询超时时间的方法，请参见Config和Hint配置参数。

  • 集群压力较大

    当集群出现较大压力时，内部节点通信超时或者内部进程无法服务都会导致查询失败。

• Readonly

  当系统发现Raft Log出现问题时，会直接将进程状态置为Readonly，此时写入操作会出现报错。

• Timeout

  当系统无法即时消费Raft Log Queue（例如有超长主键导致写入慢等），此时会出现反压，最终导致写入速度变慢，出现Timeout报错。

表读取结果数据量

AnalyticDB for MySQL的数据会存储在不同的存储节点上。表读取结果数据量展示某个时间点，多个存储节点上所有SQL查询从存储层返回到计算层的数据量。

如下图所示，在某个时间点（Time_1），假设共有6条SQL语句（query1、query2、query3、query4、query5、query6）分别从6张表（user、report、customer、test、region、partition）中读取数据。在该时间点，表读取结果数据量为20.1 GB（计算方法为：1.6+2+3+0.7+4.8+8=20.1 GB）；表平均读取结果数据量为6.7 GB（计算方法为：所有存储节点读取的数据量/存储节点个数，即(1.6+2+3+0.7+4.8+8)/3=6.7 GB）；表最大读取结果数据量为12.8 GB（计算方法为：4.8+8=12.8 GB）。

表读取结果数据量、表最大读取结果数据量和表平均读取结果数据量能在一定程度上反映SQL查询对集群的压力。

• 当表平均读取结果数据量突然增加时，说明存储层中有较多的数据被发送到计算层进行处理，消耗更多的CPU资源和内存资源。同时，从存储层读取的数据量增加，也会占用更多的磁盘IO资源。

• 当表最大读取结果数据量和表平均读取结果数据量相差较大时，说明从多个存储节点读取的数据量存在差异，节点处理的数据量不同会导致某些节点过早地达到资源瓶颈，进而影响集群的整体性能。这种情况通常源于表设计的不合理，例如某些表选择了不均匀的分布字段，导致数据在多个存储节点上的分布不均。

写入、删除、更新的响应时间增长

写入响应时间表示INSERT INTO VALUES操作处理每行数据的响应时间；删除响应时间表示DELETE操作处理每行数据的响应时间；更新响应时间表示UPDATE操作处理每行数据的响应时间。响应时间一般会受到以下因素的影响：

• 存储节点CPU使用率增高

  存储节点CPU使用率增高可能受到其他指标增高的影响，例如集群出现了Bad SQL，或者写入（删除/更新）的TPS增加等。

• 存储节点写相关IO指标增高

  存储节点写相关IO指标包括磁盘IO吞吐量和磁盘IOPS等，这些指标增高的可能原因如下：

  • Build任务数增加所致。

  • 执行了备份、扩容等操作。

  因为以上操作都需要对磁盘进行写入操作，所以可能会影响相关的响应时间。