使用大型Linux页面对PostgreSQL进行基准测试

Linux内核提供了多种可能影响性能的配置选项。 所有这些都是为您的应用程序和工作负载获取正确的配置。 像任何其他数据库一样，PostgreSQL使用Linux内核进行最佳配置。 设置不当会导致性能下降。 因此，在每个调优会话之后测量数据库性能以避免性能下降很重要。 在我以前的出版物之一“为PostgreSQL优化调整Linux内核参数”中，我描述了一些最有用的Linux内核参数以及它们如何帮助您提高数据库性能。 现在，在设置具有不同PostgreSQL工作负载的大型Linux页面之后，我将分享测试结果。 我对不同的PostgreSQL负载大小和同时客户端数量进行了详尽的测试。

试验机

• Supermicro服务器：
  
  • 英特尔®至强®CPU E5-2683 v3 @ 2.00GHz
  • 2个插槽/ 28芯/ 56线程
  • 内存：256GB RAM
  • 储存：SAMSUNG SM863 1.9TB企业级SSD
  • 文件系统：ext4 / xfs
• 操作系统：Ubuntu 16.04.4，kernel 4.13.0-36-generic
• PostgreSQL：版本11

Linux内核设置

除了禁用透明大页面（Transparent HugePages）以外，我使用默认内核设置没有进行任何优化/调整。 透明大页面默认情况下处于启用状态，并突出显示页面大小，数据库可能不建议使用该大小。 数据库通常需要固定大小的大页面，而透明大页面则无法覆盖这些页面。 因此，始终建议您禁用此功能并默认使用经典大页面。

PostgreSQL设置

我对所有测试使用统一的PostgreSQL设置，以针对大型Linux页面使用不同的设置记录不同的PostgreSQL工作负载。 这是用于所有测试的PostgreSQL设置：

^{postgresql.conf}

shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON' 

测试方案

在测试中，测试方案起着重要的作用。 对于每次运行，所有测试均进行3次，每次30分钟。 我取了这三个指标的平均值。 使用PostgreSQL pgbench性能测试工具进行了测试。 pgbench使用比例因子，其中一个比例因子约为16 MB的工作负载。

大页面（HugePages）

默认情况下，Linux使用4K页内存和大页内存。 BSD具有超级页面，而Windows具有大型页面。 PostgreSQL仅支持大页面（Linux）。 在高内存使用情况下，小页面会降低性能。 通过安装大页面，可以增加为应用程序分配的内存，从而减少分配/交换过程中产生的运营成本。 也就是说，您可以使用大页面来提高生产率。

这是使用1 GB的大页面大小时大页面的设置。 您始终可以从/ proc获取此信息。

^{$ cat / proc / meminfo | grep -i巨大}

 AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB 

有关大页面的更多信息，请阅读我以前的博客文章。

https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

通常，大页面为2 MB和1 GB，因此有意义的是使用1 GB而不是小得多的2 MB。

https://access.redhat.com/documentation/zh-CN/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/

测试结果

该测试显示了各种尺寸的大页面的总体效果。 第一个测试套件是使用Linux 4K上的默认页面大小创建的，不包括大页面。 请注意，透明的大页面也被禁用，并且在所有这些测试中均保持禁用状态。

然后在2 MB的大页面上执行第二组测试。 最后，第三组测试在1 GB的大页面上运行。

所有这些测试都是在PostgreSQL版本11中执行的。这些集合包括数据库和客户端大小不同的组合。 下图显示了这些测试的可比较性能结果，其中Y轴为TPS（每秒事务数），X轴为数据库大小，每个数据库大小的客户端数量。



从上图可以看出，如果页面的大小保留在共享内存中先前分配的缓冲区中，则大页面的性能提升会随着客户端数量和数据库大小的增加而增加。

此测试显示了与客户端数量相比的TPS。 在这种情况下，数据库大小为48 GB。 在Y轴上，我们有TPS，在X轴上，我们有连接的客户端数。 数据库大小足够小以适合设置为64 GB的共享缓冲区。



如果将大页面设置为1 GB，则客户端越多，相对性能增益就越高。

除了96 GB的数据库大小之外，以下图形与以上图形相同。 这超出了设置为64 GB的共享缓冲区的大小。



此处的主要观察结果是，随着客户端数量的增加，具有1 GB大页面的性能会提高，并且最终它会提供比2 MB大页面或4 KB标准页面大小更高的性能。

此测试根据数据库的大小显示TPS。 在这种情况下，连接的客户端数为32。在Y轴上，我们有TPS，在X轴上，我们有数据库大小。



不出所料，当数据库超出预分配的大页面时，性能将大大降低。

总结

我的主要建议之一是我们应该禁用“透明HugePages”。 将数据库放在启用了大页面的共享缓冲区中时，您将看到最大的性能提升。 选择大页面的大小需要少量的反复试验，但是当数据库大小很大但仍然足够小以适合共享缓冲区时，这可能会导致TPS显着增加。