Vertica 监控最佳实践

编译：JiangChong

原文：Best Practices for Monitoring Vertica（2023-06-28）

📝 文章说明：本文基于 Vertica 官方 KB 原文翻译整理。原文发布于 2023 年 6 月，仅讨论了 Enterprise 模式的 10 大监控领域，未涉及 Eon 模式（计算-存储分离架构）的专属监控。译者根据当前 Vertica Eon 技术架构与 vault 已有运维经验，补充了 Eon 模式监控内容（☁️ 标注），分散融入系统健康（§1）、资源使用（§2）、恢复（§5）、重平衡（§6）、DC 表（§10）各章节，并在第 11 节集中介绍 Eon 特有的 Depot 缓存命中率、公共存储延迟和架构对比速查。

关联：Vertica 维护前准备 Checklist（监控发现问题后的执行动作）| K-Safety 最佳实践

概述

本文档帮助监控 Vertica 数据库，按查询执行类别分类，覆盖以下 11 大领域。Eon 模式差异以 ☁️ 标注分散融入各章节，第 11 节集中介绍 Eon 特有的 Depot/公共存储监控：

1. 系统健康（☁️ 含分片订阅状态）
2. 资源使用（☁️ 含子集群资源隔离）
3. 活跃会话
4. 活跃事务/查询
5. 恢复（☁️ Eon 恢复机制差异）
6. 重平衡（☁️ Eon REBALANCE_SHARDS 差异）
7. 历史活动
8. 对象统计
9. 查询性能
10. Data Collector 表（☁️ 含 Eon 专属 DC 表）
11. Eon 模式专属监控（Depot 命中率、公共存储延迟、架构对比速查）

---

1. 系统健康

监控节点状态

节点处于 DOWN 状态时，不参与该时间点之后提交的任何事务。务必持续监控节点状态。

SELECT node_name, node_state FROM nodes ORDER BY 1;

输出示例：

node_name      | node_state
---------------+------------
v_demo_node0001 | UP
v_demo_node0002 | INITIALIZING
v_demo_node0003 | UP
(3 rows)

也可以通过 Management Console 查看可视化概览：

如果节点 DOWN，先尝试重启。排查参考「What Should I do When the Database Node is Down?」和 KB 文章「Node Recovery in Vertica」。

监控 Epoch 状态

AHM（Ancient History Mark）指向可被物理清除的历史数据的时间点。AHM 负责清理 delete vector。 Epoch 状态反映集群健康度。

SELECT current_epoch, ahm_epoch, last_good_epoch,
       designed_fault_tolerance, current_fault_tolerance,
       wos_used_bytes, ros_used_bytes
FROM system;

或简化版：

SELECT get_ahm_time(), get_ahm_epoch(), get_last_good_epoch(),
       get_current_epoch(), sysdate;

关注要点：

• designed_fault_tolerance 和 current_fault_tolerance 是否一致？
• ahm_epoch 是否接近 last_good_epoch？如果相差很远 → AHM 未推进
• WOS/ROS 使用量
• 默认 AHM 配置是将 AHM 尽可能靠近当前时间；如果 AHM 时间超过 14 天前，联系 Vertica 技术支持

监控 Delete Vector

DELETE 或 UPDATE 语句会创建 delete vector。数量过多会严重影响性能。

-- 系统级总数
SELECT COUNT(*) FROM v_monitor.delete_vectors;

-- 按投影看哪些表的删除行比例 > 5%
SELECT node_name, schema_name, projection_name,
       total_row_count, deleted_row_count, delete_vector_count
FROM storage_containers
WHERE deleted_row_count > total_row_count * 0.05
ORDER BY deleted_row_count DESC;

大量 delete vector 表示集群处于异常状态。处理参考 Vertica 数据删除最佳实践。

监控 ROS Container 数量

Vertica 每个投影的 ROS container 上限为 1024。数量过大会影响性能。

SELECT node_name, projection_schema, projection_name,
       SUM(ros_count) AS ros_count
FROM v_monitor.projection_storage
GROUP BY node_name, projection_schema, projection_name
ORDER BY ros_count DESC;

超过 500 通常意味着 PARTITION BY 设计有问题，或 merge 过程未正常运作。详见 Vertica 分区表常见问题。

☁️ Eon 模式：监控分片订阅状态

