0

我最近不得不在工作中安装 slony（2.0.2 版）。一切正常，但是，我的老板想在复制期间降低从节点上的 cpu 使用率。在网上搜索并没有发现任何明显的答案。任何有助于降低 CPU 使用率（或将更新分散到更长的时间）的建议将不胜感激！

4

3 回答 3

1

Magnus 可能是对的，这很可能只是您的数据库具有非常高的流量这一事实的症状。Slony 有效地增加了任何给定 DML 操作的资源使用量：不仅将数据 CRUD'ed 到复制主机，而且每次发生这种情况时，Slony 触发器（将其视为更改侦听器）生成相同的事务并将其转发到Slon 进程，它在集群的其他成员上运行它。

但是，此问题还有另外两种可能的解释/解决方案：

  1. 一个可能的解决方案可能是在与数据库主机不同的机器上运行 slon 进程。即使你有一个单主/单从复制方案，在稳定性、角色隔离和性能（就是你）方面，在物理上不同的一组硬件上运行 slon 复制守护程序（在同一LAN 段，理想情况下）。Slony 并没有说它必须与给定的数据库主机在同一台机器上运行，因此将它放在不同的位置（想想“流量控制器”）可能会减轻数据库主机上的一些资源负载。这在机器稳定性和可扩展性方面也是一个好主意。

  2. 这也有可能只是您最近开始使用 Slony 造成的暂时问题。当您第一次将新节点订阅到复制集时，该节点（以及在某种程度上，它的父节点）在订阅过程中会经历非常重的 CPU 负载（可能还有磁盘负载）。我不确定它在幕后是如何工作的，但是，根据订阅的节点上已经有多少数据，Slony 将检查主节点的数据与复制表中从节点上存在的每一条数据，并且如果数据丢失或不同，则将数据复制到从站。这些是潜在的 CPU 密集型操作。尤其是大型数据库，订阅过程可能需要很长时间（我花了一天多，但我们的数据库超过20GB），在此期间 CPU 负载将非常高。查看 Slony 在做什么的简单方法是使用pgAdmin 的服务器状态查看器，虽然有限，但会在此处为您提供一些有用的信息。如果在 CPU 负载较高的节点上进行大量“为复制准备表”或“复制后清理表”操作，可能是因为订阅未完成。然而，pgAdmin 的状态查看器信息量不是很大；有更可靠的方法可以直接使用 Slony 检查订阅进度。Slony 日志分析文档中的第 4.7.6.4 节可能会对此有所帮助，阅读SUBSCRIBE SET 的文档也会有所帮助（特别注意盒装警告消息和“危险/不直观的行为”部分。判断一个集合是否仍在订阅过程中的一个简单而明确的技巧是运行一个 MERGE SET 并尝试将它与一个空（或不）其他集。如果订阅仍在运行，则 MERGE SET 将失败并出现“正在订阅”错误。但是，该 hack 不适用于 Slony 2.1；MERGE SET 将一直等到订阅完成。

于 2011-10-27T14:58:40.140 回答
1

您是否在这里查看过一般的 PostgreSQL 调优？如果服务器没有提供足够的资源来处理冗余工作，服务器可能会浪费大量的 CPU 周期，并且默认配置非常小。 Tuning Your PostgreSQL Server在这里是一个有用的指南，shared_buffers 和 checkpoint_segments 是两个参数，您可能会从从属服务器上获得一些显着的改进（其余的许多参数只真正有助于改善查询时间）。

于 2009-06-27T06:44:18.030 回答
0

减少 CPU 使用率的最佳方法是将更少的数据放入数据库:-)

除此之外，您可以尝试使用sync_interval。这可能是您正在寻找的东西。

于 2009-06-25T14:58:23.757 回答