PostgreSQL常用配置参数【一表说明】-Toy模板网

这篇具有很好参考价值的文章主要介绍了PostgreSQL常用配置参数【一表说明】。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

参数	更改需要重新启动	说明	类型	default	范围	设置建议
Work_mem		最小64kB.可以限制用于排序内存的大小,该值在客户端连接之后可以增加,该类型分配使用的是"非共享内存"	整型	4MB	64~2147483647 单位KB通常设置为64MB。	如果尝试寻找一个适合所有场景的答案，通常设置为64MB。内存中的排序往往是比需要借助磁盘临时文件的排序要快很多的。将这个参数设置成一个比较大的值，会导致你的部署环境中内存成为瓶颈，因为每个排序操作都需要这么多的内存。因此，当你有很多用户需要执行排序操作，那么系统将会为所有的用户分配work_mem×total_sort_operations大小的内存。全局地将这个值设置得很高，会导致很高的内存使用率。因此，将来推荐在会话级别来设置这个参数
Shared_buffers	Y	共享内存缓冲区由参数shared_buffers 设置，它决定了 PostgreSQL 能够使用的专用缓存大小。增加 shared_buffers 的值是提高性能最有效的设置之一。对于专用的数据库服务器，shared_buffers 大概可以设置为系统内存的 25%。由于 PostgreSQL 还依赖于操作系统的缓存，大于内存 40% 的 shared_buffers 并不会带来性能的提示，反而可能会下降。	整型	1000	16~1073741823 块每个缓冲块为8KB内存25%è内存 40%	确保在所有机器和操作系统上的兼容性，PostgreSQL 默认将该值设置得很小，通常是 128 MB。因此，增加 shared_buffers 的值是提高性能最有效的设置之一。增加shared_buffers 的值通常也需要相应地增加 max_wal_size 的值，以便延长检查点的时间间隔。专用的数据库服务器，shared_buffers 大概可以设置为系统内存的 25%大于内存 40% 的 shared_buffers 并不会带来性能的提示
Maintenance_work_mem		指定了日常维护操作允许占用的最大内存，例如 VACUUM、CREATE INDEX 以及 ALTER TABLE ADD FOREIGN KEY 等操作	整型	64MB	1024~ 2147483647 KB	由于一个数据库会话同时只能执行一个维护操作，一般不会存在并发的维护操作；所以将该参数设置的比 work_mem 大很多也不会有问题，更大的维护内存还能够提高数据库清理和数据导入的性能。唯一需要注意的是，如果启动了 autovacuum，可能会占用 autovacuum_max_workers（默认为 3）倍 work_mem 设置的内存。我们也可以为此设置单独的autovacuum_work_mem 参数。
effective_cache_size		设置规划器对一个单一查询可用的有效磁盘缓冲区大小。为 PostgreSQL 提供了一个可供操作系统和数据库使用的缓存估值。默认值为 4 GB，保守估可以设置为是系统可用内存的 1/2。通常对于专用数据库服务器可以设置为系统总内存的 75％，可以根据特定的服务器工作负载进行调整。如果 effective_cache_size 设置过低，查询计划器可能会忽略某些索引，即使通过索引可以明显增加查询的性能。	整型	4GB	保守系统可用内存的 1/2è专用数据库服务器可以设置为系统总内存的3/4 最低限度:1 (8kB)最大:2147483647 (17179869176kB)单元:8kB	如果指定值时没有单位，则以块为单位，即BLCKSZ字节，通常为8kB。默认值是 4GB。(如果BLCKSZ不是8kB，默认值会按比例缩放它。) 保守系统可用内存的 1/2è专用数据库服务器可以设置为系统总内存的 75％它告诉PostgreSQL查询规划器估计有多少RAM可用于缓存数据，包括在shared_buffers和文件系统缓存中。这种设置可以帮助规划器做出合理的成本估算;它实际上并不分配内存。如果effective_cache_size 设置过低，查询计划器可能会忽略某些索引，即使通过索引可以明显增加查询的性能。
max_connections	Y	max_connections 决定了客户端的最大并发连接数，默认值通常为 100。如果出现连接数过多，无法连接数据库的错误时，可能需要考虑增加最大连接数。不过，修改该参数还需要考虑对其他参数的影响（尤其是 work_mem）；因为它们是基于每个连接设置的值，增加连接数也会导致这些内存使用量的增加。对于主从复制中的从节点，必须将该参数的值设置为大于等于主节点上的值；否则，从节点将无法执行查询操作。	整型	100	100₃₀₀500~700 可取范围：1-262143	如果出现连接数过多，无法连接数据库的错误时，可能需要考虑增加最大连接数。修改该参数还需要考虑对其他参数的影响（尤其是 work_mem）。因为它们是基于每个连接设置的值，增加连接数也会导致这些内存使用量的增加。最佳性能是当存在300-500个并发连接时。在700之后，性能急剧下降(就每秒事务数和延迟而言)。超过1000个连接的任何连接均表现不佳，并且延迟不断增加。在Google Cloud和Heroku这些云平台上，也将max_connections限制在了500左右。max_connctions不易过大，要考虑到local memory，尤其是work_mem，推荐300 ~ 700区间的值，再高性能就损耗明显了，对于高吞吐量的数据库，可以考虑使用应用层面内置的连接池，也可以使用应用和数据库中间一层的连接池如pgbouncer。
geqo		允许或禁止遗传查询优化。默认是启用。在生产环境中通常最好不要关闭它。geqo_threshold变量提供了对 GEQO 更细粒度的空值。	布尔型	on	on/off	在生产环境中通常最好不要关闭它。
random_page_cost		减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。对磁盘存储的随机访问通常比顺序访问要贵不止四倍。但是，由于对磁盘的大部分随机访问（例如被索引的读取）都被假定在高速缓冲中进行，所以使用了一个较低的默认值（4.0）。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍，而期望 90% 的随机读取会被缓存。如果你相信 90% 的缓冲率对你的负载是一个不正确的假设，你可以增加 random_page_cost 来更好的反映随机存储读取的真正代价。相应地，如果你的数据可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的。为具有很低的随机读取代价的存储（例如固态驱动器）采用较低的 random_page_cost 值可能更好。虽然允许你将random_page_cost设置的比 seq_page_cost小，但是物理上的实际情况并不受此影响。然而当所有数据库都位于内存中时，两者设置为相等是非常合理的，因为在此情况下，乱序抓取并不比顺序抓取开销更大。同样，在缓冲率很高的数据库上，你应当相对于 CPU 开销同时降低这两个值，因为获取内存中的页比通常情况下的开销小许多。	浮点型	4.0	0è1.79769e+308	设置数据库存储的寻道扫描时间的比例。不应该被改变，除非你使用特殊的存储(ssd，高端san等)，其中查找/扫描比率实际上是不同的。如果需要数据库更喜欢索引，那么就调优effecve_cache_size和一些cpu_*开销。减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。若90% 的缓冲率对你的负载是一个不正确的假设，可以增加random_page_cost 来更好的反映随机存储读取的真正代价。如果数据可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的。
Checkpoint_timeout		影响系统何时启动一个检查点操作。如果现在的时间减去上次检查点操作结束的时间超过了checkpoint_timeout的值，系统就会自动启动一个检查点操作。增大这个参数会增加数据库崩溃以后恢复操作需要的时间。当促发检查点操作时，数据库会进行前面说的（刷脏数据）行为。这是一个代价十分大的操作，因为它会引发大量的IO。这个过程涉及到了大量读写磁盘的操作。若用户的系统速度赶不上写数据的速度,则可以适当提高该值。	浮点型	5min	5₃₀60min~24h可取范围在 30秒到 1 天之间。	增大这个参数会增加数据库崩溃以后恢复操作需要的时间。若用户的系统速度赶不上写数据的速度,则可以适当提高该值。一般来说，默认值（5分钟）相当低,普遍采用30分钟到1小时之间,PostgreSQL 9.6甚至增加了最多1天,建议使用30分钟。如果您执行非常大的ETL批处理，您可能希望将此设置增加到批处理运行的最大长度。
temp_buffers		设置每个数据库会话使用的临时缓冲区的最大数目。此本地缓冲区只用于访问临时表。临时缓冲区是在某个连接会话的服务进程中分配的，属于本地内存。临时缓冲区的大小也是按数据块大小分配的，默认是 1000，对于 8K 的数据块大小为 8MB。	整型	8MB	100~1073741823 单位8KB	此本地缓冲区只用于访问临时表临时缓冲区是在某个连接会话的服务进程中分配的，属于本地内存。目前仅用于在内存中保存临时表。如果您的应用程序需要大量使用临时表(许多专有报表引擎都需要)，那么可能需要大幅增加临时表的使用。但是，要小心，因为这是每个会话分配的非共享RAM。否则，默认即可。
cpu_tuple_cost		设置规划器对一次查询中处理每一行的代价估计。默认值是 0.01	浮点型	0.01	0è 1.79769e+308
deadlock_timeout		在检查是否存在 deadlock 条件之前，等待一个 lock 的时间长度。死锁检查是相对昂贵的，因此，pg 不会在每次等待 lock 时都运行死锁检测。PostgreSQL 会乐观的认为死锁在生产应用程序中并不常见，只需要等待一段时间后再检查死锁。这是您在实践中想要设置的最小值，在负载很重的 pg 中，可能需要提高本参数值。在理想情况下，本参数值应该超过典型的 transaction 时间，以提高在 PostgreSQL 决定检查死锁之前将释放锁的几率。仅仅 superuser 可以修改本参数值。在log_lock_waits 参数启用的情况下，deadlock_timeout参数值也决定了一个有关 lock wait 的 log message 被写入运行日志之前的等待时间。如果你正在尝试调查锁定延迟 (lockingdelays)，你可能希望设置比正常deadlock_timeout 参数值更短的时间。	整型	1000ms	应该超过典型的 transaction 时间， 1è2147483647ms	负载很重的 pg 中，可能需要提高本参数值。在理想情况下，本参数值应该超过典型的 transaction 时间，以提高在 PostgreSQL 决定检查死锁之前将释放锁的几率。如果你正在尝试调查锁定延迟 (locking delays)，你可能希望设置比正常 deadlock_timeout 参数值更短的时间。
cpu_operator_cost		设置规划器对于一次查询中处理每个操作符或函数的代价估计。默认值是 0.0025。	浮点型	0.0025	0è 1.79769e+308	稍微减少这个值，让数据库更喜欢索引。
stats_start_collector		要想让统计收集器运行起来，参数 stats_start_collector 必须设置为 true ，如果你对统计信息不感兴趣并且想把所有额外的开销都去除，那么可以把它设置为 false	布尔型	TRUE	true/false	如果对统计信息不感兴趣并且想把所有额外的开销都去除，那么可以把它设置为 false
cpu_index_tuple_cost		设置规划器对一次索引扫描中处理每一个索引项的代价估计。默认值是 0.005。	浮点型	0.005	0è 1.79769e+308	稍微减少这个值，让数据库更喜欢索引。
Fsync		将数据刷新到磁盘以确保崩溃安全(关闭此功能可能导致不可恢复的数据损坏) 。强制把数据同步更新到磁盘是因为系统的IO压力很大，为了更好的测试其他配置的影响，把改参数改为off	布尔型	on	on/off	为了更好的测试其他配置的影响，把改参数改为off 将数据刷新到磁盘以确保崩溃安全(关闭此功能可能导致不可恢复的数据损坏) 。