PostgreSQL中的选项shared_buffers

概述我在Centos 5上有一个4GB RAM和PostgreSQL 9.0.3的服务器.我使用pgbench和pgbench-tools来测量性能,使用两个pgbench-tools查询：select和tpc-b. 使用postgresql.conf的默认设置并使用select查询,我得到以下结果： Scale: 1, 10, 100, 1000. Transactions per second: 我在Centos 5上有一个4GB RAM和Postgresql 9.0.3的服务器.我使用pgbench和pgbench-tools来测量性能,使用两个pgbench-tools查询：select和tpc-b.

使用postgresql.conf的默认设置并使用select查询,我得到以下结果：

Scale: 1,10,100,1000.
Transactions per second: 10000,8800,7500,100.

(表的记录数是刻度* 100000)

我将选项shared_buffer增加到256MB(以前是32 MB),8000,3200,30

与第一次测试相比,当第二次测试中的比例为100或更高时,为什么性能如此之低？我唯一做的就是增加记忆力.

增加shared_buffers时,唯一一致使pgbench变慢的事情是一个名为assertion checking的调试选项.如果你在psql中这样做：

show deBUG_assertions;

而且它已经开启,你的构建有这个问题,你所看到的结果是预期的.您需要一个未启用断言调试的新安装,以使其消失.

否则,如果您没有多次执行此 *** 作,我不会确定这里的原因是shared_buffers更改.作为一个示例,如果autovacuum恰好在大型数据库运行时运行,则会降低测试结果的速度.测试开始时的检查点也将开始.关闭autovacuum以从测试中消除它,并打开log_checkpoints以查看它是否在干扰.

第三种可能性,我几乎可以肯定你在某种程度上受到了影响,因为在磁盘上移动的东西会导致结果减少50％.磁盘的早期部分速度是后者的两倍,并且当您重复运行pgbench时,数据会随着时间的推移移动到较慢的部分.我最终重建整个文件系统以获得可重复的结果,只有这样才能确保你从驱动器上的同一点开始.这不会影响较小尺度的结果,因为它们都适合RAM.

当我在触摸配置参数后看到性能变化时,我总是再次尝试原始配置以确保原因.我经常会惊讶地发现,每次运行测试时测试速度都会变慢,这个磁盘位置速度差异是该问题的一个来源.

总结

以上是内存溢出为你收集整理的PostgreSQL中的选项shared_buffers全部内容，希望文章能够帮你解决PostgreSQL中的选项shared_buffers所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。