PostgreSQL 性能测试——注意事项？答案

【问题标题】：PostgreSQL performance testing - precautions?PostgreSQL 性能测试——注意事项？
【发布时间】：2017-06-15 01:25:00
【问题描述】：

我对某些数据的索引结构进行了一些性能测试。我将并排比较 2 个索引（我还没有决定是否使用 2 个 VM）。当然，我要求结果尽可能中立，所以我有这些问题，我会很感激任何关于......我如何确保/控制影响测试的因素？例如，从一个测试到另一个测试的缓存效果/到达顺序将影响结果。我如何衡量这些影响？如何进行合适的热身？或者我可以使用什么样的统计技术来消除这些影响（我认为仅仅取平均值是不够的）？

【问题讨论】：

标签： database postgresql testing performance-testing

【解决方案1】：

开始之前：

确保您的表和索引刚刚创建和填充。这避免了与碎片有关的问题。否则，如果一个测试中的数据非常分散，而另一个不是，则您可能不会将苹果与苹果进行比较。
确保您的表格是正确的ANALYZEd。这可确保查询规划器在所有情况下都有正确的统计信息。

如果您只想要一个比较，而不是实际使用下的测试，我会这样做：

冷启动您的（虚拟）机器。等待一段合理但固定的时间（比如 5 分钟，或任何对您的系统而言合理的时间），以便所有启动过程都发生并且不会干扰数据库执行。
使用 index1 执行测试，并测量时间（这是指数据库和操作系统都没有缓存任何内容的时间）。
如果您对存在缓存效果时的结果感兴趣：再次执行测试 10 次（或任何合理的次数）。每次都进行测量，以考虑因 VM 上运行的其他进程和其他突发事件而导致的可变性。
重新启动您的计算机，然后对 test2 重复整个过程。有一些方法可以清理操作系统缓存；但它们非常系统依赖，而且您没有办法清理数据库缓存。检查See and clear Postgres caches/buffers?。
如果您真的（或最）对没有缓存效果的性能感兴趣，您应该多次执行整个过程。这是缓慢而乏味的。如果您只对（很可能）存在 cache 效果的情况感兴趣，则无需重新启动。
执行ANOVA（或您可能认为更适合的任何其他统计假设检验）以确定您的平均时间是否在统计上有所不同。

您可以在question about NOT NULL versus CHECK(xx NOT NULL). 的回答中看到执行多个测试的示例

【讨论】：

谢谢，非常有帮助的评论。是的，最终我只是想要一个比较，但要清楚，你对“现实使用不足”的理解是什么？
实际使用的意思是：因为你的应用程序和其他应用程序，数据库正在运行各种事务。您的服务器还运行其他进程，而不仅仅是数据库（比如说邮件服务器、Web 服务器、文件共享……您可以命名它）。在这种情况下，cache 效果会有很大的不同。一些 smallish 表可能被大量使用并且总是在数据库缓存中。其他一些可能只是部分缓存或根本不缓存......并且相同的确切查询可能从一次到下一次需要非常不同的时间。
嗨，已经有一段时间了，但重读你的观点让我有了一些新的思考。首先，应该多久分析一次表格？是的，新鲜的统计数据是个好主意，但是假设索引没有理由改变（例如，只执行了一些琐碎的选择查询）——那还需要经常分析吗？最后一点，数据库基准测试是否有一些官方标准？再次感谢您分享这么多信息。
如果 PostgreSQL 使用或多或少的标准配置，当更改数量超过某个阈值时，autovacuum 进程将负责重新分析您的表。但是，如果您想进行测试，请在开始之前（至少是第一次）进行分析，以确保您的所有测试都基于完全分析的数据。
关于基准，我不确定它们是否作为标准存在，但请检查TPC 看看是否符合您的需要。我知道 PostgreSQL 有 pgbench: 用于比较 PostgreSQL 的 versions 或不同 configuration settings 或 operating systems 或 的效果i>硬件.

【解决方案2】：

尽可能保持中立，然后在数据库管理系统的同一个实例上创建两个数据库，然后用数据创建相同的表空间，在一个实例上使用索引而不在另一个实例上使用索引。

虚拟机面临的挑战是您可以仲裁访问磁盘资源（除非您将每个虚拟机固定到特定的接口和磁盘集）。因此，您的仲裁模型可能因一项测试而异。消除仲裁的最中立的课程是在物理硬件上......并且在两种情况下都是相同的硬件。

【讨论】：