如何排查 Amazon Redshift 中的 VACUUM 性能问题？

简短描述

VACUUM 是一种资源密集型操作，可因以下因素而减慢速度：

• 未排序数据的百分比较高
• 列过多的大型表
• 交错排序键用法
• 无规律或不经常使用 VACUUM
• 并发表、集群查询、DDL 语句或 ETL 作业

使用 svv_vacuum_progress 查询来检查您的 VACUUM 操作的状态和详细信息。然后，按照 VACUUM 最佳实践进行故障排查并避免将来出现的任何问题。

解决方法

**注意：**以下内容适用于预置的 Amazon Redshift 集群。以下系统表和查询在 Amazon Redshift Serverless 上不起作用。

要检查 VACUUM 操作是否正在进行，请运行 svv_vacuum_progress 查询：

dev=# SELECT * FROM svv_vacuum_progress;
table_name |          status                 | time_remaining_estimate
-----------+---------------------------------+-------------------------
 data8     |  Vacuum: initialize merge data8 | 4m 55s
(1 row)

svv_vacuum_progress 查询还会验证正在清理的表名称、清理状态以及完成之前的估计剩余时间。如果没有正在运行的清理，则 svv_vacuum_progress 查询将显示上次运行的清理操作的状态。

**注意：**svv_vacuum_progress 查询仅返回一行结果。

检查正在清理的表的详细信息。在 WHERE 子句中指定表和架构名称：

SELECT schema, table_id, "table", diststyle, sortkey1, sortkey_num, unsorted, tbl_rows, estimated_visible_rows, stats_off 
FROM svv_table_info 
WHERE "table" IN ('data8');

以下是示例输出：

Schema     | table_id | table | diststyle | sortkey1 | sortkey_num | unsorted | tbl_rows  | est_visible_rows | stats_off 
------------+----------+-------+-----------+----------+-------------+----------+-----------+------------------+-----------
 testschema | 977719   | data8 | EVEN      | order_id |  2          |    25.00 | 755171520 | 566378624        | 100.00

在此输出中，sortkey1 列显示主排序键。

如果表中有交错排序键，则此列将显示 INTERLEAVED 状态。

• sortkey_num 列显示排序键中的列数。
• 未排序列显示需要排序的行的百分比。
• tbl_rows 列显示行的总数，包括已删除和已更新的行。
• estimated_visible_rows 是排除了已删除的行之后的行数。
• 完全清理（删除和排序）后，tbl_rows 和 estimated_visible_rows 的值应彼此相似，并且未排序的数量应达到 0。 **注意：**表中的数据将实时更新。要检查 VACUUM 的进度，请继续运行查询。请注意，未排序的行随着 VACUUM 的进度逐渐减少。要验证您的未排序数据百分比是否较高，请检查特定表的 VACUUM 信息。

运行以下查询以检查表的 VACUUM 信息，并指定来自上一个查询的表 ID：

SELECT table_id, status, rows, sortedrows, blocks, eventtime
FROM stl_vacuum
WHERE table_id=977719
ORDER BY eventtime DESC LIMIT 20;

以下是示例输出：

table_id |             status             |    rows    | sortedrows | blocks |         eventtime         
----------+--------------------------------+------------+------------+--------+----------------------------
   977719 | [VacuumBG] Finished            |  566378640 |          0 |  23618 | 2020-05-27 06:55:33.232536
   977719 | [VacuumBG] Started Delete Only | 1132757280 |  566378640 |  47164 | 2020-05-27 06:55:18.906008
   977719 | Finished                       |  566378640 |  566378640 |  23654 | 2020-05-27 06:46:04.086842
   977719 | Started                        | 1132757280 |  566378640 |  45642 | 2020-05-27 06:28:17.128345
(4 rows)

输出会先按排序顺序，先列出最新事件，然后是较旧的事件。

• 最后执行的清理是自动 VACUUM DELETE，它于 2020-05-27 06:55:18.906008 UTC 开始，并在几秒钟内完成。
• 此清理操作释放了被删除的行占用的空间，并通过清理开始和完成时显示的行数和块数确认。

请注意从 VACUUM 开始和完成时表占用的块数发生的变化。

**注意：**Amazon Redshift 会自动在后台对表执行 vacuum 排序和 vacuum 删除操作。这些背景 vacuum 在负载减少期间运行，在高负荷期间暂停。这种自动 vacuum 减少了运行 vacuum 命令的需要。

sortedrows 列显示表中已排序的行数。在最后一个清理操作中，未进行排序，因为它是一个自动 VACUUM DELETE 操作。标记为删除的行显示与 VACUUM 启动时相同的已排序行数，因为未对活动行进行排序。在 VACUUM DELETE 完成后，它指示 0 个已排序的行。

启动于 2020-05-27 06:28:17.128345 UTC 的初始清理操作显示完全清理。在大约 18 分钟后，它释放了已删除行的空间，并对行进行了排序。在清理操作完成后，输出会显示行数和 sortedrows 的值相同，因为清理操作成功对行进行了排序。

对于已在进行中的清理，继续监控其性能并采用 VACUUM 最佳实践。

VACUUM 最佳实践

通过以下最佳实践可提高 VACUUM 性能：

• 由于 VACUUM 是一种资源密集型操作，因此它在非高峰时段运行。
• 在非高峰时段，使用 wlm_query_slot_count 临时覆盖 VACUUM 操作队列中的并发级别。
• 对于大型表，运行 VACUUM 操作时的阈值参数最高为 99%。
• 确定运行 VACUUM 的适当阈值和频率。例如，您可能希望以 100% 的阈值运行 VACUUM，或者始终对数据进行排序。使用可优化 Amazon Redshift 集群的查询性能的方法。
• 使用足以确保未排序区域不会在大型表中累积的频率运行 VACUUM FULL 或 VACUUM SORT ONLY。
• 如果大型表中有大量未排序的数据，则执行深层复制。深层复制可以帮助您将数据加载到新表中，而不是在现有的表上运行 VACUUM SORT。
• 使用 BOOST 选项运行 VACUUM 命令。BOOST 选项可为 VACUUM 分配额外的资源，例如可用内存和磁盘空间。使用 BOOST 选项，VACUUM 在一个窗口中运行，并在 VACUUM 操作期间阻止并发删除和更新。
  **注意：**使用 BOOST 选项运行 VACUUM 可能会影响查询性能。这仅是在维护操作或非高峰时段运行 VACUUM BOOST 操作的最佳实践。
• 将任何大型表分成时间序列表，以提高 VACUUM 性能。在某些情况下，使用时间序列表可以满足运行 VACUUM 的需要。
• 为大型表选择列压缩类型。对数据进行排序时，压缩行消耗的磁盘空间较少。
• 在 VACUUM 操作后使用 ANALYZE 命令更新统计信息，查询规划器会使用这些统计信息来选择最优计划。

---