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测试方法
测试参数:./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,目前发现的兼容性问题比较好解决,只有查询栏的查询时间上需要做一定的修改,其他地方都可以保持兼容。 |