PostgreSQL配置优化 淡淡的烟草味﹌ 2022-11-24 12:55 130阅读 0赞 * PostgreSQL配置优化 * * 硬件和系统配置 * 测试工具 * 配置文件 * 主要选项 * 测试数据 * 总结 ### 硬件和系统配置 ### <table> <tbody> <tr> <td>操作系统</td> <td>Ubuntu13.04</td> </tr> <tr> <td>系统位数</td> <td>64</td> </tr> <tr> <td>CPU</td> <td>Intel(R) Core(TM)2 Duo CPU</td> </tr> <tr> <td>内存</td> <td>4G</td> </tr> <tr> <td>硬盘</td> <td>Seagate ST2000DM001-1CH164</td> </tr> <tr> <td>测试工具</td> <td>PostgreSQL-9.1.11</td> </tr> </tbody> </table> ### 测试工具 ### <table> <tbody> <tr> <td>工具名称</td> <td>pgbench</td> </tr> <tr> <td>数据量</td> <td>200W(整个数据库大小约为300M)</td> </tr> <tr> <td>模拟客户端数</td> <td>4</td> </tr> <tr> <td>线程数</td> <td>4</td> </tr> <tr> <td>测试时间</td> <td>60秒</td> </tr> </tbody> </table> * 准备命令:pgbench -i -s 20 pgbenchdb * 测试命令:pgbench -r -j4 -c4 -T60 testdb ### 配置文件 ### 默认的配置配置文件是保存在/etc/postgresql/VERSION/main目录下的postgresql.conf文件 * 如果想查看参数修改是否生效,可以用psql连接到数据库后,用<show 选项名> 来查看。 * 如果要修改shared\_buffers, 在ubuntu下可能需要执行命令<sysctl -w>Managing Kernel Resources ### 主要选项 ### <table> <tbody> <tr> <td>选项</td> <td>默认值</td> <td>说明</td> <td>是否优化</td> <td>原因</td> </tr> <tr> <td>max_connections</td> <td>100</td> <td>允许客户端连接的最大数目</td> <td>否</td> <td>因为在测试的过程中,100个连接已经足够</td> </tr> <tr> <td>fsync</td> <td>on</td> <td>强制把数据同步更新到磁盘</td> <td>是</td> <td>因为系统的IO压力很大,为了更好的测试其他配置的影响,把改参数改为off</td> </tr> <tr> <td>shared_buffers</td> <td>24MB</td> <td>决定有多少内存可以被PostgreSQL用于缓存数据(推荐内存的1/4)</td> <td>是</td> <td>在IO压力很大的情况下,提高该值可以减少IO</td> </tr> <tr> <td>work_mem</td> <td>1MB</td> <td>使内部排序和一些复杂的查询都在这个buffer中完成</td> <td>是</td> <td>有助提高排序等操作的速度,并且减低IO</td> </tr> <tr> <td>effective_cache_size</td> <td>128MB</td> <td>优化器假设一个查询可以用的最大内存,和shared_buffers无关(推荐内存的1/2)</td> <td>是</td> <td>设置稍大,优化器更倾向使用索引扫描而不是顺序扫描</td> </tr> <tr> <td>maintenance_work_mem</td> <td>16MB</td> <td>这里定义的内存只是被VACUUM等耗费资源较多的命令调用时使用</td> <td>是</td> <td>把该值调大,能加快命令的执行</td> </tr> <tr> <td>wal_buffer</td> <td>768kB</td> <td>日志缓存区的大小</td> <td>是</td> <td>可以降低IO,如果遇上比较多的并发短事务,应该和commit_delay一起用</td> </tr> <tr> <td>checkpoint_segments</td> <td>3</td> <td>设置wal log的最大数量数(一个log的大小为16M)</td> <td>是</td> <td>默认的48M的缓存是一个严重的瓶颈,基本上都要设置为10以上</td> </tr> <tr> <td>checkpoint_completion_target</td> <td>0.5</td> <td>表示checkpoint的完成时间要在两个checkpoint间隔时间的N%内完成</td> <td>是</td> <td>能降低平均写入的开销</td> </tr> <tr> <td>commit_delay</td> <td>0</td> <td>事务提交后,日志写到wal log上到wal_buffer写入到磁盘的时间间隔。需要配合commit_sibling</td> <td>是</td> <td>能够一次写入多个事务,减少IO,提高性能</td> </tr> <tr> <td>commit_siblings</td> <td>5</td> <td>设置触发commit_delay的并发事务数,根据并发事务多少来配置</td> <td>是</td> <td>减少IO,提高性能</td> </tr> </tbody> </table> ### 测试数据 ### * 测试的数据是运行3次,取平均值。 * 关闭fsync是为了更好的体现出其他参数对PostgreSQL的影响。 <table> <tbody> <tr> <td>参数</td> <td>修改值</td> <td>事务总数</td> <td>tps(包括建立连接)</td> <td>tps(不包括建立连接)</td> </tr> <tr> <td>默认设置</td> <td> </td> <td>8464</td> <td>140.999792</td> <td>141.016182</td> </tr> <tr> <td>fsync</td> <td>off</td> <td>92571</td> <td>1479.969755</td> <td>1480.163355</td> </tr> <tr> <td>shared_buffers</td> <td>1GB</td> <td>100055</td> <td>1635.759275</td> <td>1635.977823</td> </tr> <tr> <td>work_mem</td> <td>10MB</td> <td>101209</td> <td>1665.804812</td> <td>1666.04082</td> </tr> <tr> <td>effective_cache_size</td> <td>2GB</td> <td>98209</td> <td>1636.733152</td> <td>1636.970271</td> </tr> <tr> <td>maintenance_work_mem</td> <td>512MB</td> <td>92930</td> <td>1548.029233</td> <td>1548.223108</td> </tr> <tr> <td>checkpoint_segments</td> <td>32</td> <td>195982</td> <td>3265.995</td> <td>3266.471064</td> </tr> <tr> <td>checkpoint_completion_target</td> <td>0.9</td> <td>194390</td> <td>3239.406493</td> <td>3239.842596</td> </tr> <tr> <td>wal_buffer</td> <td>8MB</td> <td>198639</td> <td>3310.241458</td> <td>3310.724067</td> </tr> <tr> <td>恢复fsync</td> <td>off</td> <td>11157</td> <td>185.883542</td> <td>185.909849</td> </tr> <tr> <td>commit_delay && commit_siblings</td> <td>10 && 4</td> <td>11229</td> <td>187.103538</td> <td>187.131747</td> </tr> </tbody> </table> ### 总结 ### <table> <tbody> <tr> <td> </td> <td>事务总数</td> <td>tps(包括建立连接)</td> <td>tps(不包括建立连接)</td> </tr> <tr> <td>优化前</td> <td>8464</td> <td>140.999792</td> <td>141.016182</td> </tr> <tr> <td>优化后(fsync=on)</td> <td>11229</td> <td>187.103538</td> <td>187.131747</td> </tr> <tr> <td>优化后(fsync=off)</td> <td>198639</td> <td>3310.241458</td> <td>3310.724067</td> </tr> </tbody> </table> 在fsync打开的情况下,优化后性能能够提升30%左右。因为有部分优化选项在默认的SQL测试语句中没有体现出它的优势,如果到实际测试中,提升应该不止30%。 测试的过程中,主要的瓶颈就在系统的IO,如果需要减少IO的负荷,最直接的方法就是把fsync关闭,但是这样就会在掉电的情况下,可能会丢失部分数据。 作者:roddick621 发表于2013-12-26 9:21:16 [原文链接][Link 1] 阅读:0 评论:0 [查看评论][Link 2] [Link 1]: http://blog.csdn.net/kyle__shaw/article/details/17576259 [Link 2]: http://blog.csdn.net/kyle__shaw/article/details/17576259#comments
还没有评论,来说两句吧...