Eon 模式下，分片订阅（Shard Subscription）替代 buddy projection 保障数据冗余。任何分片失去所有订阅者时，集群立即进入 READONLY 模式，其重要性等同于 Enterprise 模式的 current_fault_tolerance 检查。

-- 巡检：按子集群汇总非 ACTIVE 状态的订阅
SELECT subcluster_name AS subcls,
       subscription_state AS state,
       COUNT(DISTINCT n.node_name) AS nodes,
       COUNT(DISTINCT shard_name) AS shards
FROM nodes n
LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name = ns.node_name)
WHERE subscription_state != 'ACTIVE'
GROUP BY 1, 2
ORDER BY 1, 2;

告警规则：返回任何行都需要关注。UNSUBSCRIBED 状态需立即处理。

每个分片的订阅者数：K=1 集群每个 shard 应有 ≥2 个 ACTIVE 订阅者。

SELECT shard_name, COUNT(*) AS subscriber_count
FROM v_catalog.node_subscriptions
WHERE subscription_state = 'ACTIVE'
GROUP BY shard_name ORDER BY subscriber_count;

来源：NODE_SUBSCRIPTIONS。完整的分片订阅监控内容见 §11.2。

---

2. 资源使用

监控 Resource Pool

SELECT sysdate AS current_time, node_name, pool_name,
       memory_inuse_kb, general_memory_borrowed_kb, running_query_count
FROM resource_pool_status
WHERE pool_name IN ('general')
ORDER BY 1, 2, 3;

查看哪个节点慢、哪些查询在运行或停止。也可查内存消耗大的查询：

SELECT * FROM resource_acquisitions
ORDER BY memory_inuse_kb DESC LIMIT X;

监控资源队列

SELECT * FROM v_monitor.resource_queues;

显示各资源池的待处理请求，position_in_queue 表示排队位置。

监控资源请求拒绝

SELECT * FROM v_monitor.resource_rejections;

记录 Resource Manager 拒绝的资源请求。计数器在节点重启时归零。用于诊断资源空间不足及受影响的用户/池。

监控系统资源

SELECT * FROM v_monitor.system_resource_usage
ORDER BY end_time DESC;

提供内存、CPU、网络、磁盘 I/O 等系统资源的历史数据。

监控磁盘空间

Vertica 建议保留 40% 空闲空间以确保平稳运行。

SELECT * FROM v_monitor.storage_usage
ORDER BY poll_timestamp DESC;

☁️ Eon 模式：监控子集群资源隔离

Eon 支持按子集群隔离工作负载。资源池在子集群级别独立运行，支持对全局资源池参数做子集群级覆盖（通过 ALTER RESOURCE POOL ... FOR SUBCLUSTER ...）。 覆盖配置可查询 SUBCLUSTER_RESOURCE_POOL_OVERRIDES 系统表。

-- 按子集群分组查看资源池负载
SELECT n.subcluster_name, rps.pool_name,
       MAX(rps.running_query_count) AS max_running,
       NVL(MAX(rq.queue_cnt), 0) AS max_queue_depth,
       (MAX(rps.memory_inuse_kb) / 1048576.0)::NUMERIC(10,2) AS max_mem_gb
FROM resource_pool_status rps
JOIN (SELECT node_name, subcluster_name FROM nodes) n USING (node_name)
LEFT JOIN (
  SELECT a.node_name, a.pool_name, MAX(a.position_in_queue) AS queue_cnt
  FROM resource_queues a GROUP BY 1, 2
) rq USING (node_name, pool_name)
GROUP BY 1, 2 ORDER BY 1, max_running DESC;

告警规则：如果 ETL 子集群的 max_queue_depth 持续增长而查询子集群负载低，说明子集群间负载不均衡。

来源：SUBCLUSTER_RESOURCE_POOL_OVERRIDES。完整子集群资源监控内容见 §11.5。

---

3. 活跃会话

一个用户可以同时连接到多个运行中的会话。大量活跃用户会话可能影响集群性能。

查看当前会话

SELECT user_name, session_id, current_statement, statement_start
FROM v_monitor.sessions;

查询结果显示当前连接的用户（user_name）、会话 ID（session_id）、当前执行的语句（current_statement）以及语句开始时间（statement_start）。

用这个表可以：

• 识别运行长查询的用户
• 识别因未提交事务而持有锁的用户
• 确定关闭数据库前需要断开哪些用户
• 查看会话是否使用 SSL 或客户端认证
• 识别客户端版本

