跳转至

ROS Pushback 故障排查

原文：Troubleshooting ROS Pushback

适用版本： 本文基于 Enterprise Mode 编写。Eon Mode 无 WOS/ROS 容器概念（数据在公共存储），不存在 ROS pushback 问题。Case 3 中层次分区需 Vertica 9.0+。

概述

Vertica 限制每个节点每个 projection 最多 1024 个 ROS 容器。使用以下查询检查各节点各 projection 的 ROS 容器数：

=> SELECT node_name, schema_name, projection_name,
          sum(delete_vector_count/cnt)::int + count(*) container_count
   FROM storage_containers
   JOIN (SELECT projection_id, count(*) cnt FROM projection_columns GROUP BY 1) proj_cols
     ON storage_containers.projection_id = proj_cols.projection_id
   WHERE storage_type = 'ROS'
   GROUP BY 1,2,3
   ORDER BY 4 DESC;

本文涵盖 ROS pushback 的 8 种常见场景及其解决方案。

Case 1: 长时间运行的 Mergeout 作业

症状： 宽表（>250 列）或含大 VARCHAR 列的表上 mergeout 作业运行时间过长。

排查： 检查是否有 60 分钟以上的 mergeout：

=> SELECT a.node_name, a.schema_name, b.projection_name, count(*)
   FROM dc_tuple_mover_events a, dc_tuple_mover_events b
   WHERE a.transaction_id = b.transaction_id
     AND a.event = 'Start'
     AND b.event = 'Complete'
     AND b.time - a.time > interval '60 minutes'
   GROUP BY 1, 2, 3
   ORDER BY 4 DESC;

解决： 将 Tuple Mover 资源池的 MEMORYSIZE 增加到 2GB × MAXCONCURRENCY，并将 PLANNEDCONCURRENCY 设为与 MAXCONCURRENCY 相等。

Case 2: 长时间运行的 Replay Delete

症状： mergeout 期间 replay delete 操作耗时过长。

排查： 检查是否有 60 分钟以上的 replay delete：

=> SELECT a.node_name, a.schema_name, b.projection_name, count(*)
   FROM dc_tuple_mover_events a, dc_tuple_mover_events b
   WHERE a.transaction_id = b.transaction_id
     AND a.event = 'Change plan type to Replay Delete'
     AND b.event = 'Complete'
     AND b.time - a.time > interval '60 minutes'
   GROUP BY 1, 2, 3
   ORDER BY 4 DESC;

解决： 如果 projection 未针对删除操作优化，可将 ReplayDeleteAlgorithmSwitchThreshold 参数设为 0。

详见 Vertica 数据库 Replay Delete 算法

Case 3: ROS 容器数逼近上限但未被 Mergeout

症状： 每节点每 projection 的 ROS 容器数接近 1024 上限，但 Tuple Mover 未选择这些 projection 进行 mergeout。这通常是因为每个表的分区数已接近 1024 限制。

排查： 检查分区数：

=> SELECT node_name, table_schema, projection_name,
          count(distinct partition_key)
   FROM PARTITIONS
   GROUP BY 1,2,3
   ORDER BY 3 DESC;

解决： - 将超出保留策略的分区 MOVE 或 DROP 到其他表 - 推荐使用 层次分区（Vertica 9.0+），专门针对此场景设计

详见 理解 Vertica 的分区

Case 4: 分区重组待处理

症状： 当修改表的分区表达式后，现有数据必须重组以匹配新表达式。处于待重组状态的 ROS 容器不会被 mergeout 考虑。

排查：

=> SELECT table_schema, projection_name
   FROM partition_status
   WHERE partition_reorganize_percent <> 100;

解决：

ALTER TABLE <table_name> REORGANIZE;

Case 5: 频繁写入非活跃分区

症状： ETL 工作负载频繁向非活跃分区加载数据。默认情况下 Vertica 只有 1 个活跃分区（最新创建的分区），对活跃分区使用 strata 算法合并 ROS 容器；非活跃分区中的 ROS 容器会被合并为每个分区 1 个 ROS 容器。如果频繁向非活跃分区写入，mergeout 可能产生大量 I/O。

解决： 调整 ActivePartitionCount 参数以匹配工作负载。例如，如果按天分区且接收 3 天的数据，将 ActivePartitionCount 设为 3。有客户在正确设置此参数后观察到显著的集群性能提升。

检查非活跃分区的 mergeout 次数：

grep "Projection chosen =" vertica.log | grep "stratumNo = -1" | wc -l

Case 6: WOS 溢出（Spillover）

症状： Tuple Mover moveout 跟不上写入速度，导致 WOS 溢出到磁盘。

排查：

=> SELECT node_name, count(*)
   FROM dc_execution_engine_events
   WHERE event_type = 'WOS_SPILL'
   GROUP BY node_name;

解决：

  • 启用 reflexiveMoveout 配置参数（Enterprise Mode，≥9.3）
  • 对每节点大于 100MB 的文件使用 /*+DIRECT*/ hint 加载
  • 避免在 WOS 中滞留未提交数据（未提交数据不会被 moveout）
  • 使用 /*+DIRECT*/ hint 加载大型临时表（临时表不会被 moveout）

Case 7: 过多 Trickle Load

症状： 频繁的小批量（trickle）加载使用 /*+DIRECT*/ hint，导致 ROS 容器高速创建，mergeout 跟不上。

解决： - 不要对 trickle load 使用 /*+DIRECT*/ hint - 如果无效，将 Tuple Mover 资源池的 PLANNEDCONCURRENCY 和 MAXCONCURRENCY 从 3 增加到 4 - 绝不要超过 6，否则会对集群性能产生负面影响

Case 8: 缩短 MergeoutInterval 和 MoveoutInterval

症状： mergeout/moveout 休眠期间 ROS 容器高速产生。

解决： 降低 MergeoutInterval 配置参数（默认 600 秒）。仅当 ROS 容器在 mergeout 休眠期间高速创建时才有效。

详见 Tuple Mover 最佳实践完全指南

扩展阅读