如何解决 Amazon Redshift 中的 VACUUM 问题？

3 分钟阅读

我对我的 Amazon Redshift 集群上的 VACUUM 的性能感到担忧。或者，我的 VACUUM 查询在我的 Amazon Redshift 集群中失败。

简短描述

VACUUM 是一项资源密集型操作，可能会由于以下原因减慢速度：

未排序数据的百分比很高
包含过多列的大型表
使用交错排序键
不定期或不经常使用 VACUUM
并发表、集群查询、DDL 语句或 ETL 作业

使用 svv_vacuum_progress 查询来检查 VACUUM 操作的状态和详细信息。然后，遵循 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 查询还包括表的名称、vacuum 的状态以及预计剩余完成时间。如果没有 VACUUM 正在运行，则 svv_vacuum_progress 查询会显示上次运行的 VACUUM 的状态。

**注意：**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 是自动 VACUUM DELETE，从 2020-05-27 06:55:18.906008 UTC 开始，并在几秒钟后完成。
此 VACUUM 释放了被删除的行所占用的空间。VACUUM 操作开始和完成时显示的行数和块数证实了这种状态。

请注意从 VACUUM 开始和完成以来表占用的块数的变化。

**注意：**Amazon Redshift 会在后台自动对表执行 VACUUM SORT 和 VACUUM DELETE 操作。这些后台 VACUUM 在负载减少期间运行，在高负载期间暂停。这种自动的 VACUUM 可减少运行 VACUUM 命令的需要。

sortedrows 列显示表中已排序的行数。在上一次的 VACUUM 中，没有进行任何排序，因为这是一次自动的 VACUUM DELETE 操作。由于未对活动行进行排序，因此标记为删除的行显示与 VACUUM 启动时相同的已排序行数。VACUUM DELETE 完成后，您将看到 0 行已排序。

于 2020-05-27 06:28:17.128345 UTC 开始的初始 VACUUM 显示 VACUUM 已满。大约 18 分钟后，该过程从删除的行和排序的行中释放了空间。VACUUM 操作完成后，输出显示的 rows 和 sortedrows 的值相同，因为 VACUUM 成功对这些行进行了排序。

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

排查 VACUM 故障

**注意：**如果您在运行 AWS 命令行界面 (AWS CLI) 命令时收到错误，请参阅 AWS CLI 错误故障排除。此外，请确保您使用的是最新版本的 AWS CLI。

要找出 VACUUM 查询失败的原因，请使用 SYS_QUERY_HISTORY 或 STL_QUERY 来检查错误消息。

如果您使用 STL_QUERY，则必须从 STL_ERROR 中获取错误详细信息。由于 STL_ERROR 没有查询 ID 列，因此请从 STL_QUERY 中找到 PID 字段。然后，在 STL_ERROR 查询中使用该字段。

示例：

SELECT user_id, query_id, transaction_id, session_id,  status, start_time, end_time, execution_time, error_message FROM sys_query_history WHERE query_id IN (<failed queries>) 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

| user_id | query_id   | transaction_id |  session_id | status | start_time              |     end_time                  |  execution_time |   error_message |  
| 100        | 915082632 | 35599398     | 1096641177 | failed  | 2024-10-06 21:09:30.209587 | 2024-10

如果您使用执行语句运行 VACUUM 查询，则使用 describe-statement 来识别任何错误消息。

示例：

aws redshift-data describe-statement --id 7c823348d-be8b-437a-9a0-db8c0ca44f0f
{
    "ClusterIdentifier": "redshift-cluster-1",
    "CreatedAt": "2024-10-07T16:25:27.566000+00:00",
    "Duration": -1,
    "Error": "ERROR: VACUUM cannot run inside a multiple commands statement",
    "HasResultSet": false,
    "Id": "7c823348d-be8b-437a-9a0-db8c0ca44f0f",
    "QueryString": "vacuum full toptem;\nvacuum full tsupport;\nvacuum full supplierxbox;\nvacuum full party;",
    "RedshiftPid": 10723479554,
    "RedshiftQueryId": 42304,
    "ResultRows": -1,
    "ResultSize": -1,
    "Status": "FAILED",
    "UpdatedAt": "2024-10-07T16:25:33.566000+00:00"
}

VACUUM 最佳实践

您可以按照以下最佳实践提高 VACUUM 的性能：

由于 VACUUM 是一项资源密集型操作，因此请在非高峰时段运行它。
在非高峰时段，使用 wlm_query_slot_count 暂时覆盖 VACUUM 操作队列中的并发级别。
对于大型表，以高达 99% 的阈值参数运行 VACUUM 操作。
确定运行 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 命令来更新统计数据。查询规划器使用这些值来选择最佳计划。
如果集群完全空闲，则对失败的 VACUUM 尝试运行 MANUAL VACUUM。有关详细信息，请参阅手动清空和分析表。