使用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或更高时,为什么性能如此之低?我唯一做的就是增加记忆力.
show debug_assertions;
而且它已经开启,你的构建有这个问题,你所看到的结果是预期的.您需要一个未启用断言调试的新安装,以使其消失.
否则,如果您没有多次执行此操作,我不会确定这里的原因是shared_buffers更改.作为一个示例,如果autovacuum恰好在大型数据库运行时运行,则会降低测试结果的速度.测试开始时的检查点也将开始.关闭autovacuum以从测试中消除它,并打开log_checkpoints以查看它是否在干扰.
第三种可能性,我几乎可以肯定你在某种程度上受到了影响,因为在磁盘上移动的东西会导致结果减少50%.磁盘的早期部分速度是后者的两倍,并且当您重复运行pgbench时,数据会随着时间的推移移动到较慢的部分.我最终重建整个文件系统以获得可重复的结果,只有这样才能确保你从驱动器上的同一点开始.这不会影响较小尺度的结果,因为它们都适合RAM.
当我在触摸配置参数后看到性能变化时,我总是再次尝试原始配置以确保原因.我经常会惊讶地发现,每次运行测试时测试速度都会变慢,这个磁盘位置速度差异是该问题的一个来源.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。