主页 / dba / 问题 / 314894
Accepted
Dolphin
Asked: 2022-07-27 21:18:38 +0800 CST

是否有可能永远不会在 PostgreSQL 中运行vacuum full

  • 772

由于VACUUM FULL锁表，在我们的生产环境中对我们来说是不可接受的。

是否可以只在生产系统上运行VACUUM而从不运行？VACUUM FULL

是否VACUUM使新空间可重复使用INSERT？

postgresql locking

2 个回答

  1. Best Answer

    为了了解它们之间的区别

    • VACUUM
    • VACUUM ANALYZE
    • VACUUM FULL,

    需要对 PostgreSQL 的体系结构有基本的了解。

    从几个9s 1我们被告知：

    • PostgreSQL 不使用 IN-PLACE 更新机制，所以按照 DELETE 和 UPDATE 命令的设计方式，

      • 每当执行 DELETE 操作时，它会将现有元组标记为 DEAD，而不是物理删除这些元组。
      • 同样，每当执行 UPDATE 操作时，它会将相应的现有元组标记为 DEAD 并插入一个新元组（即 UPDATE 操作 = DELETE + INSERT）。

    这会导致所谓的“膨胀”——即表会变得更大，即使由于这些死元组而导致记录数保持不变。

    从EnterpriseDB 2，我们有：

    • 当真空进程运行时，这些死元组占用的空间被标记为可被其他元组重用。

    这与删除文件系统中的文件类似——该空间仅被标记为可重用，实际上并没有删除任何内容。这无关紧要 - 需要注意的重要一点是，该行占用的空间再次可用于该表的 PostgreSQL 服务器！

    和之间的主要区别在于，使用 a ，释放的空间也可供操作系统使用！如果您希望执行备份并且磁盘空间不足，这可能会很有用。从这里：VACUUMVACUUM FULLVACUUM FULL

    • Vacuum full 取出排他锁并重建表，使其没有空块（我们现在假设填充因子为 100%）。

    因此，VACUUM FULL类似于对磁盘文件进行碎片整理（考虑磁盘文件 ≡ PostgreSQL 表），从Percona 3我们有：

    VACUUM FULL 是 PostgreSQL 安装可用的默认选项，它允许我们重新构建表。[强调我的]

    但是，此重建确实需要Access Exclusive Lock，正如手册指出的那样：

    • 访问独家

      与所有模式的锁冲突（ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE 和 ACCESS EXCLUSIVE）。这种模式保证 持有者是唯一以任何方式访问表的事务。[强调我的]

    显然，正如您所指出的，完全重写该表并不适合生产。手册甚至说：

    • 通常这应该只在需要从表中回收大量空间时使用。

    所以，回答你的2个问题：

    问：1)

    真空是否使新插入的空间可重复使用？

    是的，确实如此，但更重要的是，它不需要访问独占锁。从文档中，我们发现：

    Autovacuum 工作人员通常不会阻止其他命令。

    Autovacuum 是VACUUM没有的FULL，通常在postgresql.conf文件中配置。

    VACUUM需要一个 SHARE UPDATE EXCLUSIVE 锁。

    同样，来自手册：

    此模式保护表免受并发模式更改和 VACUUM 运行。

    或者正如知识渊博的 PostgreSQL 贡献者所解释的那样：

    Autovacuum 确实会在表上加锁，但它是一个弱锁，不会干​​扰正常操作（SELECT、UPDATE、DELETE），但会干扰添加索引或截断表等操作。

    上面引用的 EnterpriseDB 博客给出了“VACUUM and ANALYZE Best Practice Tips”——就我个人而言，我通常会建议更新表的统计信息以供优化器使用ANALYZE！VACUUM本文还可以帮助您决定何时可能要运行VACUUM.

    问 2)

    主题中提出的问题。

    是否有可能永远在 PostgreSQL 中完全运行真空

    是的，可以永远不运行它，尤其是在不担心磁盘空间的情况下。然而，这可能是值得的，因为完整的表重写（连同索引）可以对查询性能产生有益的影响——物理顺序的记录可以减少需要扫描的页面！

    结论。

    这是一个复杂的问题，一篇完整的文章不可能很长，但我强烈建议您阅读此处的参考资料（以及此处、此处、此处（填充因子）和此处的页面）。

    当然，您不希望VACUUM在繁忙时间中断您的生产系统。决定最佳策略几乎与 IT 中的所有其他事情相同 - "It depends!".

    需要考虑磁盘空间和 I/O 负载参数，您必须达成最适合所有利益相关者的折衷方案。

    1）几个9s 是一个优秀的站点，用于PostgreSQL 的所有内容。
    2）EnterpriseDB也是一个优秀的站点，也是最大的PostgreSQL公司，拥有大量的核心团队成员和贡献者。
    3) Percona，虽然以前是一家 MySQL 公司，但现在也有一个 PostgreSQL 发行版，并且他们赞助了有前途的pg_stat_monitor扩展（另见此处）。他们受到高度评价。

    • 2

  2. 对于超级用户，我们不能阻止vacuum full 并且只在table 上进行vacuum 不会使空间可重用，我们必须使用vacuum full 来物理删除死元组。

    • -1

相关问题