我们的软件产品目前在Windows 7上以Postgres 8.3作为其数据库。在繁忙的站点上,可能有24个自动系统每分钟生成100行(x100列),3-10个人工客户端查看大约1000行的子集--所有这些都是一次检索的,增量更新大约每分钟查询pk +时间戳,并检索相关的新行。有几个辅助表,但是这个表有主要的活动。
作为建立一个有限的多主系统的第一步(帮助地理上分离的团队),我们实现了一个9.3的升级。性能并不是第一位的,所以它没有被真正的剖析。随着发布时间的到来,管理层决定暂时放弃9.3,理由是担心可能出现性能退化和缺乏测试资源。我确信性能问题是荒谬的,所以我做了一些PgBench测试。
使用9.3's pgbench,我交替连接到本地8.3和9.3安装(不同的端口号)。我在这个谷歌驱动器电子表格中捕捉到了我的结果,但总结是8.3胜9.3。9.3仅在原始插入性能方面获胜。
我们对我们的postgresql.conf文件进行了一些定制,我通常保存在8.3到9.3之间,我将列出非默认设置
max_connections = 1000
shared_buffers = 320MB
temp_buffers = 80MB
max_prepared_transactions = 50 #8.3 only, 9.3 left at 0 (not sure why)
max_fsm_pages = 204800 #8.3 only, 9.3 doesn't have setting
autovacuum_max_workers = 30
那么,这仅仅是进步的代价,还是我应该在9.3中做些什么,让它变得更出色?
发布于 2014-01-27 22:11:55
通常情况下,PostgreSQL 9.3通常比8.3更快,但很难说出出了什么问题。可能的来源: IO的问题,错误的PostgreSQL配置- max_connections = 1000可能是非常错误的值,默认work_mem通常太小,达到hw限制(9.1及更高的应该更好地使用更多的work_mem),错误的测试.
其他问题可能是pgBench中的更改。pgBench 8.3的结果不应与pgBench 9.3的结果进行准确的比较。如果要有一个很好的数字,那么必须使用pgBench 9.3来表示PosgreSQL 9.3和PostgreSQL 8.3。别忘了-测试应该最少20分钟(更好的时间)。
第二个因素--可能pgBench对你的生产并不重要。pgBench是一种综合测试,有争议的价值。它适用于初始hw和sw测试,但不利于配置精度和数据库调优。更重要的是应用程序的速度--您应该测试慢查询的速度,或者最常见的查询速度。9.3有许多新的功能--更好的监视、更舒适的工具、更好的对某些查询的优化、内置复制、在线舒适的物理备份、大量的智能真空(在大型数据集上更快)、.
default_statistics_target的增加在查询规划方面有一定的开销--对于极其快速和简单的查询,它可能是非常重要的。另一方面,较高的值降低了错误估计和错误优化的可能性--这对于通常的非平凡查询非常重要--规划的速度有点慢(可以在综合测试中看到),但在生产中的使用要健壮得多。取决于您的应用程序(如果它使用简单或不简单的查询),这个配置变量对您是否重要。
https://dba.stackexchange.com/questions/57629
复制相似问题