PostgreSQL VACUUM 监控实战：pg_stat_all_tables 与 pg_stat_progress_vacuum 详解
大家好，我是你们的 PostgreSQL 好伙伴“老司机”。今天咱们来聊聊 PostgreSQL 中一个非常重要，但又经常被忽视的维护操作——VACUUM。VACUUM 就像数据库的“清洁工”，负责清理那些“死元组”（dead tuples，也就是被删除或更新的旧数据行），回收空间，防止数据库膨胀。更重要的是，它还能防止事务 ID 回卷（transaction ID wraparound）带来的灾难性后果。
但是，VACUUM 运行起来可不是“静悄悄”的，它需要消耗资源，有时候甚至会影响数据库的性能。所以，我们需要密切监控 VACUUM 的运行状态，确保它在“默默奉献”的同时，不会给我们的业务带来负面影响。今天，我就来给大家介绍两个监控 VACUUM 的利器：pg_stat_all_tables 和 pg_stat_progress_vacuum，并通过实际案例，教你如何解读这些视图中的关键指标，判断 VACUUM 是否正常工作，以及如何发现潜在问题。
为什么需要监控 VACUUM？
在深入了解这两个视图之前，我们先来搞清楚，为什么我们需要监控 VACUUM？
- 防止数据库膨胀:
VACUUM最主要的作用就是回收“死元组”占用的空间。如果不及时清理，数据库文件会越来越大，占用磁盘空间，影响性能。 - 防止事务 ID 回卷: PostgreSQL 使用事务 ID（XID）来标识每个事务。XID 是一个 32 位整数，用完之后会“回卷”到起始值。如果数据库长时间不进行
VACUUM，旧的 XID 可能无法及时回收，导致 XID 耗尽，数据库将停止写入，后果非常严重。 - 优化查询性能: “死元组”过多会降低查询性能，因为数据库在扫描数据时需要跳过这些“死元组”。
VACUUM可以减少“死元组”数量，提高查询效率。 - 避免
VACUUM运行时间过长:VACUUM操作可能会阻塞其他数据库操作，特别是VACUUM FULL。我们需要监控VACUUM的运行时间，避免它长时间占用资源，影响业务。 - 发现潜在问题:
VACUUM运行异常可能预示着某些潜在问题, 例如长时间运行的事务, 导致无法回收死元组.
pg_stat_all_tables：表级别的统计信息
pg_stat_all_tables 视图提供了表级别的统计信息，包括 VACUUM 和 ANALYZE 的相关信息。我们可以通过这个视图了解每个表上次 VACUUM 和 ANALYZE 的时间、执行次数、“死元组”数量等信息。
常用字段
relname: 表名。last_vacuum: 上次手动VACUUM的时间（不包括 autovacuum）。last_autovacuum: 上次自动VACUUM(autovacuum) 的时间。vacuum_count: 手动VACUUM的次数。autovacuum_count: 自动VACUUM的次数。last_analyze: 上次手动ANALYZE的时间。last_autoanalyze: 上次自动ANALYZE的时间。analyze_count: 手动ANALYZE的次数。autoanalyze_count: 自动ANALYZE的次数。n_live_tup: 表中“活元组”（live tuples）的数量，也就是当前有效的数据行数。n_dead_tup: 表中“死元组”的数量。n_mod_since_analyze: 自上次ANALYZE以来，表中被修改的元组数量。
示例查询
我们可以通过以下 SQL 查询来查看 pg_stat_all_tables 中的信息：
SELECT
relname,
last_vacuum,
last_autovacuum,
vacuum_count,
autovacuum_count,
last_analyze,
last_autoanalyze,
analyze_count,
autoanalyze_count,
n_live_tup,
n_dead_tup,
n_mod_since_analyze
FROM
pg_stat_all_tables
ORDER BY
n_dead_tup DESC;
这个查询会按照“死元组”数量降序排列，方便我们找出“死元组”最多的表。
解读关键指标
last_vacuum和last_autovacuum: 这两个字段可以帮助我们了解表上次VACUUM的时间。如果这两个时间都比较久远，说明这个表可能长时间没有进行VACUUM了，需要关注。n_dead_tup: 这个字段表示表中“死元组”的数量。如果这个值很大，说明这个表需要进行VACUUM了。一般来说，如果n_dead_tup超过n_live_tup的一定比例（例如 10% 或 20%），就需要考虑进行VACUUM。vacuum_count和autovacuum_count: 查看vacuum执行的次数, 了解vacuum的频率.- 注意:
n_dead_tup只是一个估算值, 并不完全精确. 并且,n_dead_tup的数量并不能完全决定是否需要执行VACUUM.
案例分析
假设我们通过上面的查询发现，表 my_table 的 last_autovacuum 时间是 3 天前，n_dead_tup 是 10000，n_live_tup 是 50000。这说明 my_table 已经 3 天没有进行自动 VACUUM 了，而且“死元组”数量占到了“活元组”数量的 20%。这可能意味着 autovacuum 的配置不合理，或者 autovacuum 进程遇到了问题。我们需要进一步调查，看看是什么原因导致 autovacuum 没有及时运行。
pg_stat_progress_vacuum：VACUUM 进度监控
pg_stat_progress_vacuum 视图提供了正在运行的 VACUUM 操作的进度信息。我们可以通过这个视图了解 VACUUM 正在处理哪个表、已经处理了多少数据、还剩多少数据等信息。
常用字段
pid:VACUUM进程的 PID。datid: 数据库 OID。datname: 数据库名称。relid: 正在进行VACUUM的表的 OID。phase:VACUUM当前所处的阶段。PostgreSQL 12 以及之前的版本, 包含如下阶段:initializing: 初始化阶段。scanning heap: 扫描堆（heap）阶段，查找“死元组”。vacuuming indexes: 清理索引阶段。vacuuming heap: 清理堆阶段。cleaning up indexes: 再次清理索引阶段。truncating heap: 截断堆阶段。performing final cleanup: 执行最终清理阶段。
PostgreSQL 13 及之后的版本新增了scanning index阶段.
heap_blks_total: 表的总块数。heap_blks_scanned: 已扫描的块数。heap_blks_vacuumed: 已清理的块数。index_vacuum_count: 已清理的索引数量。max_dead_tuples: 允许的最大“死元组”数量。num_dead_tuples: 当前已发现的“死元组”数量。
示例查询
我们可以通过以下 SQL 查询来查看 pg_stat_progress_vacuum 中的信息：
SELECT
pid,
datname,
relid,
phase,
heap_blks_total,
heap_blks_scanned,
heap_blks_vacuumed,
index_vacuum_count,
max_dead_tuples,
num_dead_tuples
FROM
pg_stat_progress_vacuum;
解读关键指标
phase: 这个字段表示VACUUM当前所处的阶段。我们可以通过这个字段了解VACUUM的进度。例如，如果phase是scanning heap，说明VACUUM正在扫描堆，查找“死元组”。heap_blks_total、heap_blks_scanned和heap_blks_vacuumed: 这三个字段可以帮助我们了解VACUUM已经处理了多少数据，还剩多少数据。我们可以通过计算heap_blks_scanned / heap_blks_total来估算VACUUM的进度。index_vacuum_count: 已清理的索引数量.- 如果查询结果为空, 则表示当前没有正在运行的
VACUUM进程.
案例分析
假设我们通过上面的查询发现，有一个 VACUUM 进程正在处理表 my_table，phase 是 vacuuming heap，heap_blks_total 是 1000，heap_blks_scanned 是 800，heap_blks_vacuumed 是 600。这说明 VACUUM 已经扫描了 80% 的数据块，清理了 60% 的数据块，进度已经过半。我们可以继续观察这个进程，直到它完成。
结合使用两个视图
pg_stat_all_tables 和 pg_stat_progress_vacuum 这两个视图通常需要结合使用，才能更全面地了解 VACUUM 的运行状态。
- 首先，通过
pg_stat_all_tables找出需要关注的表。 我们可以根据last_vacuum、last_autovacuum和n_dead_tup等字段，找出长时间没有进行VACUUM或者“死元组”数量较多的表。 - 然后，通过
pg_stat_progress_vacuum监控正在运行的VACUUM进程。 我们可以了解VACUUM的进度、所处的阶段等信息。 - 如果发现
VACUUM运行时间过长或者卡住，需要进一步调查原因。 可能是因为有长时间运行的事务阻塞了VACUUM，或者是因为VACUUM的配置不合理。
常见问题及排查
VACUUM运行时间过长: 可能是因为有长时间运行的事务阻塞了VACUUM。可以通过pg_stat_activity视图查看当前正在运行的事务，找出长时间运行的事务并进行处理。也有可能是表非常大，导致VACUUM需要很长时间才能完成。可以考虑使用VACUUM FULL（会锁定表，谨慎使用）或者调整 autovacuum 的参数，加快VACUUM的速度。VACUUM卡住: 可能是因为遇到了锁冲突。可以通过pg_locks视图查看当前的锁信息，找出导致锁冲突的进程并进行处理。- autovacuum 没有及时运行: 可能是因为 autovacuum 的配置不合理。可以检查
autovacuum_vacuum_threshold、autovacuum_vacuum_scale_factor、autovacuum_naptime等参数，根据实际情况进行调整。也可以检查 autovacuum 进程是否正常运行。 n_dead_tup持续增长: 可能是因为有大量的删除或更新操作，导致产生了大量的“死元组”。可以考虑优化应用程序，减少不必要的删除或更新操作。也可以调整 autovacuum 的参数，让 autovacuum 更频繁地运行。VACUUM后性能没有明显提升: 可能是因为VACUUM并没有清理多少“死元组”。可以检查VACUUM的日志，看看是否有错误信息。也有可能是因为其他原因导致性能问题，例如索引缺失、查询语句不优化等。
总结
VACUUM 是 PostgreSQL 中非常重要的维护操作，我们需要密切监控它的运行状态，确保它正常工作。pg_stat_all_tables 和 pg_stat_progress_vacuum 是两个非常有用的视图，可以帮助我们了解 VACUUM 的相关信息。通过结合使用这两个视图，并结合实际案例进行分析，我们可以及时发现并解决 VACUUM 相关的问题，保证数据库的健康运行。
希望今天的分享对大家有所帮助。如果你还有其他关于 PostgreSQL 的问题，欢迎在评论区留言，我会尽力解答。记住，数据库的健康，需要我们每个“老司机”的细心呵护！