Hologres管控台的监控指标

实例CPU使用率（%）

实例CPU指实例整体的CPU使用率，代表实例的计算负载情况。

• 在没有查询的时候，后台常驻进程或者异步执行的Compaction都可能占用CPU，因此实例无查询负载时，有少量CPU使用率是正常现象。

• Hologres因其设计原理可以充分发挥多核并行计算的能力，通常来说单个查询可以迅速将CPU使用率提高到100%，这说明计算资源得到了充分利用。

• 当实例CPU使用率长期接近100%时（例如CPU使用率连续3小时满载100%，或者连续12小时达到90%以上等），说明实例负载非常高，这通常意味着CPU资源成为了系统的瓶颈，需要分析具体的业务场景和查询，以判断原因。可以从以下几方面判断：

  • 是否有比较大的离线数据导入（INSERT），且数据规模还在日渐增长。

  • 是否有高QPS的查询或写入，共同占用了CPU的全部资源。

  • 是否有上述或上述场景以外的混合负载。

• 如果确定是业务场景需要，将资源用满，可以对实例进行扩容，以适应更复杂的查询或更大的数据量。

Worker节点CPU使用率（%）

Worker节点CPU指实例内每个Worker的CPU使用率，代表每个Worker的计算负载情况。Hologres根据实例规格，提供不同的Worker节点数，详情见实例规格概述。

• 当前指标只有Hologres V1.1及以上版本支持显示。

• 当实例内所有Worker节点CPU使用率都长期接近100%时，说明实例的负载非常高，需要根据业务情况合理的优化资源使用或者扩容。

• 当实例只有部分Worker节点的CPU水位比较高，部分Worker节点的CPU水位较低时，说明Worker资源有倾斜，常见倾斜原因以及排查方法请参见监控指标常见问题。

实例内存使用率（%）

实例内存使用率代表实例整体的内存综合使用率。

• Hologres的内存资源采用预留模式，在没有查询的时候，也会有数据表的元数据、索引、数据缓存等加载到内存中，以便加快检索和计算，此时内存使用率不为零是正常情况。理论上，在无查询的情况，内存使用率达到30%~40%左右都属于正常情况。

• 当内存使用率稳定增长，长期接近80%时，通常意味着内存资源可能成为了系统的瓶颈，可能会影响实例的稳定性或性能。

• 可以根据实例内存分布使用率，并结合业务的QPS等指标综合判断谁占用了较高的内存，从而做相应的优化。详情可以参见OOM常见问题排查指南。

Worker节点内存使用率（%）

Worker节点内存使用率指实例内每个Worker的内存使用率，代表每个内存的计算负载情况。Hologres根据实例规格，提供不同的Worker节点数，详情见实例规格概述。

• 当前指标仅Hologres V1.1及以上版本支持显示。

• 当实例內所有Worker节点的内存水位都长期接近80%时，说明实例的负载非常高，需要根据业务情况合理的优化资源或者扩容。

• 当实例只有部分Worker节点内存水位比较高，部分Worker节点内存水位较低时，说明Worker资源有倾斜，常见倾斜原因以及排查方法请参见监控指标常见问题。

实例中内存的详细使用率（%）

在Hologres中，内存会分为系统（system）、元数据（meta）、缓存（cache）、计算（query）、后端进程（background）等几个部分。从V2.0.15版本开始，支持实例内存分布使用率的监控指标，可以通过该指标查看内存的分布情况，从而进行针对性优化。主要包括以下指标：

• System：系统内存，指系统组件运行时占用的内存，组件包括Holohub、Gateway、FE（Frontend）等，其中FE会包括FE Master和FE Query，因此System内存也会随着Query的运行而波动。

• Cache：缓存占用的内存，缓存的内存主要包括：

  • SQL相关的缓存：例如result cache、block cache等，与SQL有关，根据Query运行状态动态变化。如果SQL有命中缓存（例如通过explain analyze查看Physical read bytes字段，数据越小说明缓存命中率越高），将会提升查询性能。但SQL的缓存也有一定的上限。

  • Meta缓存：包括表的Schema Meta、文件Meta等，为了Query的高效执行，Hologres的存储引擎会预先将Meta相关的数据加载进缓存中，从而减少Meta的冷访问，提升查询性能。

  • 缓存有固定大小，一般占用实例总内存的30%左右。当实例没有查询负载时，也会存在一定的缓存占用，主要是Meta占用的缓存。

