Linux内核提供了多种可能影响性能的配置选项。 最主要的是为您的应用程序和工作负载选择正确的配置。 像任何其他数据库一样，PostgreSQL需要对Linux内核进行最佳调整。 不正确的设置可能会导致性能下降。 在每个调优会话之后进行数据库性能的比较分析非常重要。 在我以前的一篇文章中，标题为“为PostgreSQL优化调整Linux内核参数”，我描述了一些最有用的Linux内核参数以及它们如何帮助提高数据库性能。 现在，在各种PostgreSQL负载下在Linux上配置HugePages之后，我将分享比较测试的结果。 我在具有不同数量的并发客户端的许多不同PostgreSQL工作负载下进行了完整的测试套件。
在其上执行测试的PC
- Supermicro服务器：
- 英特尔®至强®CPU E5-2683 v3 @ 2.00 GHz
- 2个插槽/ 28芯/ 56线程
- 内存：256 GB RAM
- 储存：SAMSUNG SM863 1.9 TB企业级固态硬盘
- 文件系统：ext4 / xfs
- 操作系统：Ubuntu 16.04.4，kernel 4.13.0-36-generic
- PostgreSQL：版本11
Linux内核设置
我使用了默认的内核参数，没有进行任何优化/调整，只禁用了透明HugePages。 默认情况下启用此技术，并分配不建议用于数据库的大小的页面。 通常，数据库需要固定大小的HugePage，但是透明HugePages无法提供它们。 因此，始终建议禁用此功能，并且默认情况下安装经典HugePages。
PostgreSQL设置
我对所有测试使用了相同的PostgreSQL设置，以记录具有不同Linux HugePages设置的不同PostgreSQL工作负载。 对于所有测试，都应用了以下PostgreSQL设置：
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分钟。 根据这3个测试的结果，我推导出平均值。 测试是使用PostgreSQL pgbench工具进行的；它以比例因子工作，并以大约16 MB的负载为增量。
大页面
默认情况下，Linux使用4K内存页以及HugePages技术。 BSD使用超级页面技术，而Windows使用大页面。 PostgreSQL仅支持HugePages（Linux）技术。 如果使用的内存量很大，则较小的页面会降低性能。 使用HugePages，可以增加为应用程序分配的内存，从而减少分配/交换过程中发生的“开销”。 因此，HugePages可以提高生产率。
这是大小为1 GB的HugePages的设置。 可以随时使用/ proc获得此信息。
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
我在上一篇文章中写了更多有关HugePages的内容。
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
通常，HugePages的大小为2 MB，1 GB，因此使用1 GB是合理的。
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/
测试结果
该测试显示了使用各种大小的HugePages的总体效果。 创建的第一个测试套件的页面大小为4K（在Linux中默认使用），并且未激活HugePages。 让我提醒您：在整个测试过程中，我禁用了“透明HugePages”选项。
然后，对大小为2 MB的HugePage执行第二组测试。 最后，对1GB HugePages运行了第三组测试。
对于所有比较测试，均使用PostgreSQL DBMS 11，套件包括各种数据库大小和各种客户端的组合。 下图显示了使用这些测试进行性能比较的结果：TPS（每秒事务数）-沿Y轴，数据库大小和特定大小的数据库的客户端数-沿X轴。
从上图可以看出，通过使用HugePages，收益随着客户数量和数据库大小的增加而增加，只要该大小保持在预分配的共享缓冲区内。
该测试比较了TPS和客户数量。 在这种情况下，数据库大小为48 GB。 Y轴显示TPS，X轴显示连接的客户端数。 数据库大小足够小以适合固定大小为64 GB的共享缓冲区。
当HugePages的大小为1 GB时，相对性能的提高随客户数量的增加而增加。
下一张图与上一张相同，但是数据库大小为96 GB。 这大于64 GB的固定总缓冲区大小。
这里要注意的主要事情是：1 GB的HugePages的性能随客户数量的增加而提高，并且最终提供比2 MB的HugePages或标准4 KB页面的性能更好的性能。
此测试显示TPS与数据库大小的比率。 在这种情况下，连接的客户端数为32。在Y轴上显示TPS，在X轴上显示数据库大小。
不出所料，当数据库的大小超过预分配的HugePages的大小时，性能将大大降低。
结论
我的主要建议之一是禁用“透明HugePages”。 如果将数据库放在启用了HugePages的共享缓冲区中，则可以最大程度地提高性能。 HugePages的最佳大小是由反复试验确定的，但是当数据库大小足够大但同时又允许它适合公共缓冲区时，这种方法可能会导致TPS的显着增加。