PostgreSQL Replication之第五章 设置同步复制（2）

5.2 理解实际影响和性能

在本章中，我们已经讨论了实际影响以及性能影响。但是，有什么好的理论性的例子吗？让我们做一个简单的基准测试，看看复制是怎么做的。我们做这样的测试来为您显示各种耐久性的级别不只是一个次要的话题，对性能来说它们是关键的。

让我们假设一个简单的测试：在下面的场景中，我们已经连接到两个同样强大的机器(3 GHz, 8 GB RAM) 超过1 Gbit 的网络。两台机器彼此相邻。为了演示同步复制的影响，我们使用 shared_buffers 和所有其他内存参数的默认设置，仅仅把 fsync 设置为 off来确保磁盘等待影响几乎降低到0。

该测试很简单：我们使用一个只有一个整型字段的表和包括只有一个INSERT语句的10000笔事务：

INSERT INTO t_test VALUES (1);

我们可以尝试这个完全的同步复制(synchronous_ commit = on):

real 0m6.043s

user 0m0.131s

sys 0m0.169s

正如您所看到的，测试用了大约六秒就可以完成。现在使用 synchronous_commit = local (这实际上意味着异步复制)来重复该测试:

real 0m0.909s

user 0m0.101s

sys 0m0.142s

在这个简单的测试中，您可以看到速度提升了六倍。当然这是一个暴力的例子，这并不能完全地反映现实情况(这不是目标)。要理解什么是重要的，同步复制和异步复制并不是几个百分点的区别。这更加强调了我们的观点：只要真正地需要同步地复制，如果您真的需要使用同步复制，确保您的同步事务数量绝对地小。

另外，请确保您的网络能够满足工作需求。通过带有高延迟的网络连接同步地复制数据肯定不知不觉地会破坏您的系统性能。请记住，没有办法通过昂贵的硬件解决这个问题。实际上，加倍您的服务器的时钟速度对您来说并没有用，因为真正的限制总是来自网络延迟，只来自网络延迟。

[只有一个连接的性能损失肯定比许多连接的情况下大。请记住，可以在并行方面做工作，网络延迟并没有使用我们更多的I/O或CPU带宽，所以，我们可以通过启动更多的并发工作来降低慢事务的影响。]

使用同步复制时，您怎么能确保性能不会有太大的损失？基本上，有几个已被证明的有帮助的重要的建议：

• 使用较长的事务: 记住,，系统必须确保提交的数据在两台服务器上是可用的；我们并不关心事务的中间过程，因为您的事务之外的任何人都不会看到数据。较长的事务会大幅地减少网络通信。

• 运行并行任务: 如果您有多个事务同时运行，它一定会对性能有利。原因是，远程服务器将返回XLOG内部的位置被认为是安全的进程(刷新或接收)。此方法确保了多事务可能会在同一时间得到批准。