问题描述
我们将生产从旧基础设施迁移到新基础设施（使用新网络/服务器/直流......）。
新硬件/存储应该至少相等或更好（因为它是新的，质量没有降级，与 5 年或更旧的旧硬件相比）。
什么是平等的：
有什么不同：
- 操作系统发布（之前：rhel6，之后：rhel7）
- 存储（之前：光纤通道，之后：iscsi）
- 架构（之前：1 个主 + 1 个异步从，之后：1 个主 + 1 个同步从 + 1 个异步从）
- cpu：相同的缓存但不同的周期（之前：3199MHz，之后：3600MHz）
我们注意到查询速度有点慢。 我们开始在本地进行基准测试以排除网络层，并且仍然观察到之前和之后的差异。 我们测试了一个简单的
\timing on
explain analyze select version();
在这里，令人惊讶的是，我们也有不同之处。 之前：
- 平均规划时间：0.005 毫秒
- 平均执行时间：0.006ms
- 平均计时：0.090 毫秒
之后：
- 平均规划时间：0.016 毫秒
- 平均执行时间：0.018ms
- 平均计时：0.255 毫秒
我还仅使用本地磁盘进行了测试，以排除存储/iscsi/fc 层。 此外，我每次都在 async slave 上进行测试（bench 查询只是 SELECT）。
这怎么解释？我们可以使用哪些杠杆来至少在本地检索以前的表现？
我在考虑在 RHEL7 上对 PG 进行潜在的特定调整还是与内存相关的一些事情？
解决方法
确实有太多的因素和很少的信息来确定正在发生的事情。
有根据的猜测是，这是由于存储或复制的变化。 同步复制会对性能产生影响，尤其是在大量写入的情况下。
如果您没有内部基准，您可以使用 pgbench。在两台服务器上运行它，使用相同的参数。
使用缩放 -s 标志，足够大以在您的服务器上创建足够的负载）。
确保您的基准测试至少运行几分钟（-t 和 -T 标志）。
通过使用 -r 标志，您将看到每个语句的延迟报告。
通过比较两台服务器上 pgbench 的结果，您应该对情况有一个很好的了解。
如果我的猜测是正确的，您会发现在具有同步复制的系统上，UPDATE/INSERT 语句的延迟会更高。
另一点值得考虑的是存储的差异。
不同的存储系统可能需要调整 random_page_cost and seq_page_cost 以优化您的工作负载。