我的团队在EDB的CTO团队中的大部分工作是研究和开发不同的方法和技术，通过自动调整、建议、监控等，使PostgreSQL更易于运行和管理。为了正确理解PostgreSQL的性能特征，并测试我们编写的代码，我们需要一种简单、一致地运行各种基准测试的方法。

我的同事德夫里姆·冈杜兹（Devrim Gunduz）、肖恩·托马斯（Shaun Thomas）、维克·费林（Vik Fearing）和我都未能找到一个好的方法来实现这一点，因此决定我们需要建立自己的公司。我们有一些初步要求：

• 该框架需要支持运行pgbench和HammerDB进行TPROC-C和TPROC-H测试。

• 它应该能够在多台服务器上并行运行测试，以避免需要多次连续运行（多次运行基准测试以确保结果一致始终很重要）。

• 配置基准应该很容易。

• 配置PostgreSQL（或EDB高级服务器）应该很容易。

• 从操作系统的干净安装中配置测试机器应该很容易。

• 它应该能够在测试运行之前选择性地清除缓存并预热数据库实例。

• 它应该支持多次运行的概念，其中可以使用不同的配置自动重复测试。

我们很快决定使用Ansible作为框架的基础。它的幂等声明性设计使得根据需要配置服务器变得简单，并且可以轻松地用于运行脚本命令。它对角色的使用以及在需要时导入剧本和配置的能力也允许我们尽可能多地重用代码。

自从我们最初构建框架以来，我们已经使用它在裸机服务器以及所有主要云提供商上运行了数百个基准测试。该框架可以在Github上找到。

核心功能

最初开发的框架包括以下特点：

系统配置

开发了Ansible playbook，用于设置测试中的系统或SUTs。这执行了许多功能：

• 设置包存储库和所需的GPG密钥和凭据。

• 安装所需的一组RPM软件包。

• 配置NTP。

• 配置sysstat（供将来使用）。

• 安装HammerDB（不作为RPM提供）。

• 安装并配置node_exporter，以便使用Prometheus进行额外监控。

• 配置合适的防火墙规则。

• 设置用于运行PostgreSQL的优化配置文件。

框架配置

框架使用了两个配置文件。库存yml是一个标准的Ansible清单文件，由用户从模板中复制，用于指定用于测试的服务器的详细信息。

第二个文件是config.yml用于指定测试的配置。这包括用于访问EDB Advanced Server RPM的存储库凭据、是否启用或禁用某些功能、PostgreSQL的配置参数（GUC）以及用于不同基准的配置参数，例如pgbench的比例因子。

参数（RUN_NUM）也定义为默认值1。该参数通常由用户或包含的运行基准在Ansible命令行上设置。sh脚本。Ansible使用Jinja2模板库，我们可以在配置文件中使用它来根据运行编号设置配置选项。这允许我们在更改配置的情况下多次执行测试。例如，我们可以在配置中设置以下配置。yml使用不同的shared_buffers值运行测试：

OVERRIDE_GUCS:
   - name: max_connections
     value: 250
   - name: huge_pages
     value: on
   - name: shared_buffers
     value: "{{ '8GB' if RUN_NUM|int > 3 else '4GB' if RUN_NUM|int > 2 else '1GB' if RUN_NUM|int > 1 else '128MB' }}"

这会将max_connections设置为250，启用巨大的页面，然后将shared_buffers设置为运行1的128MB，运行2的1GB，运行3的4GB，最后是运行4的8GB（以及任何其他运行）。

要在4次运行中执行该测试（在TPROC-C模式下使用HammerDB），我们可以使用运行基准。sh脚本如下：

./run-benchmark.sh tprocc 4

清理、初始化、调整和启动/停止PostgreSQL

重要的是，每次执行测试运行时，PostgreSQL都处于已知状态。这需要一组在过去运行之后进行清理的Playbook，然后创建一个新的PostgreSQL数据库（使用initdb），调优数据库服务器，并启动它以供使用。

初始化测试数据库

一旦配置了PostgreSQL，我们需要为将要运行的测试加载一个模式。编写剧本是为了执行此任务，在初始化模式下使用config.yml中指定的参数运行pgbench或HammerDB。创建模式后，将对其进行备份，以便在将来运行时恢复。恢复备份比从头开始重新创建模式要快得多。注意根据基准类型和基准配置来分离备份。例如，将创建单独的备份，并在以后使用不同的比例因子重新用于pgbench。

执行基准