• Meta：元数据、文件等占用的内存，元数据的内存使用采用Lazy Open模式，即频繁被访问的元数据会常驻内存中，未被访问的元数据则不会放在内存中，以此来减少元数据对内存的占用。一般建议Meta占用的内存维持在总内存的30%以内。如果Meta占用的内存较高，说明实例中访问的文件数较多，或者分区表较多，可以通过表统计信息查看与分析对实例中的表做相关治理。

• Query：代表执行SQL时消耗的内存，与Query的复杂度、并发度等正相关。主要包括Fixed Plan、HQE、SQE等执行SQL消耗的内存。

  • Query计算的内存会采用弹性机制，即单个Worker最低使用20 GB，最高使用根据实例的总空闲内存浮动，其他分类中内存占用越多，会导致计算部分弹性的内存越少。

  • 如果Query占用的内存较多，甚至出现了OOM的现象，说明Query较复杂或者并发度较高，建议对Query调优或者对实例扩容，以避免实例高水位运行，详情请参见优化内部表的性能。

• Background：后台任务占用的内存，包括Compaction、Flush等任务，一般Background消耗的内存较少，约在5%以内。但如果对表修改了索引、执行了大量的写入或更新等操作，Background的内存占用将会上升，并随任务的结束而下降。

• Memtable：内存表占用的内存，在Hologres中Memtable（内存表）主要用于存储有实时写入、更新、删除等操作完成之后的表数据。一般Memtable的内存占用在5%以内。

QE Query内存使用量（byte）

指实例中使用了HQE、SQE等Hologres自研引擎XQE的Query，在运行过程中的内存使用量。

• 该指标仅Hologres V2.0.44及以上版本、V2.1.22及以上版本支持显示。

• 在内存细分类中，Query的内存使用量大于QE Query内存使用量。

通过QE Query内存使用量可知该实例中运行的Query复杂度，如果内存使用量较多，说明Query比较复杂，使用的内存较多。

QE Query内存使用率（%）

QE Query内存使用率可以判断当前实例的负载情况，如果QE内存使用率较高，可能因内存不足而导致OOM，需要治理Query或者扩容。

该指标仅Hologres V2.0.44及以上版本、V2.1.22及以上版本支持显示。

Query QPS（countS）

Query QPS代表实例中平均每秒SQL语句的执行次数，为实例内总的QPS。包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL语句。Query QPS >= QE Query + FixedQE Query QPS。

QE Query QPS（countS）

指实例内使用QE引擎的Query每秒执行的次数。包括SELECT、INSERT、UPDATE和DELETE四种类型的SQL语句。

该指标仅Hologres V2.2及以上版本支持显示。

FixedQE Query QPS（countS）

指实例内使用FixedQE引擎的Query每秒执行的次数（走Fixed Plan链路，原名SDK）。包括SELECT、INSERT、UPDATE和DELETE四种类型的SQL语句。

该指标仅Hologres V2.2及以上版本支持显示。

DML RPS（countS）

DML RPS代表实例内Query每秒导入或者更新的数据记录条数，包括INSERT、UPDATE和DELETE三种类型的SQL语句，因此DML RPS = QE DML RPS + FixedQE DML RPS。

QE DML RPS（countS）

指实例内使用QE引擎的Query每秒导入或者更新的数据记录条数，包括INSERT、UPDATE和DELETE三种类型的SQL语句。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 使用QE引擎导入或更新数据的常见场景如下：

  • MaxCompute或OSS外部表的批量导入或更新。

  • Copy批量写入或更新。

  • Hologres表之间的批量导入。

FixedQE DML RPS（countS）

指实例内使用FixedQE引擎的Query每秒导入或者更新的数据记录条数（原指标名为SDK），包括INSERT、UPDATE和DELETE三种类型的SQL语句。其中：

• 该指标仅Hologres V2.2及以上版本支持显示。

• 常见的FixedQE场景包括：

  • 通过Flink实时写入。

  • 通过Holo-Client写入。

  • Spark的数据写入至Hologres。

  • 实时同步MySQL Binlog的数据至Hologres。

  • 实时同步DataHub的数据至Hologres。

  • 通过数据集成DataX离线写入。

  • SQL或JDBC通过INSERT INTO VALUES()语句写入。