关闭会话

关闭会话会中断指定外部会话、回滚当前事务（如果有）并关闭 socket。只能关闭自己的会话。 会话关闭可能需要一定时间。

SELECT close_session('session_id');

-- 返回：
 CLOSE_SESSION
--------------------------------------------------------------------
 Session close command sent. Check v_monitor.sessions for progress.
(1 row)

会话 ID 是一个字符串，用于指定要关闭的会话。该标识符在集群中任何时间点都是唯一的，但会话关闭后可能会被重用。

---

4. 活跃查询

监控正在运行的查询

SELECT node_name, query, query_start, user_name, is_executing
FROM v_monitor.query_profiles
WHERE is_executing = 't';

查询结果会显示连接到数据库的用户（user_name）及其正在运行的查询（query），还可以看到查询开始时间（query_start）和查询开始运行的节点（node_name）。这些结果有助于了解集群当前的工作负载。

监控加载状态

SELECT table_name, read_bytes, input_file_size_bytes,
       accepted_row_count, rejected_row_count,
       parse_complete_percent, sort_complete_percent
FROM load_streams
WHERE is_executing = 't'
ORDER BY table_name;

查看历史加载记录：改为 WHERE is_executing = 'f'。

监控锁状态

Vertica 使用锁来管理数据并发性和一致性。通过根据对象状态限制用户可对对象执行的操作，Vertica 自动控制锁定。v_monitor.locks 系统表用于监控所有节点的锁授予和请求情况。

SELECT locks.lock_mode, locks.lock_scope,
       substr(locks.transaction_description, 1, 100) AS "left",
       locks.request_timestamp, locks.grant_timestamp
FROM v_monitor.locks;

无结果 = 当前没有锁。用于分析批处理问题和慢查询原因。

---

5. 恢复（Recovery）

节点从 DOWN 恢复时，需要从 buddy 节点同步缺失数据才能回到 UP 状态。

SELECT node_name, recover_epoch, recovery_phase,
       current_completed, current_total, is_running
FROM v_monitor.recovery_status
ORDER BY 1;

字段含义：

字段	含义
is_running	恢复是否进行中
current_completed	已完成恢复的投影数
current_total	需要恢复的投影总数

详见 KB 文章「Node Recovery in Vertica」。

☁️ Eon 模式：节点恢复差异

Eon 模式节点恢复不走 buddy 数据同步，而是从公共存储重新订阅分片。恢复进度通过 node_subscription_change_phases 系统表观测：

-- 查看恢复各阶段耗时
SELECT session_id, action AS phase,
       subscriber_node_name, shard_name,
       TIMESTAMPDIFF(MINUTE, MIN(start_time), MAX(end_time)) AS duration_min,
       phase_result
FROM v_catalog.node_subscription_change_phases
WHERE subscriber_node_name = '<recovering_node>'
GROUP BY 1, 2, 3, 4, 6
ORDER BY MIN(start_time) DESC;

恢复阶段顺序：COLLECT SHARD METADATA → WITH PLAN → WITH LOCK → INSTALL LARGE → INSTALL SMALL → COMMIT。

告警规则：COLLECT SHARD METADATA 超过 30 分钟 → 排查公共存储响应慢 / Catalog 过大（>20GB 考虑 TSCatalogInvite = 0）/ Kerberos 票据。

⚠️ 恢复期间触发 drop/remove subscription 产生 GCL-X 锁，短时性能下降为正常现象。

来源：NODE_SUBSCRIPTION_CHANGE_PHASES。

---

6. 重平衡（Rebalance）

检查节点依赖

SELECT GET_NODE_DEPENDENCIES();

一份状态健康（clean）的节点依赖列表应显示 （节点数 + 1） 行。每行显示分段投影数，最后一行是非分段投影数。在位图格式中，每一位代表一个节点。例如位图 00011 中：node 1 = 1、node 2 = 1、node 3 = 0、node 4 = 0、node 5 = 0。1 表示该节点存在 segment，0 表示不存在。

监控重平衡进度