使基准测试的执行保持一致和正确与确保每个测试从已知状态开始同样重要。与初始化手册一样，有运行每个基准的手册。这些都遵循相同的基本结构：

• 如果配置为这样做，请停止PostgreSQL（清除其缓存），清除内核缓存，然后重新启动PostgreSQL。

• 记录服务器配置和预运行状态。

• 如果配置为预热数据库服务器，请对其进行预热。

• 运行基准测试。

• 记录运行后的统计数据。

• 将日志文件下载到控制器计算机。

聚集

在构建了所有必需的部分之后，编写了“元”剧本来运行每种类型的测试。这些确保我们从已知状态开始，初始化和调优PostgreSQL，然后初始化和运行基准测试，所有这些都以正确的顺序进行，而不会遗漏任何步骤。这些剧本被称为运行基准。sh脚本，该脚本是为了在执行多个运行时方便而添加的。

此外，还编写了其他辅助脚本，用于将结果以更有组织的格式复制到长期存档（在我们的情况下，在Google Drive上），并用于从日志文件中提取关键指标，以文本格式快速查看，或以适当的格式轻松复制并粘贴到电子表格中。

进一步增强

自最初开发以来，该框架已进一步增强，以提供更多功能：

驱动机器

最初，人们通常会在控制器机器上运行Ansible框架，而其他一切都在一个或多个SUT上运行。这种配置与许多实际应用程序不匹配，其中应用程序在一台服务器上运行，数据库在另一台服务器中运行。

为了克服这一问题，增加了驾驶员的概念；配置中的每个SUT可以可选地具有与其关联的驱动器机器。如果是这种情况，则在驱动程序上执行基准软件，访问SUT上的数据库服务器。

钩子

有各种钩子可用于在不同点扩展框架的功能。其主要驱动因素是允许我们将框架作为GIT子模块包含在其他项目中，包括特定于项目的钩子代码，用于安装和配置PostgreSQL扩展作为测试初始化的一部分，并记录扩展运行前后的统计数据。

特设监测员

可以在测试运行期间执行Shell脚本以记录临时统计信息。例如，我们添加的第一个监视器是使用pg_buffercache扩展来监视PostgreSQL缓冲区缓存中块的使用计数。这使我们能够看到共享缓冲区在不同工作负载和不同大小缓存下的行为。监视器将统计数据记录在CSV文件中，该文件在运行结束时自动从正在测试的系统下载。然后，包含的助手脚本可以将其转化为图形进行可视化，或者将文件导入电子表格进行分析。下图是pgbench测试运行的缓冲区缓存监控示例：

sysctl配置

添加了支持，以允许在运行之前配置系统内核。这在测试具有不同值的shared_buffers的巨大页面时是必要的；我们需要能够为vm设置适当的值。nr_hugepages内核配置参数与每次运行使用的共享缓冲区大小相对应。

正在进行的工作和未来的工作

Devrim目前仍在进行中，目前正在为Mark Wong的DBT-2实现添加支持，这将允许我们使用另一个工作负载进行测试。

此外，在最近对我们的一个项目进行的一些测试中，很明显，我们需要能够定义自定义工作负载的能力，以便测试特定的更改；例如，与您可能期望的相反，HammerDB中的TPROC-H测试不包括许多大型排序，因此在测试PostgreSQL排序代码的潜在改进时，我们将受益于运行专门设计用于测试该代码的基准测试的能力。pgbench被设计为允许运行自定义测试脚本，添加支持可能会解决这个问题。

结论

我们对我们构建的框架感到非常自豪，因此决定将其开源（在PostgreSQL许可下），希望其他人也会发现它有用。我们一直致力于设计它，以确保测试易于同时在多台机器上并行运行，以易于使用的方式确保有效和一致的结果，同时提供高度的可配置性和定制性，以帮助将其作为可能具有特定需求和要求的开发项目的一部分使用。

您可以在Github上找到该框架，以及一份全面的自述文件，可以帮助您快速轻松地启动和运行。请随时尝试，并在Github上记录任何问题或拉取请求。

关于作者

Dave Page是数据库基础设施副总裁兼首席架构师，目前在CTO团队工作，负责研究和开发、Postgres的最佳实践，并为关键客户提供高级指导和支持。Dave自1998年以来一直与PostgreSQL合作。

原文标题：Ansible Benchmark Framework for PostgreSQL
原文作者：Dave Page
原文链接：https://www.enterprisedb.com//blog/ansible-benchmark-framework-postgresql