Postgres pgbench简单性能测试 参数调优

简单介绍

Postgres安装好后默认的参数都设置的比较小，因此在使用数据库中想要获得比较好的性能，就必须对一些默认参数做调整。本文介绍在给客户安装时系统环境做一些简单的调整，后续可根据实际业务场景和使用情况做性能调优。

参数介绍

max_connections

数据库的最大并发连接数。默认值通常是 100 个连接。

fsync

如果打开这个参数，PostgreSQL服务器将尝试确保更新被物理地写入到磁盘，做法是发出fsync()系统调用或者使用多种等价的方法（见wal_sync_method）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。
虽然关闭fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync。

shared_buffers

数据库服务器将使用的共享内存缓冲区量。默认通常是128MB。如果有一个专用的 1GB 或更多内存的数据库服务器，一个合理的shared_buffers开始值是系统内存的 25%。即使更大的shared_buffers有效，也会造成一些工作负载， 但因为PostgreSQL同样依赖操作系统的高速缓冲区，将shared_buffers设置为超过 40% 的RAM不太可能比一个小点值工作得更好。为了能把对写大量新的或改变的数据的处理分布在一个较长的时间段内，shared_buffers更大的设置通常要求对max_wal_size也做相应增加。
如果系统内存小于 1GB，一个较小的 RAM 百分数是合适的，这样可以为操作系统留下足够的空间。

work_mem

设置在写入临时磁盘文件之前查询操作(例如排序或哈希表)可使用的最大内存容量。默认值是4MB。 注意对于一个复杂查询， 可能会并行运行好几个排序或者哈希操作；每个操作都会被允许使用这个参数指定的内存量，然后才会开始写数据到临时文件。同样，几个正在运行的会话可能并发进行这样的操作。因此被使用的总内存可能是work_mem值的好几倍，在选择这个值时一定要记住这一点。ORDER BY、DISTINCT和归并连接都要用到排序操作。哈希连接、基于哈希的聚集以及基于哈希的IN子查询处理中都要用到哈希表。

effective_cache_size

设置规划器对一个单一查询可用的有效磁盘缓冲区尺寸的假设。 这个参数会被考虑在使用一个索引的代价估计中，更高的数值会使得索引扫描更可能被使用，更低的数值会使得顺序扫描更可能被使用。 默认值是 4GB。

maintenance_work_mem

指定在维护性操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）中使用的 最大的内存量。 其默认值是64MB。因为在一个数据库会话中，一个时刻只有一个这样的操作可以被执行，并且一个数据库安装通常不会有太多这样的操作并发执行， 把这个数值设置得比work_mem大很多是安全的。 更大的设置可以改进清理和恢复数据库转储的性能。
注意当自动清理运行时，可能会分配最多达这个内存的autovacuum_max_workers倍，因此要小心不要把该默认值设置得太高。 通过独立地设置autovacuum_work_mem可能会对控制这种情况 有所帮助。

wal_buffers

事务日志缓冲区的大小，PostgreSQL将WAL记录写入缓冲区，然后再将缓冲区刷新到磁盘。在PostgreSQL 12版中，默认值为-1，也就是选择等于shared_buffers的1/32 。如果自动的选择太大或太小可以手工设置该值。一般考虑设置为16MB。

commit_delay

在一次 WAL 刷写被发起之前，commit_delay增加一个时间延迟。 如果系统负载足够高，使得在一个给定间隔内有额外的事务准备好提交，那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量。 但是，它也把每次 WAL 刷写的潜伏期增加到了最多commit_delay。 因为如果没有其他事务准备好提交，就会浪费一次延迟，只有在当一次刷写将要被发起时有至少commit_siblings个其他活动事务时，才会执行一次延迟。 另外，如果fsync被禁用，则将不会执行任何延迟。 如果指定值时没有单位，则以微秒作为单位。 默认的commit_delay是零（无延迟）。只有超级用户才能修改这个设置。
在PostgreSQL的 9.3 发布之前，commit_delay的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使在 WAL 刷写马上就要完成时也会等待一整个配置的延迟。从PostgreSQL 9.3 中开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。

commit_siblings

在执行commit_delay延迟时，要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。

简单修改参数

参数设置

修改work_men需要考虑整个内存的大小，可以参照如下公式：max_connections*work_mem+shared_buffers+temp_buffers+maintenance_work_mem+操作系统所需内存<RAM。简单修改一下参数配置，pgbench测试的结果，参数修改完需要重启数据生效。

alter system set shared_buffers='1GB';
alter system set work_mem='30MB';
alter system set maintenance_work_mem='256MB';
alter system set temp_buffers='256MB';

测试结果

标准化测试

命令如下

pgbench -c 80 -j 4 -t 2000 -r  test

一共测试了10次，平均tps为480.下图为最接近该tps的截图。

查询测试

命令如下

pgbench -c 80 -j 4 -t 2000 -r  -S test

只测了三次，结果如下图

按PGTune优化参数

参数设置

打开PGTune，输入参数，点击Generate 生成优化参数，如下图，膝盖数据库并重启使之生效，cpu参数查询命令，查询总线程数

查询线程总和
# cat /proc/cpuinfo |grep 'processor'|sort -u|wc -l

# DB Version: 14
# OS Type: linux
# DB Type: web
# Total Memory (RAM): 4 GB
# CPUs num: 4
# Connections num: 100
# Data Storage: hdd

ALTER SYSTEM SET
 max_connections = '100';
ALTER SYSTEM SET
 shared_buffers = '1GB';
ALTER SYSTEM SET
 effective_cache_size = '3GB';
ALTER SYSTEM SET
 maintenance_work_mem = '256MB';
ALTER SYSTEM SET
 checkpoint_completion_target = '0.9';
ALTER SYSTEM SET
 wal_buffers = '16MB';
ALTER SYSTEM SET
 default_statistics_target = '100';
ALTER SYSTEM SET
 random_page_cost = '4';
ALTER SYSTEM SET
 effective_io_concurrency = '2';
ALTER SYSTEM SET
 work_mem = '5242kB';
ALTER SYSTEM SET
 min_wal_size = '1GB';
ALTER SYSTEM SET
 max_wal_size = '4GB';
ALTER SYSTEM SET
 max_worker_processes = '4';
ALTER SYSTEM SET
 max_parallel_workers_per_gather = '2';
ALTER SYSTEM SET
 max_parallel_workers = '4';
ALTER SYSTEM SET
 max_parallel_maintenance_workers = '2';

测试结果

标准化测试

命令如下，从结果看出tps没有明显提升，一共测了8次，tps平均在500，相比原来的优化，提升的也不是太明显，约等于没有

pgbench -c 80 -j 4 -t 2000 -r   test

查询测试

命令如下，从结果看出tps确有提升

pgbench -c 80 -j 4 -t 2000 -r  -S test

总结

在给客户装机前可以按照PGTuen给的建议来配置PG，在后续的使用中再根据业务情况和及数据库实际数据情况作分析再进行调优

参考

Postgres数据库参数查询
PGTune
PG官网
上一篇