Query延迟（milliseconds）

实例内运行的所有Query的平均延迟，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL语句。Query延迟 >= MAX（QE Query延迟，FixedQE Query延迟）。

QE Query延迟（milliseconds）

实例内使用QE引擎的Query的平均延迟，包括SELECT、INSERT、UPDATE和DELETE四种类型的Query。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 对于QE Query的延迟增加排查，可以结合Optimization耗时、Start Query耗时、Get next耗时、QE QPS等指标一起排查。

FixedQE Query延迟（milliseconds）

实例内使用FixedQE引擎的Query的平均延迟，包括SELECT、INSERT、UPDATE和DELETE四种类型的Query。

• 该指标仅Hologres V2.2及以上版本支持显示。

• FixedQE Query延迟高可能是如下原因：

  • 偶发变高：可能是因为存在HQE锁，可以查看FixedQE的后端拿锁耗时是否增加，若增加说明有锁，可以通过Query洞察排查具体的拿锁Query。

  • 一直延迟高：可能是因为建表不合理，或着受其他复杂Query的影响等，可以参考Blink和Flink常见问题及诊断进行排查。

Optimization阶段的耗时（milliseconds）

实例内Query在Optimization阶段的耗时，该阶段主要用于优化器QO解析SQL，并生成对应的物理Plan以便执行引擎跟进Plan去执行。

• 该指标仅Hologres V2.0.44及以上版本、V2.1.22及以上版本支持显示。

• 如果Optimization阶段耗时较长，说明实例中Query较复杂，导致解析Query耗费较多时间。如果实例中的Query只是传入的参数不同，建议使用Prepared Statement模式降低QO耗时，详情请参见JDBC。

Start Query阶段的耗时（milliseconds）

实例内Query在Start Query阶段的耗时，该阶段为真正开始执行Query前的初始化阶段，包括了加锁，对齐Schema版本等过程。

• 该指标仅Hologres V2.0.44及以上版本、V2.1.22及以上版本支持显示。

• 如果Start Query阶段耗时较长，通常是由于等待锁或者高CPU占用导致资源等待，可以结合执行计划等细致分析。

Get next阶段的耗时（milliseconds）

Get next是指从Start Query阶段结束开始计算，到所有结果均返回所花费的时间，包括计算、返回结果等步骤的耗时。

• 该指标仅Hologres V2.0.44及以上版本、V2.1.22及以上版本支持显示。

• 如果Get next阶段耗时较长，通常是由于计算复杂导致，可以结合QE内存使用、QE QPS等指标一起排查。如无明显异常，也可能是客户端在等待返回数据。

Query P99延迟（milliseconds）

实例内运行的所有Query的P99延迟，包括SELECT、INSERT、UPDATE和UTILITY、以及系统Query等。

本实例正在运行中Query最长的时长（milliseconds）

指实例中正在运行的Query持续时长，默认汇报当前时刻运行时间最长的Query时长，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL语句。

• 该指标仅Hologres V1.1及以上版本支持显示。

• Hologres是分布式系统，根据实例的规格会有不同的Worker节点。Query运行时会在不同的Worker节点随机分发。正在运行的Query持续时长会根据每个Worker节点上Query运行时长，汇报当前时刻运行时间最长的Query，例如当前时刻不同的Worker节点分别在运行持续时长为10分钟、5分钟和30秒的Query，此时正在运行的Query持续时长将会显示为10分钟。

• 可以根据Query的运行时长，并结合活跃Query或者慢Query日志判断Query运行时长是否合理，排查并解决Query运行时间较长的问题，及早处理死锁、卡住等情况。

失败Query QPS（milliseconds）

失败Query数代表实例内平均每秒SQL语句失败的次数，包括SELECT、INSERT、UPDATE和DELETE、UTILITY、UNKNOWN等SQL语句。失败Query QPS <= QE 失败Query QPS + FixedQE 失败Query RPS。

可以根据失败的Query类型和次数，在慢Query日志中查找失败的Query并分析原因，以提高系统的可用性。

QE失败Query QPS（milliseconds）

指实例内使用QE引擎的Query每秒失败的次数。包括SELECT、INSERT、UPDATE和DELETE四种SQL语句。