SELECT rebalance_method AS "方法", Status, COUNT(*) AS Count
FROM (
  SELECT rebalance_method,
    CASE
      WHEN (separated_percent = 100 AND transferred_percent = 100) THEN 'Completed'
      WHEN (separated_percent <> 0 AND separated_percent <> 100)
        OR (transferred_percent <> 0 AND transferred_percent <> 100) THEN 'In Progress'
      ELSE 'Queued'
    END AS Status
  FROM v_monitor.rebalance_projection_status
  WHERE is_latest
) AS tab
GROUP BY 1, 2 ORDER BY 1, 2;

重平衡方法：

• ELASTIC_CLUSTER — 弹性集群
• REPLICATE — 复制
• REFRESH — 刷新

详见 Vertica 集群 Rebalance 完全指南。

☁️ Eon 模式：重平衡差异

Eon 的 REBALANCE_SHARDS() 是元数据操作，不迁移数据，分钟级完成。与 Enterprise REBALANCE_CLUSTER() 的数据重分布（数小时~数十小时）根本不同。

-- Eon 分片再平衡后验证：新节点出现 ACTIVE 即完成
SELECT subcluster_name, n.node_name, shard_name, subscription_state
FROM nodes n
LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name = ns.node_name)
ORDER BY subcluster_name, node_name;

无需监控 separated_percent / transferred_percent（Enterprise 概念），直接检查新节点是否有 ACTIVE 订阅即可。

详细 Eon rebalance 机制见 Vertica 集群 Rebalance 完全指南 §7.6。

---

7. 历史活动

按执行时间查 Top N 慢查询

SELECT user_name, start_timestamp, request_duration_ms,
       transaction_id, statement_id,
       substr(request, 0, 1000) AS request
FROM v_monitor.query_requests
WHERE transaction_id > 0
ORDER BY request_duration_ms DESC
LIMIT 10;

request_duration_ms 单位是毫秒。

查看查询的内存使用

在 Vertica 数据库中，由于数据量或查询复杂度的不同，有些查询可能使用更多内存，有些可能使用更少。可通过以下查询了解特定查询的内存使用情况：

SELECT node_name, transaction_id, statement_id, user_name,
       start_timestamp, request_duration_ms, memory_acquired_mb,
       substr(request, 1, 100) AS request
FROM v_monitor.query_requests
WHERE transaction_id = <txn_id> AND statement_id = <stmt_id>;

根据结果可以优化查询、修改表/投影设计或减少数据量。

---

8. 对象统计

监控分区数

节点分区可以方便地识别需要删除的数据，并有助于回收磁盘空间。可以在 CREATE TABLE 定义表时指定分区，Vertica 在每次加载操作时自动分区数据。也可以对已有表通过 ALTER TABLE 修改定义来指定分区，但已有数据需通过 PARTITION_TABLE 函数显式重新分区。ROS_COUNT 字段的默认最大值为 1024。

SELECT node_name, projection_name, count(partition_key)
FROM v_monitor.partitions
GROUP BY node_name, projection_name
ORDER BY node_name, projection_name;

分区过多说明需要用 ALTER TABLE 调整分区策略。

详见 Vertica 文档「ALTER TABLE」和 Vertica 分区表常见问题。

监控分段与数据倾斜

分段（Segmentation）是指在集群节点之间组织和分布数据，以实现快速数据清除和高效查询。分段的目标是将数据均匀分布到多个数据库节点上，使所有节点都参与查询执行。分段通过 CREATE PROJECTION 语句的 hash segmentation 子句指定。然而，数据库可能会出现数据倾斜（data skew）的情况。

SELECT ps.node_name, ps.projection_schema, ps.projection_name, ps.row_count
FROM v_monitor.projection_storage ps
INNER JOIN v_catalog.projections p
  ON ps.projection_schema = p.projection_schema
  AND ps.projection_name = p.projection_name
WHERE p.is_segmented
ORDER BY ps.projection_schema, ps.projection_name, ps.node_name;

各节点上同一投影的行数应接近。差异过大说明存在数据倾斜，需优化投影设计。

---

9. 查询性能

查询执行事件

当你向 Vertica 提交查询时，Vertica 查询优化器会自动选择一组操作来计算请求结果，这组操作称为查询计划（query plan）。操作的选择可以极大改善查询的运行性能和资源消耗。根据数据库中定义的投影属性，查询优化器可以选择更快、更高效的操作来计算结果。

-- query_events 表提供查询计划、优化及执行事件
SELECT * FROM v_monitor.query_events;

查询性能会随数据增长而退化，需持续监控高频和大数据量查询。

