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,目前發現的相容性問題比較好解決,只有查詢欄的查詢時間上需要做一定的修改,其他地方都可以保持相容。