该指标仅Hologres V2.2及以上版本支持显示。

FixedQE失败Query QPS（milliseconds）

指实例内使用FixedQE引擎的Query每秒失败的次数。包括SELECT、INSERT、UPDATE和DELETE四种SQL语句。

该指标仅Hologres V2.2及以上版本支持显示。

FE等锁的最大耗时（milliseconds）

Hologres是分布式系统，会有多个FE节点负责SQL的解析、分发及路由。当不同的连接请求被路由到同一个FE节点，并对同一个表做DDL操作（如CREATE、DROP）时，会产生FE锁。FE等锁耗时反映了每个FE等待DDL锁的耗时。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 一般来说，只要执行DDL操作就可能会产生锁耗时，FE锁耗时超过5分钟，同时“FE replay延迟”指标也出现较高的延迟，可能是因为有DDL执行卡住了，通过Query管理排查运行时间较长的Query并及时终止该进程。

FixedQE的后端拿锁耗时（milliseconds）

对于INSERT、DELETE或UPDATE等类型，走HQE链路的Query会使用表锁，走FixedPlan链路的Query会使用行锁。FixedQE的后端拿锁表示走FixedPlan链路的Query涉及到的表被加了行锁，同时走HQE链路的Query对该表加了表锁，导致FixedPlan的Query需要等锁，进而导致FixedQE拿锁耗时增加。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 如果FixedQE的拿锁耗时较长，可以通过慢Query日志定位到比较慢的FixedQE Query，然后通过Query洞察排查拿锁的HQE Query。

实例总的后端拿锁耗时（milliseconds）

表示INSERT、DELETE或UPDATE类型的Query在实例中总的拿锁耗时，包括FixedQE的拿锁耗时和HQE Query之间的拿锁耗时。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 如果拿锁耗时较长，可以通过慢Query日志定位到比较慢的INSERT、DELETE或UPDATE类型的Query，再通过Query洞察排查拿锁的HQE Query。

总连接数（个）

Hologres根据实例的规格，设置不同的默认总连接数，详情请参见实例规格概述。总连接数代表实例当前已经使用的连接总个数，包括active（活跃）、idle（空闲）、idle in transaction（已失败事务中的空闲状态）等连接状态。可以通过Query管理查看当前的连接使用情况，当出现连接不足时，及时kill空闲连接。

连接数（按DB展开）（个）

按照DB汇总的连接数使用个数，判断每个DB的连接使用情况。其中：

• 每个DB的总连接数上限默认是128，详情请参见实例规格概述。

• 当每个DB的连接数长期接近最大值时，说明实例的连接数使用较多，可以根据业务情况查看是空闲连接还是业务连接，详情请参见连接数管理，并根据业务情况及时清理空闲连接或者扩容获取更多的连接。

• 当部分Worker节点连接数较高，部分Worker节点的连接数较低时，说明实例的连接负载不均，通过连接数管理查看空闲连接并及时清理，以缓解连接负载不均的情况。

连接数（按FE展开）（个）

按照FE汇总的连接数使用个数，判断每个FE的连接使用情况。其中：

• 每个FE节点的总连接数上限默认是128，详情请参见实例规格概述。

• 当每个FE节点的连接数长期接近最大值时，说明实例的连接数使用较多，可以根据业务情况查看是空闲连接还是业务连接，详情请参见连接数管理，并根据业务情况及时清理空闲连接或者扩容获取更多的连接。

• 当部分Worker节点连接数较高，部分Worker节点的连接数较低时，说明实例的连接负载不均，通过连接数管理查看空闲连接并及时清理，以缓解连接负载不均的情况。

连接数使用率最高的FE的连接数使用率（%）

代表使用率最高的FE（Frontend）节点的使用率，汇报每个FE节点的最大值，即Max(frontend_connection_used_rate)，可以更加方便的知道使用的连接数是否即将超过某个Frontend节点的最大连接数，造成无法连接的情况。多个FE节点之间采用轮训策略（Round Robin），新建连接依次与不同Frontend节点建立物理连接。可以通过Query管理查看当前的连接使用情况，当出现连接不足时，及时kill空闲连接。

标准IO读吞吐（byte/s）

代表Query读取标准存储数据时的I/O吞吐。

标准IO写吞吐（byte/s）