详见 KB 文章「System Tables for Query Performance」。

加载流统计

load_streams 系统表包含活跃和历史加载指标的数据。可用于获取上次加载中接受了多少行、拒绝了多少行的统计信息。Vertica 维护系统表指标直到达到指定的容量配额（以 KB 为单位），该配额由内部流程设置，无法直接查看或设置。

SELECT schema_name, table_name, load_start, load_duration_ms,
       is_executing, parse_complete_percent, sort_complete_percent,
       accepted_row_count, rejected_row_count
FROM v_monitor.load_streams;

记录每次加载的接受/拒绝行数，按来源分组可追踪数据来源。

---

10. Data Collector 表速查

类别	组件	DC 表	说明
Query	RequestsIssued	dc_requests_issued	所有 SQL 请求历史
Query	RequestsCompleted	dc_requests_completed	所有完成的 SQL 请求
Query	ExecutionEngineProfiles	dc_execution_engine_profiles	EE 分析历史
Query	QueryExecutions	dc_query_executions	查询执行各步骤
Resource	ResourceAcquisitions	dc_resource_acquisitions	资源获取历史
Resource	ResourcePoolStatus	dc_resource_pool_status	资源池状态
Event	OptimizerEvents	dc_optimizer_events	优化器重要事件
Event	ExecutionEngineEvents	dc_execution_engine_events	本地规划与执行事件
Session	SessionStarts	dc_session_starts	会话启动
Session	SessionEnds	dc_session_ends	会话结束
Lock	LockAttempts	dc_lock_attempts	锁尝试历史
Lock	LockReleases	dc_lock_releases	锁释放历史

完整的系统表列表详见「System Tables for Query Performance」。

☁️ Eon 模式专属 DC 表

类别	DC 表	说明
Depot	dc_depot_fetches	Depot 从公共存储拉取数据的历史（缓存未命中）
Depot	dc_depot_uploads	Depot 上传数据到公共存储的历史
Depot	dc_depot_evictions	Depot 逐出对象的历史（含 number_hits 字段）
Shard	dc_shard_subscriptions_changes	分片订阅变更历史
Shard	dc_shard_subscriptions_state	分片订阅状态快照

完整字段与版本差异见系统表参考目录。来源：DEPOT_FETCHES、DEPOT_UPLOADS、DEPOT_EVICTIONS

---

11. Eon 模式专属监控

Eon 模式（计算-存储分离）的架构与 Enterprise 模式有根本性不同：数据存储在公共存储（S3/HDFS/GCS），节点本地仅保留 Depot 缓存，容错依赖分片订阅（Shard Subscription）而非 buddy projection。这导致了全新的监控需求，以下逐一介绍。

11.1 架构差异：Enterprise vs Eon 监控维度对比

监控维度	Enterprise 模式	Eon 模式
容错机制	Buddy projection（每个分段投影有 buddy 副本）	Shard Subscription（每个分片有多个订阅节点）
数据存储	本地磁盘（CATALOG + DATA 路径）	公共存储 + 本地 Depot 缓存
节点恢复	从 buddy 节点同步缺失数据	从公共存储重新订阅分片元数据
重平衡	数据重分布（REBALANCE_CLUSTER()），迁移 TB 级数据	分片再平衡（REBALANCE_SHARDS()），仅调整元数据
节点扩容	加节点 → rebalance（数小时~数十小时）	加节点 → 分片订阅再分配（分钟级）
节点间数据冗余	buddy projection 2 副本	分片订阅 K+1 个订阅者
资源隔离	资源池（Resource Pool）	资源池 + 子集群级别资源覆盖（SUBCLUSTER_RESOURCE_POOL_OVERRIDES）

11.2 监控分片订阅（Shard Subscription）状态

基本的订阅状态巡检 SQL 见 §1 系统健康章节。以下为深度监控和诊断用查询。

Eon 模式中，分片订阅替代了 buddy projection 的容错角色。每个分片必须有至少 1 个订阅节点，任何分片失去所有订阅者时集群自动进入 READONLY 模式。

查看各节点分片订阅状态

-- 查看所有分片订阅关系
SELECT node_name, shard_name, subscription_state,
       is_primary, is_participating_primary
FROM v_catalog.node_subscriptions
ORDER BY shard_name, node_name;

subscription_state 可能的值：ACTIVE（正常）、PENDING（正在建立）、UNSUBSCRIBED（已退订）、ERROR（异常）。

