技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> PostgreSQL参数优化对比性能测试

PostgreSQL参数优化对比性能测试

浏览:1657次  出处信息

1、 测试目的

通过运行标准测试程序TPC-B和TPC-C,确定在不同参数和不同版本下(8.2.14 VS 8.4.2)的性能的不同,为eCop CM上PostgreSQL数据库的参数配置和版本选择提供参考。

测试平台为:

硬件配置:CPU E4600 双核2.4G 2G RAM 160G SATA * 2

操作系统:Ubuntu 9.10 Server

文件系统:Ext3

数据库:PostgreSQL 8.2.14和8.4.2

采用源码编译方式安装,GCC版本4.4.1

2、 测试和数据

2.1 TPC-B(Pgbench)

2.1.1 测试方法

通过执行PostgreSQL源码中自带的Pgbench来执行TPC-B测试。关于Pgbench的更多信息可以参见http://www.pgsqldb.org/mwiki/index.php?title=Pgbench

测试参数:./pgbench -i -s 20 pgbench 将负载因子设定为20

初始化数据库表容量:

able # of rows

————————-

branches 20

tellers 200

accounts 2000000

history 0

数据库物理大小:数据库总大小288MB,其中表accounts 248MB

每次事物执行的SQL语句:

1. BEGIN;

2. UPDATE accounts SET abalance = abalance + :delta WHERE aid = :aid;

3. SELECT abalance FROM accounts WHERE aid = :aid;

4. UPDATE tellers SET tbalance = tbalance + :delta WHERE tid = :tid;

5. UPDATE branches SET bbalance = bbalance + :delta WHERE bid = :bid;

6. INSERT INTO history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

7. END;

测试方法:./pgbench -t 2000 -c 20 -U postgres pgbench 模拟20个并发用户,每个用户执行2000次事务。每种配置参数执行三次,记录TPS值。

2.1.2 测试结果(8.2.14)

PostgreSQL 8.2.14的Pgbench测试结果(单位TPS/每秒钟事务数量),重点关注的参数:shared_buffers、effective_cache_size、wal_buffers、checkpoint_segments。

序号

参数配置

第一次

第二次

第三次

平均值

1

默认参数

404

408

415

409

2

调整WAL日志参数

wal_buffers = 1024kB (默认64kb)

checkpoint_segments = 32 (默认3)

852

895

813

853

3

将WAL日志在放在第二块硬盘

1673

1673

1657

1667

4

调整内存参数

shared_buffers = 256MB(默认32MB)

work_mem = 10MB(默认1M)

effective_cache_size = 512MB(默认128M)

2351

2375

2390

2372

5

调整内存参数

shared_buffers = 512MB

work_mem = 10MB

effective_cache_size = 1024MB

2264

2354

2351

2323

6

关闭WAL日志

2761

2806

2810

2792

2.1.3 测试结果(8.4.2)

PostgreSQL 8.4.2的Pgbench测试结果(单位TPS/每秒钟事务数量),重点关注的参数:shared_buffers、effective_cache_size、wal_buffers、checkpoint_segments。

序号

参数配置

第一次

第二次

第三次

平均值

1

默认参数

466

470

450

462

2

调整WAL日志参数

wal_buffers = 1024kB (默认64kb)

checkpoint_segments = 32 (默认3)

checkpoint_completion_target=0.9(默认0.5)

939

940

1064

981

3*

将WAL日志在放在第二块硬盘

1364

1945

1378

1562

4

调整内存参数

shared_buffers = 256MB(默认32MB)

work_mem = 10MB(默认1M)

effective_cache_size = 512MB(默认128M)

2316

2341

2341

2332

5

调整内存参数

shared_buffers = 512MB

work_mem = 10MB

effective_cache_size = 1024MB

2319

2361

2370

2350

6

关闭WAL日志

2800

2813

2814

2809

注*执行测试3的时候,数据变化非常大,执行多次也如此,最小值1214,最大值2010,很不稳定

2.1.4 测试性能数据对比

2.1.5 测试数据分析

1) 默认参数配置情况下,性能都很差,不管是8.2.14还是8.4.2,见测试1数据

