设为首页 收藏本站
查看: 1085|回复: 0

[经验分享] postgresql调优一:postgresql参数调优

[复制链接]

尚未签到

发表于 2016-11-20 08:06:53 | 显示全部楼层 |阅读模式
  1。pg中性能相关常调参数
参数名称参数意义优化思路
shared_buffers数据库服务器将使用的共享内存缓冲区大小,该缓冲区为所有连接共用。从磁盘读入的数据(主要包括表和索引)都缓存在这里。提高该值可以减少数据库的磁盘IO。
work_mem声明内部排序和哈希操作可使用的工作内存大小。该内存是在开始使用临时磁盘文件之前使用的内存数目。数值以kB为单位的,缺省是 1024 (1MB)。请注意对于复杂的查询,可能会同时并发运行好几个排序或者哈希操作,每个都会使用这个参数声明的这么多内存,然后才会开始求助于临时文件。同样,好几个正在运行的会话可能会同时进行排序操作。因此使用的总内存可能是 work_mem 的好几倍。ORDER BY, DISTINCT 和mergejoin都要用到排序操作,而哈希操作在哈希连接、哈希聚集和以哈希为基础的 IN 子查询处理中都会用到。该参数是会话级参数。 执行排序操作时,会根据work_mem的大小决定是否将一个大的结果集拆分为几个小的和 work_mem差不多大小的临时文件写入外存。显然拆分的结果是导致了IO,降低了排序的速度。因此增加work_mem有助于提高排序的速度。通常设置时可以逐渐调大,知道数据库在排序的操作时不会有大量的写文件操作即可。该内存每个连接一份,当并发连接较多时候,该值不宜过大。
effective_cache_size优化器假设一个查询可以使用的最大内存(包括pg使用的和操作系统缓存),和shared_buffer等内存无关,只是给优化器生成计划使用的一个假设值。 设置稍大,优化器更倾向使用索引扫描而不是顺序扫描,建议的设置为可用空闲内存的25%,这里的可用空闲内存指的是主机物理内存在运行pg时得空闲值。
maintenance_work_mem这里定义的内存只是在CREATE INDEX, VACUUM等时用到,因此用到的频率不高,但是往往这些指令消耗比较多的资源,因此应该尽快让这些指令快速执行完毕。 在数据库导入数据后,执行建索引等操作时,可以调大,比如512M。
wal_buffers日志缓冲区,日志缓冲区的大小。 两种情况下要酌情调大:1.单事务的数据修改量很大,产生的日志大于wal_buffers,为了避免多次IO,调大该值。
2.系统中并发小数据量修改的短事务较多,并且设置了commit_delay,此时wal_buffers需要容纳多个事务(commit_siblings个)的日志,调大该值避免多次IO。
commit_delay事务提交后,日志写到wal_buffer上到wal_buffer写到磁盘的时间间隔。 如果并发的非只读事务数目较多,可以适当增加该值,使日志缓冲区一次刷盘可以刷出较多的事务,减少IO次数,提高性能。需要和commit_sibling配合使用。
commit_siblings触发commit_delay等待的并发事务数,也就是系统的并发活跃事务数达到了该值事务才会等待commit_delay的时间才将日志刷盘,如果系统中并发活跃事务达不到该值,commit_delay将不起作用,防止在系统并发压力较小的情况下事务提交后空等其他事务。 应根据系统并发写的负载配置。例如统计出系统并发执行增删改操作的平均连接数,设置该值为该平均连接数。
fsync设置为on时,日志缓冲区刷盘时,需要确认已经将其写入了磁盘,设置为off时,由操作系统调度磁盘写的操作,能更好利用缓存机制,提高IO性能。 该性能的提高是伴随了数据丢失的风险,当操作系统或主机崩溃时,不保证刷出的日志是否真正写入了磁盘。应依据操作系统和主机的稳定性来配置。
autovacuum是否开启自动清理进程(如开启需要同时设置参数stats_start_collector = on,stats_row_level = on,),整理数据文件碎片,更新统计信息。 如果系统中有大量的增删改操作,建议打开自动清理进程,这样一方面可以增加数据文件的物理连续性,减少磁盘的随机IO,一方面可以随时更新数据库的统计信息,使优化器可以选择最优的查询计划得到最好的查询性能。如果系统中只有只读的事务,那么关闭自动清理进程。
autovacuum_naptime自动清理进程执行清理分析的时间间隔应该根据数据库的单位时间更新量来决定该值,一般来说单位时间的更新量越大该时间间隔应该设置越短。由于自动清理对系统的开销较大,该值应该谨慎配置(不要过小)。
bgwriter_delay后台写进程的自动执行时间后台写进程的作用是将shared_buffer里的脏页面写回到磁盘,减少checkpoint的压力,如果系统数据修改的压力一直很大,建议将该时间间隔设置小一些,以免积累的大量的脏页面到checkpoint,使checkpoint时间过长(checkpoint期间系统响应速度较慢)。
bgwriter_lru_maxpages后台写进程一次写出的脏页面数依据系统单位时间数据的增删改量来修改
bgwriter_lru_multiplier后台写进程根据最近服务进程需要的buffer数量乘上这个比率估算出下次服务进程需要的buffer数量,在使用后台写进程写回脏页面,使缓冲区能使用的干净页面达到这个估计值。 依据系统单位时间数据的增删改量来修改。
   
  2。 tpcc/压力测试时pg常调参数示例:
  max_connections = 200
  #根据数据量尽量调大shared_buffer值,把所有数据都放到内存中更好,
  #曾经在32G内存的服务器上把shared_buffert调到了26G 
  #wal_buffers根据产生的wal日志量也适当设大点
  shared_buffers=1200MB
wal_buffers = 2000kB
  #work_mem要适可而止,每个连接都要用这么大的
  work_mem = 1024kB
  #一般做做检查点的时间长于压力测试的时间,这样性能数据会更好,等压力测试完了再去做检查点吧。 DSC0000.gif
  Checkpoint_timeout=120min
 
  bgwriter_delay = 10ms  
bgwriter_lru_maxpages = 75
full_page_writes = off
log_min_messages = fatal
  #压力测试时由于高并发等锁的时间可以长一些
  deadlock_timeout = 3s
  #平时实践有些应用中把位图扫描和顺序扫描关了性能会更好 
  enable_bitmapscan = off
enable_seqscan = off
  #如果是只读的压力测试,还可以关掉没事的后台写进程等

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-302662-1-1.html 上篇帖子: Nginx, PostgreSQL And Trac : 准备工作 下篇帖子: PostgreSQL-学习-03--服务器配置
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表