加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

postgresql 参数配置优化详介绍

发布时间:2020-12-13 17:50:45 所属栏目:百科 来源:网络整理
导读:一、Linux内核参数设置:/etc/sysctl.conf http://www.pgsqldb.org/pgsqldoc-8.1c/kernel-resources.html#SYSVIPC 缺省设置只适合小安装(缺省最大共享内存是 32 MB)。 不过,其它的缺省值都相当大,通常不需要改变。 最大的共享内存段设置可以用sysctl 接

一、Linux内核参数设置:/etc/sysctl.conf
http://www.pgsqldb.org/pgsqldoc-8.1c/kernel-resources.html#SYSVIPC
缺省设置只适合小安装(缺省最大共享内存是 32 MB)。
不过,其它的缺省值都相当大,通常不需要改变。
最大的共享内存段设置可以用sysctl 接口设置。
比如,要允许 128MB,并且最大的总共享内存数为 2097152 页(缺省):
你可以把这些设置放到 /etc/sysctl.conf 里,在重启后保持有效。
$ sysctl -w kernel.shmmax=134217728
$ sysctl -w kernel.shmall=2097152 #ceil(SHMMAX/PAGE_SIZE)
老版本里可能没有 sysctl 程序,但是同样的改变可以通过操作 /proc 文件系统来做:
$ echo 134217728 >/proc/sys/kernel/shmmax
$ echo 2097152 >/proc/sys/kernel/shmall

二、影响 PostgreSQL 的内存使用的配置参数
名称 近似倍率(每次增加的字节数)
max_connections 400 + 220 * max_locks_per_transaction
max_prepared_transactions 600 + 220 * max_locks_per_transaction
shared_buffers 8300 (假设 8K 的BLCKSZ)
wal_buffers 8200 (假设 8K 的BLCKSZ)
max_fsm_relations 70
max_fsm_pages 6

三、Usage Approximate shared memory bytes required (as of 8.3)
Connections (1800 + 270 * max_locks_per_transaction) * max_connections
Autovacuum workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
Prepared transactions (770 + 270 * max_locks_per_transaction) * max_prepared_transactions
Shared disk buffers (block_size + 208) * shared_buffers
WAL buffers (wal_block_size + 8) * wal_buffers
Fixed space requirements 770 kB

四、参数调整:
参数具体含义参考:http://www.pgsqldb.org/pgsqldoc-cvs/runtime-config-resource.html
shared_buffers memory的 1/4 - 1/2
temp_buffers #根据每次访问表读取的平均量而设置
max_prepared_transactions #默认,暂不调整
work_mem RAM的 2% - 4% #可以根据explain analyze分析语句查看及数据库查询形式.
maintenance_work_mem > work_mem + ↑M # 目前我们服务器上:work_mem+50-100暂时足够,后续根据数据库
max_stack_depth < ulimit -s
effective_cache_size memory的 1/2
max_connections # max_connections * work_mem < memory
max_prepared_transactions # 0或max_connections 一样大小
checkpoint_segments RAM的 10% 比较合理
wal_buffers #大到能保存下一次事务生成的 WAL 数据即可,但得在服务器启动的时候设置
max_fsm_pages # 16 * max_fsm_relations 只能在服务器启动的时候设置
max_fsm_relations # 最大数目的关系(表和索引)* 50
# - Planner Method Configuration -
enable_bitmapscan = on
enable_hashagg = on
enable_hashjoin = on
enable_indexscan = on
enable_material = on
enable_mergejoin = on
enable_nestloop = on
enable_seqscan = on
enable_sort = on
enable_tidscan = on
注意:考虑 max_connections * work_mem + shared_buffers + temp_buffers + maintenance_work_mem + 操作系统所需内存 < RAM