按子集群汇总订阅状态（巡检用）

SELECT subcluster_name AS subcls,
       subscription_state AS state,
       COUNT(DISTINCT n.node_name) AS nodes,
       COUNT(DISTINCT shard_name) AS shards
FROM nodes n
LEFT JOIN v_catalog.node_subscriptions ns ON (n.node_name = ns.node_name)
WHERE subscription_state != 'ACTIVE'
GROUP BY 1, 2
ORDER BY 1, 2;

告警规则：如果查询返回结果（即存在非 ACTIVE 状态的订阅），需要排查原因。特别是 UNSUBSCRIBED 状态，可能导致该分片覆盖不足。

检查每个分片的订阅者数量

SELECT shard_name, COUNT(*) AS subscriber_count
FROM v_catalog.node_subscriptions
WHERE subscription_state = 'ACTIVE'
GROUP BY shard_name
ORDER BY subscriber_count;

告警规则：任何分片的 subscriber_count = 0 时，集群立即进入 READONLY。K=1 集群每个分片应该有 ≥2 个 ACTIVE 订阅者。

查看当前会话已使用的订阅

-- SESSION_SUBSCRIPTIONS：当前会话实际使用哪些节点的分片订阅
SELECT node_name, shard_name, is_participating, is_collaborating
FROM v_catalog.session_subscriptions;

来源：SESSION_SUBSCRIPTIONS — 用于诊断查询是否调度到了预期的节点上。

查看分片信息

SELECT shard_name, shard_type, is_replicated,
       lower_hash_bound, upper_hash_bound
FROM v_catalog.shards
ORDER BY shard_name;

shard_type = replica 的为全复制分片（存储 catalog 等元数据），其他为数据分片。

11.3 监控 Depot 缓存命中率与容量

Depot 是 Eon 节点的本地 LRU 缓存。当查询所需数据不在 Depot 中时，节点从公共存储拉取，产生额外延迟。监控 Depot 命中率是 Eon 性能管理的核心。

查看 Depot 容量使用

-- DEPOT_SIZES：每个节点的 Depot 总容量和当前使用量
SELECT node_name, location_path,
       (current_usage_bytes / 1073741824.0)::NUMERIC(10,2) AS usage_gb,
       (max_size_bytes / 1073741824.0)::NUMERIC(10,2) AS max_gb,
       ROUND(current_usage_bytes * 100.0 / max_size_bytes, 1) AS pct_used
FROM v_monitor.depot_sizes
ORDER BY node_name;

告警规则：pct_used 持续 >90% 说明 Depot 容量不足，应考虑扩容 Depot 或缩减数据量。来源：DEPOT_SIZES

监控 Depot 从公共存储拉取（反映缓存未命中）

-- v_monitor.depot_fetches：记录每次从公共存储拉取数据到 Depot
SELECT node_name,
       COUNT(*) AS fetch_count,
       (SUM(file_size_bytes) / 1048576.0)::NUMERIC(12,2) AS total_mb,
       AVG(file_size_bytes)::INT AS avg_file_bytes,
       SUM(CASE WHEN NOT is_successful THEN 1 ELSE 0 END) AS failed_fetches
FROM v_monitor.depot_fetches
WHERE start_time > SYSDATE - INTERVAL '1 hour'
GROUP BY node_name
ORDER BY fetch_count DESC;

分析要点：fetch_count 高说明频繁从公共存储拉取。高峰期突增可能意味着： - Depot 容量不足导致频繁 eviction 后重新拉取 - 工作负载发生了显著变化（新查询访问冷数据） - 节点重启后 Depot 冷启动

来源：DEPOT_FETCHES

推算 Depot 命中率（近似）

Vertica 没有直接暴露 depot_hit_ratio 指标，但可通过 dc_depot_evictions 的 number_hits 与 dc_depot_fetches 的 fetch_count 推算：

-- Depot 逐出记录：包含该对象被逐出前在 Depot 中被命中的次数
SELECT node_name,
       COUNT(*) AS eviction_count,
       SUM(number_hits) AS total_hits,
       ROUND(AVG(number_hits), 1) AS avg_hits_per_object,
       (SUM(file_size_bytes) / 1048576.0)::NUMERIC(12,2) AS evicted_mb
