如何排查 Amazon Redshift 中的 VACUUM 性能问题?
上次更新时间:2020 年 8 月 26 日
我担心 VACUUM 对我的 Amazon Redshift 集群的性能影响。 为什么运行 VACUUM 需要这么长时间?在我的 Amazon Redshift 集群上运行 VACUUM 操作时,我应该考虑哪些最佳实践?
简短描述
VACUUM 是一种资源密集型操作,可因以下因素而减慢速度:
- 未排序数据的百分比较高
- 列过多的大型表
- 交错排序键用法
- 无规律或不经常使用 VACUUM
- 并发表、集群查询、DDL 语句或 ETL 作业
使用 svv_vacuum_progress 查询来检查您的 VACUUM 操作的状态和详细信息。然后,按照 VACUUM 最佳实践进行故障排查并避免将来出现的任何问题。
解决方法
要检查 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 查询仅返回一行结果。
检查正在清理的表的详细信息。在 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
注意:表中的数据将实时更新。要检查 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 DELETE 操作。VACUUM DELETE 安排在负载较低的时段运行,而在高负载时段期间暂停。您极少需要运行 DELETE ONLY 操作。
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。
- 如果大型表上有大量未排序的数据,请创建深层复制(使用 CREATE TABLE AS)。深层复制可以帮助您将数据加载到新表中,而不是在现有的表上运行 VACUUM SORT。
- 使用 BOOST 选项运行 VACUUM 命令。BOOST 选项可为 VACUUM 分配额外的资源,例如可用内存和磁盘空间。使用 BOOST 选项,VACUUM 在一个窗口中运行,并在 VACUUM 操作期间阻止并发删除和更新。
注意:如果使用 BOOST 选项运行 VACUUM,查询性能可能会受到影响。这是在维护操作或非高峰时段运行 VACUUM BOOST 操作的最佳实践。 - 将任何大型表分成时间序列表,以提高 VACUUM 性能。在某些情况下,使用时间序列表可以满足运行 VACUUM 的需要。
- 为大型表选择列压缩类型。对数据进行排序时,压缩行消耗的磁盘空间较少。