五、详细参数说明
--服务器配置
Mem: 1035140k total,1014492k used,20648k free,146700k buffers
Swap: 1052248k total,320k used,1051928k free,718972k cached
--参数详细配置及详细说明
1、shared_buffers = 1/4 memory in your system #这是最重要的参数,postgresql通过shared_buffers和内核和磁盘打交道,因此应该尽量大,让更多的数据缓存在shared_buffers中
2、temp_buffers
/*设置每个数据库会话使用的临时缓冲区的最大数目,
这些都是会话的本地缓冲区,只用于访问临时表。缺省是 1000。
这个设置可以再独立的会话内部设置,但是只有在会话第一次使用临时表的时候才能增长,在该会话里随后的改变该数值的企图将没有作用。
一个会话将按照 temp_buffers 给出的限制,根据需要分配临时缓冲区。
如果在一个并不需要大量临时缓冲区的会话里设置一个大的数值,
其开销只是一个缓冲区描述符,或者说每次temp_buffers里的增加大概64字节,
不过,如果一个缓冲区实际上被使用,那么就会有额外的8192字节为之消耗(或者,概括来说是 BLCKSZ 字节)。
*/
3、effective_cache_size =1/2 of total memory
/*是PostgreSQL能够使用的最大缓存,这个数字对于独立的PostgreSQL服务器而言应该足够大,
比如4G的内存,可以设置为3.5G (437500),use 25% of RAM for cache size,and 2-4% for sort size
*/
4、work_mem
/*EnterpriseDB在执行排序操作时,会根据work_mem的大小决定是否将一个大的结果集拆分为几个小的
和work_mem查不多大小的临时文件。显然拆分的结果是降低了排序的速度。
因此增加work_mem有助于提高排序的速度。及散列表在散列连接,散列为基础的聚集,以及散列为基础的 IN 子查询处理中都要用到。
通常设置为实际RAM的2% -4%,根据需要排序结果集的大小而定,比如81920(80M)
*/
5、maintenance_work_mem
/*这里定义的内存只是在CREATE INDEX,VACUUM等时用到,
因此用到的频率不高,但是往往这些指令消耗比较多的资源,因为在一个数据库会话里,
任意时刻只有一个这样的操作可以执行,并且一个数据库安装通常不会有太多这样的工作并发执行,
把这个数值设置得比 work_mem 更大是安全的。更大的设置可以改进清理和恢复数据库转储的速度。
因此应该尽快让这些指令快速执行完毕:给maintence_work_mem大的内存,比如512M(524288)
*/
6、max_connections
/*通常max_connections的目的是防止 max_connections * work_mem 超出了实际内存大小。
比如,如果将work_mem设置为实际内存的2%大小,则在极端情况下,如果有50个查询都有排序要求,
而且都使用2%的内存,则会导致swap的产生,系统性能就会大大降低。
当然,如果有4G的内存,同时出现50个如此大的查询的几率应该是很小的。
不过,要清楚 max_connections和work_mem的关系
*/
7、max_prepared_transactions (integer) <= max_connections
/*设置可以同时处于"准备好"状态的事务的最大数目,把这个参数设置为零则关闭准备好的事务的特性,
缺省是 5,这个选项只能在服务器启动的时候设置,
如果你不使用准备好事务,这个参数也可以设置为零。
如果你使用它们,你可能会需要把 max_prepared_transactions 设置成至少和 max_connections 一样大,
以避免在准备步骤的失败,增加这个参数可能会导致 PostgreSQL 要求比缺省的操作系统配置的更多的 System V 共享内存。
*/
8、max_stack_depth (integer) <= ulimit -s
/*声明服务器的执行堆栈的最大安全深度。
内核强制的实际堆栈尺寸(就是 ulimit -s 或者局部等效物的设置),
小于一个安全的一兆字节左右的范围。需要这么一个安全的界限是因为在服务器里,
并非所有过程都检查了堆栈深度,而只是在可能递规的过程,比如表达式计算这样的过程里面进行检查。
把这个参数设置得大于实际的内核限制讲意味着一个正在跑的递归函数可能会导致一个独立服务器进程的崩溃。
缺省设置是 2048 KB (两兆),这个值相对比较小,不容易导致崩溃。
但是,这个值可能太小了,以至于无法执行复杂的函数。
*/
9、max_fsm_pages (integer) > 16 * max_fsm_relations
/*设置在共享的自由空间映射表里自由空间会跟踪的最大数目的磁盘页面数。
每个页面槽位需要消耗六个字节的共享内存。缺省是 20000。这个选项只能在服务器启动的时候设置。*/
10、max_fsm_relations (integer) ~ (表和索引)*50
/*设置自由空间将在共享地自由空间映射里跟踪的最大数目的关系(表和索引)。
每个槽位大概要使用五十字节左右。缺省是 1000。
这个选项只能在服务器启动的时候设置。
*/
11、vacuum_cost_delay (integer)
/*以毫秒计的时间长度,如果超过了开销限制,那么进程将睡眠一会儿,缺省值是 0,它关闭基于开销的清理延迟特性。
正数值打开基于开销的清理,不过要注意在许多系统上 sleep 延迟的有效分辨率是 10 毫秒;
把 vacuum_cost_delay 设置为一个不是 10 的整数倍的数值与将它设置为下一个 10 的整数倍作用相同。
*/
12、vacuum_cost_page_hit (integer) #清理一个在共享缓存里找到的缓冲区的预计开销。它代表锁住缓冲池,查找共享的散列表以及扫描页面的内容的开销。缺省值是 1。
13、vacuum_cost_page_miss (integer) #清理一个要从磁盘上读取的缓冲区的估计开销。这个行为代表锁住缓冲池,查找共享散列表,从磁盘读取需要的数据块以及扫描它的内容的开销。缺省值是 10。
14、vacuum_cost_page_dirty (integer) #如果清理修改一个原先是干净的块的预计开销,它需要一个把脏的磁盘块再次冲刷到磁盘上的额外开销。缺省值是 20。
15、vacuum_cost_limit (integer) #导致清理进程休眠的积累开销。缺省是 200。
/*注意: 有些操作会持有关键的锁,并且应该尽快结束。
在这样的操作过程中,基于开销的清理延迟不会发生作用。为了避免在这种情况下的长延时,
实际的延迟是:vacuum_cost_delay*accumulated_balance/vacuum_cost_limit与vacuum_cost_delay*4之间的最大值
*/
16、bgwriter_delay (integer)
/*声明后端写进程活跃回合之间的延迟。在每个回合里,写进程都会为一些脏的缓冲区发出写操作。
然后它就休眠 bgwriter_delay 毫秒,然后重复动作。缺省值是 200。
请注意在许多系统上,休眠延时的有效分辨率是 10 毫秒;
因此,设置 bgwriter_delay 为一个不是 10 的倍数的数值与把它设置为下一个 10 的倍数是一样的效果。
这个选项只能在服务器启动的时候。
*/
17、bgwriter_lru_percent (floating point)
/*为了减少服务器进程发出自己的写操作的可能,后端写进程尽量写那些可能很快被重复使用的缓冲区。
在每个回合里,它检查最多百分之 bgwriter_lru_percent 的快要被重复使用的缓冲区,然后写出其中的脏缓冲区。
缺省值是 1.0(这是全部共享缓冲区的百分比),这个选项只能在服务器启动的时候设置。
*/
18、bgwriter_lru_maxpages (integer) #在每个回合里,不超过这么多个缓冲区将做为扫描到的即将重复使用的缓冲区写入磁盘,缺省值是5。这个选项只能在服务器启动的时候设置。
19、bgwriter_all_percent (floating point)
/*为了减少检查点时刻需要做的工作,后端写进程还会对整个缓冲池进行循环扫描,把那些认为是脏的缓冲区写出到磁盘。
在每个回合里,它为此检查最多百分之 bgwriter_all_percent 的缓冲区进行操作。
缺省值是 0.333(这是全部共享缓冲区的百分比),使用缺省的 bgwriter_delay,
这个设置可以做到每分钟扫描一次整个共享缓冲池,同上。
*/
20、bgwriter_all_maxpages (integer) #在每个回合里,不超过这个数值的缓冲区,将作为扫描整个缓冲池的结果,写入磁盘,缺省值是 5,同上。
/*小的 bgwriter_all_percent 和 bgwriter_all_maxpages 减少后端写进程导致的额外 I/O 负荷,
但是会导致在检查点的时候的更多工作。
要降低检查点时的峰值负荷,增加这两个值。
类似的小的 bgwriter_lru_percent 和 bgwriter_lru_maxpages 减小后端写进程导致的额外的 I/O 负载,
但是会有可能是服务器进程不得不自己发出写动作,降低交互查询的交互性。
要想完全关闭后台写进程,可以把两个 percent 和/或两个 maxpages 设置为零。
*/

六、增加最大连接数到2000以上 Linux操作系统中默认的SEMMNI一般只能支持2000个左右的连接,这个值应该设为 max_connections*16,但实际上各不同的系统中有似乎有一点偏差,如: SEMMNI=128时,公式算出的最大连接数(max_connections)为2048,在RHEL5中最大只能用到2030 RHEL5中修改SEMMNI方法: vi /etc/sysctl.conf #中加入一行 kernel.sem=250 32000 32 128 当中最后一个'128'为当前的SEMMNI

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读