2) 增大WAL日志参数中的checkpoint_segments的值可以显著提升性能,提升1倍以上。增大checkpoint_segments的实际效果是数据库写入日志更快,见测试2数据

3) 将WAL日志在放在第二块硬盘以后,降低了I/0的竞争,性能提升显著,提升幅度在1倍左右,见测试3数据

4) 增加内存参数,使得在内存中基本可以放入整个数据库表的内容,性能提升明显,超过50%,见测试4数据

5) 在内存的可以装入整个数据库表的情况下,再增大内存参数,对性能提升没有影响,见测试5数据

6) 关闭预写式日志的情况下,可以提升20%左右的性能,见测试6数据

7) 8.4.2的性能相对8.2.14有性能提升,最多15%

2.2 TPC-C(BenchMark Factory)

2.2.1 测试方法

采用BenchMark Factory用ODBC连接数据库,初始化负载因子2,初始化表容量

测试分别模拟5个、10个、15个和20个并发连接,进行测试。

参数配置:

shared_buffers = 512MB

work_mem = 10MB

effective_cache_size = 1024MB

fsync = on/off 打开/关闭WAL

2.2.2 测试结果(8.2.14)

PostgreSQL 8.2.14的TPC-C测试结果(关闭WAL)

并发线程数

TPS(每秒钟事务量)

平均响应时间(ms)

5

79.24

63

10

110.92

90

15

116.43

128

20

119.40

167

2.2.3 测试结果(8.4.2)

PostgreSQL 8.4.2的TPC-C测试结果(关闭WAL)

并发线程数

TPS(每秒钟事务量)

平均响应时间(ms)

5

70.65

70

10

107.42

93

15

144.66

103

20

150.35

132

PostgreSQL 8.4.2的TPC-C测试结果(开启WAL)

并发线程数

TPS(每秒钟事务量)

平均响应时间(ms)

5

62.98

79

10

116.46

85

15

125.31

119

20

125.74

158

2.2.4 测试性能数据对比

2.2.5 测试数据分析

1) 在低负载的情况下,并发线程数为5和和10个的时候,8.2.14和8.4.2性能差别不打,甚至可能表现得更好,

2) 一旦负载增大,8.2.14的性能同8.4.2相比就体现出来比较大的差距,(并发线程数为20的时候119.40 VS 150.35),8.4.2的性能高出25.9%

3、 测试总结

数据库性能的关键影响点是磁盘I/0性能

eCop默认采用的是8.2.x的版本,目前的数据库表容量在几十MB到500MB以内,根据不同机型和用户量,在CM1-4的机型可以配置如下参数:

shared_buffers = 256MB

work_mem = 10MB

effective_cache_size = 512MB

wal_buffers = 1024kB

checkpoint_segments = 32

CM5的机型可以配置为:

shared_buffers = 512MB

work_mem = 10MB

effective_cache_size = 1024MB

wal_buffers = 1024kB

checkpoint_segments = 32

把WAL日志放到独立的硬盘上。

在合适的时候可以考虑将数据库升级到8.4.2,目前发现的兼容性问题比较好解决,只有查询栏的查询时间上需要做一定的修改,其他地方都可以保持兼容。

    【编者加注

    本篇PostgreSQL性能测试文章,来源于PostgreSQL QQ群共享,非本站原创!

建议继续学习:

  1. 也谈PostgreSQL的同步配置(Slony)    (阅读:4613)
  2. 多版本并发控制:PostgreSQL vs InnoDB    (阅读:3653)
  3. Ubuntu下Postgresql-8.4安装及配置    (阅读:3342)
  4. PostgreSQL与MySQL的区别    (阅读:2958)
  5. Ubuntu下PostgreSQL数据库集群(PL/Proxy)配置方法    (阅读:2955)
  6. PostgreSQL 9.1的新特性    (阅读:2526)
  7. PostgreSQL    (阅读:2475)
  8. PostgreSQL从菜鸟到专家 PostgreSQL介绍    (阅读:2465)
  9. 在Linux上编译安装PostgreSQL8.3.X    (阅读:2289)
  10. PostgreSQL安装    (阅读:2260)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1