FROM v_monitor.depot_evictions
WHERE start_time > SYSDATE - INTERVAL '24 hours'
GROUP BY node_name
ORDER BY eviction_count DESC;

解读：number_hits 高的对象被逐出 = 常用数据被挤出（Depot 不够大）。number_hits 低的逐出 = 正常的 LRU 淘汰。

近似命中率推算：hit_rate ≈ 1 - (fetch_count / (fetch_count + total_hits))。来源：DEPOT_EVICTIONS

监控 Depot 上传到公共存储

SELECT node_name,
       COUNT(*) AS upload_count,
       (SUM(file_size_bytes) / 1048576.0)::NUMERIC(12,2) AS total_mb
FROM v_monitor.depot_uploads
WHERE start_time > SYSDATE - INTERVAL '1 hour'
GROUP BY node_name
ORDER BY upload_count DESC;

来源：DEPOT_UPLOADS — 上传量大说明写入负载高。结合网络带宽评估公共存储带宽是否充足。

Depot 故障排查

当查询持续从公共存储拉取数据、性能下降时：

现象	可能原因	排查方向
dc_depot_fetches 频繁	Depot 容量不足	检查 depot_sizes 的 pct_used，考虑增加 Depot 大小
同一对象反复 fetch → evict → fetch	LRU 抖动（thrashing）	Depot 远小于工作集，扩大 Depot 或调整查询模式
dc_depot_fetches.is_successful = 'f'	公共存储连接异常	检查 HDFS/S3 连通性、Kerberos 票据
节点重启后大量 fetch	Depot 冷启动（正常）	预热后自动恢复，可通过运行代表性查询加速预热

11.4 监控公共存储延迟

Eon 模式下，Depot 未命中时需要从公共存储（S3/HDFS/GCS）读取数据，网络延迟直接影响查询性能。

监控网络带宽使用

-- NETWORK_USAGE：每个节点网络收发的历史记录
SELECT node_name,
       AVG(rx_kbytes_per_sec) AS avg_rx_kbs,
       MAX(rx_kbytes_per_sec) AS peak_rx_kbs,
       AVG(tx_kbytes_per_sec) AS avg_tx_kbs,
       MAX(tx_kbytes_per_sec) AS peak_tx_kbs
FROM v_monitor.network_usage
WHERE start_time > SYSDATE - INTERVAL '1 hour'
GROUP BY node_name
ORDER BY peak_rx_kbs DESC;

来源：NETWORK_USAGE。公共存储延迟无法直接查询（取决于外部系统），但通过网络带宽使用和 Depot fetch 频率间接评估： - rx_kbytes_per_sec 持续高 → 大量从公共存储读取 - 与 dc_depot_fetches 趋势一致 → 确认是 Depot 未命中导致的带宽消耗

通过 vnetperf 测试网络

在生产环境外，使用 Vertica 自带的 vnetperf 工具测试节点间和与公共存储之间的网络延迟：

# 测试节点间 UDP/TCP 带宽
/opt/vertica/bin/vnetperf --hosts node1,node2,node3

# 测试到 HDFS NN 的延迟
ping <hdfs-namenode>

参考 Vertica Eon 模式中分片、节点和 Depot 选择的最佳实践。

11.5 监控子集群资源隔离

基本的子集群资源池负载查询见 §2 资源使用章节。以下为子集群级别资源覆盖和弹性伸缩的深度监控。

查看子集群资源池使用（分集群维度）

-- 按子集群统计资源池使用
SELECT n.subcluster_name,
       rps.pool_name,
       MIN(rps.running_query_count) AS min_running,
       MAX(rps.running_query_count) AS max_running,
       NVL(MAX(rq.queue_cnt), 0) AS max_queue_depth,
       (MIN(rps.memory_inuse_kb) / 1048576.0)::NUMERIC(10,2) AS min_mem_gb,
       (MAX(rps.memory_inuse_kb) / 1048576.0)::NUMERIC(10,2) AS max_mem_gb
FROM resource_pool_status rps
JOIN (SELECT node_name, subcluster_name FROM nodes) n USING (node_name)
LEFT JOIN (
  SELECT a.node_name, a.pool_name, MAX(a.position_in_queue) AS queue_cnt
  FROM resource_queues a
  GROUP BY 1, 2
) rq USING (node_name, pool_name)
GROUP BY 1, 2
ORDER BY 1, max_running DESC;

查看子集群级别资源池覆盖

