执行计划时间因平台而异答案

【问题标题】：Execution plan timings differ from one platform to another执行计划时间因平台而异
【发布时间】：2021-07-23 00:32:20
【问题描述】：

我们将生产从旧基础架构迁移到新基础架构（使用新网络/服务器/dc...）。

新硬件/存储应该至少相同或更好（因为它是新的，与 5 年或更早的旧硬件相比，没有质量降级）。

什么是相等的：

有什么不同：

我们注意到查询速度有点慢。我们开始在本地进行基准测试以排除网络层，并且仍然观察到之前和之后的差异。我们测试了一个简单的

\timing on
explain analyze select version();

在这方面，令人惊讶的是，我们也存在差异。之前：

之后：

我还仅使用本地磁盘进行了测试，以排除存储/iscsi/fc 层，并且仍然如此。此外，我每次都在 async slave 上进行测试（bench 查询只是 SELECT）。

这怎么解释？我们可以利用哪些杠杆来至少在本地检索以前的表现？

我正在考虑在 RHEL7 上对 PG 进行潜在的特定调整，或者与内存相关的东西？

【问题讨论】：

您的查询并未真正衡量查询性能。它衡量您可以多快地计划一个返回常量的函数。它不访问任何数据。您遗漏了有关 CPU 的任何细节。这是内部部署还是云计算？
您是否ANALYZE 新安装的数据库以更新统计表？
实际上，我们开始对数据进行基准访问，要么通过索引，要么强制全扫描，只有当我们注意到差异时，我们才尝试了这个选择版本（），我认为它应该只在内存中。真空数据库已经完成。不是云，本地测试。

【解决方案1】：

确实有太多的因素和很少的信息来确定到底发生了什么。

有根据的猜测是，这可能是由于存储或复制的变化造成的。同步复制可能会对性能产生影响，尤其是在写入繁重的情况下。

如果您没有内部基准，可以使用pgbench。使用相同的参数在两台服务器上运行它。

使用缩放，-s 标志，大到足以在您的服务器上创建足够的负载）。

确保您的基准测试运行至少几分钟（-t 和 -T 标志）。

通过使用 -r 标志，您将看到每个语句的延迟报告。

通过比较两台服务器上 pgbench 的结果，你应该对情况有了一个很好的了解。

如果我的猜测是正确的，你会发现在同步复制的系统上 UPDATE/INSERT 语句的延迟会更高。

另一个值得考虑的点是存储方面的差异。

不同的存储系统可能需要调整 random_page_cost and seq_page_cost 以优化您的工作负载。

【讨论】：

插入或更新等写入查询当然有所不同，但正如您所说，我们预料到了这一点。我们没想到的是在纯 SELECT 查询上也有不同。已经执行了基准测试，并确认我们在纯 SELECT 查询的新基础架构上处于两倍的时间，无论我们指向主节点还是从节点