代表Query写入标准存储数据时的I/O吞吐。

低频IO读吞吐（byte/s）

代表Query读取低频存储数据时的I/O吞吐。

低频IO写吞吐（byte/s）

代表Query写入低频存储数据时的I/O吞吐

标准存储已用容量（byte）

标准存储已经使用的存储容量，若超过购买的存储容量，可以适当扩容存储。

标准存储使用率（%）

标准存储已经使用的存储使用率，若超过购买的存储容量，可以适当扩容存储。

低频存储已用容量（byte）

低频存储已经使用的存储容量，若超过购买的存储容量，可以适当扩容存储。

低频存储使用率（%）

低频存储已经使用的存储使用率，若超过购买的存储容量，可以适当扩容存储。

FE replay延迟（milliseconds）

Hologres为分布式系统，在接入层有多个Frontend（FE）负责SQL的解析、分发、路由。对于DDL，Hologres的原理是先在一个FE执行，然后其余FE节点replay。其中：

• FE replay需要一定的时间，一般来说，Relay延迟在毫秒级、秒级都为正常情况。

• 当某个FE replay的延迟超过分钟级时，可能是由于DDL太多，replay不及时；若是延迟一直增加，可能是Query卡住了，可以通过hg_stat_activity排查耗时较高的Query，并及时Kill。

• 该指标仅Hologres V2.2及以上版本支持。

Shard多副本同步延迟（milliseconds）

Shard多副本延迟是指实例开了Replication后，主从Shard之间的副本数据同步延迟。

• 通常Shard多副本延迟为毫秒级。

• 当有大量数据写入、更新或频繁执行DDL操作时，可能会导致同步延迟。

主从同步延迟（milliseconds）

主从实例同步延迟表示从实例读取主实例数据时的延迟（毫秒），其中：

• 仅从实例显示该指标，主实例默认不显示。

• 只有在从实例绑定了主实例之后，该指标才会显示数据（0ms），当主实例有数据写入时，从实例的同步延迟会出现数据波动。

• 通常情况下，主从实例的同步延迟为毫秒级，当实例偶尔出现延迟抖动时，可能原因为主实例在做DDL等元数据修改的操作，可忽略。若长期延迟较大（大于秒），可能原因为实例水位较高，资源不足，您可以结合CPU、内存等水位情况综合评估，并适当扩容以减少延迟。

• 实例重启或者升级期间，同步延迟可能增加到分钟级别，并会自动恢复。

实例间文件同步延迟（milliseconds）

指异地容灾实例间的文件同步延迟，仅在Follower实例（只读从实例）上展示该指标。

每个DB统计信息缺失的表个数（countS）

代表每个DB中，统计信息缺失的表的个数。

• 该指标仅Hologres V2.2及以上版本支持显示。

• 对于Hologres V2.0及以上版本的实例，会默认开启新版本Auto Analyze机制，当表刚创建或者有大量数据写入或更新时，Auto Analyze可能未及时更新统计信息，可以先暂时观测一段时间。

• 如果某个DB长期（超过数小时或数天）有缺失统计信息的表，可能是因为未达到Auto Analyze的阈值，可以查看表的统计信息，并手动对表执行Analyze。详情请参见ANALYZE和AUTO ANALYZE。

正在运行的Serverless Computing的查询中，最长的时长（milliseconds）

Hologres支持Serverless Computing，可以将指定的Query运行在Serverless Computing资源池中，隔离本实例以及任务，确保Query快速运行。

• 该指标仅Hologres V2.1及以上版本支持显示。

• 该指标反映了Query在Serverless Computing的运行时长，默认展示运行时间最长的Query的时长，同时结合hg_stat_activity定位Query在Serverless的运行情况。

每秒消费Binlog的条数或字节数

Hologres支持订阅Hologres Binlog功能，通过Binlog可以实现数据的实时分层，加速数据流转。

wal sender的使用数和使用率

同普通连接类似，在使用JDBC进行Binlog的消费时，所消费的每张表的每个Shard都会使用1个Walsender连接，Walsender连接与普通连接独立，互不影响。Walsenders数有默认上限。

结合上述两个指标，可以判断当前实例中Walsender的使用情况，若Walsender到达上限，可以通过JDBC消费Hologres Binlog排查并处理。