-- SUBCLUSTER_RESOURCE_POOL_OVERRIDES：子集群对全局资源池的覆盖参数
SELECT subcluster_name, name AS pool_name,
       memorysize, maxmemorysize, maxquerymemorysize
FROM v_catalog.subcluster_resource_pool_overrides
ORDER BY 1, 2;

来源：SUBCLUSTER_RESOURCE_POOL_OVERRIDES。例如，ETL 子集群可能需要更大的 maxmemorysize 以支持数据加载，而查询子集群可能限制 maxquerymemorysize 防止单查询占满资源。

监控子集群弹性伸缩

-- 查看各子集群节点数量
SELECT subcluster_name,
       COUNT(*) AS node_count,
       SUM(CASE WHEN node_state = 'UP' THEN 1 ELSE 0 END) AS up_nodes
FROM nodes
GROUP BY subcluster_name
ORDER BY subcluster_name;

告警规则：子集群内 up_nodes = 0 时，该子集群的服务不可用。

11.6 Enterprise vs Eon 监控维度速查

监控项	Enterprise 模式	Eon 模式	详情
节点状态	SELECT * FROM nodes;	同左	§1
容错状态	current_fault_tolerance FROM system	shard subscription_state	§1 ☁️
数据冗余	GET_NODE_DEPENDENCIES()	每个 shard 的 subscriber_count	§1 ☁️
节点恢复	v_monitor.recovery_status（投影恢复）	node_subscription_change_phases（分片订阅）	§5 ☁️
重平衡	v_monitor.rebalance_projection_status	node_subscriptions（ACTIVE 即完成）	§6 ☁️
存储空间	v_monitor.storage_usage（本地磁盘）	depot_sizes（Depot 缓存）	§2 / §11.3
子集群资源	资源池按节点	资源池按 subcluster_name + 子集群覆盖	§2 ☁️ / §11.5
网络延迟	N/A	network_usage + Depot fetch 频次	§11.4
DC 表	7 类 12 张表	+ 5 张 Eon 专属 Depot/Shard 表	§10 ☁️

---

关键 SQL 速查

监控目标	SQL
节点状态	SELECT node_name, node_state FROM nodes;
Epoch/AHM	SELECT * FROM system;
Delete Vector	SELECT COUNT(*) FROM v_monitor.delete_vectors;
ROS Container	v_monitor.projection_storage GROUP BY
资源池	SELECT * FROM resource_pool_status;
资源队列	SELECT * FROM v_monitor.resource_queues;
系统资源	SELECT * FROM v_monitor.system_resource_usage;
磁盘	SELECT * FROM v_monitor.storage_usage;
活跃会话	SELECT * FROM v_monitor.sessions;
关闭会话	SELECT close_session('session_id');
运行中查询	v_monitor.query_profiles WHERE is_executing='t'
加载进度	load_streams WHERE is_executing='t'
锁状态	SELECT * FROM v_monitor.locks;
恢复状态	v_monitor.recovery_status
重平衡进度	v_monitor.rebalance_projection_status
慢查询 Top N	v_monitor.query_requests ORDER BY request_duration_ms DESC
查询内存	memory_acquired_mb FROM v_monitor.query_requests
分区数	v_monitor.partitions GROUP BY
数据倾斜	projection_storage JOIN projections
节点依赖	SELECT GET_NODE_DEPENDENCIES();
☁️ 分片订阅状态	v_catalog.node_subscriptions WHERE subscription_state!='ACTIVE'
☁️ 分片订阅者数	SELECT shard_name, COUNT(*) FROM node_subscriptions GROUP BY 1
☁️ Depot 容量	v_monitor.depot_sizes（pct_used > 90% 告警）
☁️ Depot 拉取频率	dc_depot_fetches（高 freq = 缓存未命中多）
☁️ Depot 逐出	dc_depot_evictions（number_hits 高但被逐出 = Depot 不够大）
☁️ 子集群资源池	resource_pool_status JOIN nodes GROUP BY subcluster_name
☁️ 子集群覆盖参数	v_catalog.subcluster_resource_pool_overrides
☁️ 网络带宽	v_monitor.network_usage（rx_kbytes_per_sec 持续高 = 延迟风险）
☁️ 分片订阅变更	v_catalog.node_subscription_change_phases（恢复各阶段耗时）

☁️ = Eon 模式专属