Sentry数据库sentry_eventtag表执行VACUUM FULL后容量未缩减的问题排查求助

我之前处理过类似的Sentry PostgreSQL表膨胀问题，尤其是sentry_eventtag这种关联事件与标签的核心表，分享几个实战过的排查思路和解决办法：

先排查VACUUM FULL失效的核心原因 #

• 长事务/未提交事务阻塞清理：PostgreSQL的VACUUM FULL需要获取表的排他锁，如果有长时间运行的事务（比如慢查询、或处于idle in transaction状态的会话）持有该表的锁，会导致清理无法彻底完成。你可以用以下命令排查：

  SELECT pid, query, state, now() - xact_start AS duration 
  FROM pg_stat_activity 
  WHERE (query LIKE '%sentry_eventtag%' OR state = 'idle in transaction') 
  AND pid != pg_backend_pid();
  

  找到可疑事务后，确认可以安全终止的话，用SELECT pg_terminate_backend(pid);结束会话，再重新执行VACUUM FULL sentry_eventtag;。

• 索引膨胀掩盖了表清理效果：有时候sentry_eventtag的索引膨胀比表本身更严重，VACUUM FULL虽然清理了表数据，但索引的膨胀没解决，导致整体空间看起来没减少。先查看表和索引的空间占比：

  SELECT 
    relname AS table_name,
    pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
    pg_size_pretty(pg_relation_size(relid)) AS table_size,
    pg_size_pretty(pg_indexes_size(relid)) AS index_size
  FROM pg_stat_user_tables 
  WHERE relname = 'sentry_eventtag';
  

  如果索引占比超过70%，建议先重建索引：

  REINDEX TABLE sentry_eventtag;
  

  重建完成后再执行VACUUM FULL，通常能看到明显的空间释放。

• PostgreSQL版本缺陷：如果你的PostgreSQL版本低于10，旧版本在处理频繁更新/删除的关联表时，VACUUM FULL的清理逻辑存在局限性。这种情况下，升级到12+的稳定版本（Sentry官方推荐的版本），能从底层解决部分膨胀问题。

替代清理方案：用pg_repack在线处理 #

如果VACUUM FULL因为锁表问题无法执行（毕竟Sentry是在线服务，长时间锁表会影响业务），可以用pg_repack工具——它不需要排他锁就能在线重建表和索引，彻底清理膨胀数据。

安装完成后，执行以下命令即可：

pg_repack -d <你的Sentry数据库名> -t sentry_eventtag

这个工具会在后台创建临时表，逐步迁移数据，最后替换原表，全程几乎不影响业务访问。

从根源减少表膨胀 #

解决当前问题后，还要从根源避免再次膨胀：

• 调整Sentry的事件保留策略：在Sentry后台设置合理的事件保留时长，比如保留30天以内的事件，Sentry会自动清理旧的sentry_eventtag关联数据。
• 检查标签生成逻辑：如果业务中生成了大量重复或无用的标签，会导致sentry_eventtag表快速增长。优化业务代码，减少不必要的标签上报。

另外你提到执行VACUUM时看到空间释放但结束后又恢复，大概率是WAL日志未及时归档导致的。VACUUM过程中会生成临时文件，清理后WAL日志可能还在磁盘上，等归档完成后（通常需要几分钟），磁盘空间才会真正释放。可以用SELECT pg_walfile_name(pg_current_wal_lsn());查看当前WAL日志，确认对应的文件已经归档到指定目录。

内容的提问来源于stack exchange，提问作者nishad salam