使用Swingbench對Oracle資料庫進行效能測試

1，swingben介紹  

目前網路上開源的Oracle壓力測試工具主要是orabm和swingbench,由於orabm不支援oracle 11g版本，因此本次測試使用了swingben進行了壓力測試。另外，swingbench還能對rac進行測試。swingbench是UK based oracle Database Solutions group開發的一個oracle壓力測試工具，好像是官方廢棄的一個項目，官方頁面http://dominicgiles.com/swingbench.html 上可以下載最新的軟體版本。

   swingbench可以運行在windows和linux平台，本次測試採用linux平台，具體過程如下
   1，使用oewizard匯入測試資料，可以根據過程提示進行資料匯入
   2，設定環境變數 java版本要求1.6以上，串連串為10.4.×.×:1521:×
   export PATH=/monitor/agent_12c/core/12.1.0.1.0/jdk/bin/:$PATH
   export DISPLAY=10.6.*.*:0.0
   cd /monitor/swingbench/swingbench/bin/
   3，使用swingbench首頁面進行壓力測試
  

2，壓力測試結果

伺服器類型是IBM X3755M3伺服器，配置是4CPU *8core,128G記憶體。測試結果顯示，峰值達到48萬TPMC，tps最大接近1萬。而此時資料庫主機CPU利用率已接近95%

top - 15:26:34 up 6 days, 21:57,  2 users, load average: 189.06, 121.48, 58.92

Tasks: 909 total,  36 running, 873 sleeping,   0 stopped,  0 zombie

Cpu(s): 79.1%us, 12.9%sy,  0.0%ni, 6.5%id,  0.2%wa,  0.1%hi, 1.2%si,  0.0%st

 

附錄：

A，swingbench的相關測試參數

1. swingbench GUI上的users：the number of users(threads) that attach to a database and the amount and tye of work they perform. users can dynamically monitor the response times and load which is displayed in a series of graphs.
這裡的users是控制同時串連到oracle的使用者數量。我們知道每個串連到oracle的使用者都將分配PGA，所以這裡應該是理解為並行度。
2. min/max think time: 每個交易之間最小/大的考慮時間。如果設定min think time，每個交易之間將間隔規定時間。
3. max trans：如果設定將限制最大的交易數量。
4. 最頂端的transaction面板：load: Indicates the "weight" of the transaction in comparison to othe transactions. A higher weight indicates that it more likely to be run.
這個面板主要是可以取消一些固定的交易類型。load這個欄主要是用於調整整個測試中某些交易的權重。例如：browse product主要是select 語句，可以增加他的權重，表示更多的人查詢。
關於oewizard中的幾個參數：
Number of Customers: 預先載入到資料庫表中的使用者數量。
Number of Orders:預先載入到資料庫表中的Orders數量。
整個OE的測試是基於9張表的，那麼用oewizard預先載入資料量不同，測試結果是不是不同呢？
對oracle自己來說，有索引的表效能在大小一定的時候是不會有什麼區別的，但是當表的行數達到一定的程度，例如幾個億行，索引效能還不如全表掃描的效能。因此對於OE所允許的範圍，我認為表資料大小對效能影響不會很大。
Swingbench是一個壓力測試工具，其結果tpmc也是表示每分鐘所能做的交易數量。如果預先載入的資料越多，而TX中所有類型的權重固定的 話，需要調整並行users的數量，以取得一個最佳的tpms值。我之前測試的結果來看，並行user固定，預先載入的資料越多，得到的tpmc結果越小， 我也有點迷糊了，後來仔細分析了之後才發覺，應該相應修改並行users的數量。
通過修改TX panel裡的各個交易類型的權重，也可以得出oracle的一些績效參數，例如查詢加重，如果tpmc的值還差不多，說明這個資料庫的查詢能力還是不錯的。

B，TPMC介紹

按照TPC的定義，流量指標描述了系統在執行Payment、Order-status、Delivery、Stock-Level這四種交易的同時，每分鐘可以處理多少個New-Order交易。所有交易的回應時間必須滿足TPC-C測試規範的要求。
流量指標值越大越好！
TPMC計算依據
為了方便計算資料庫伺服器的造型，我們約定：
" 系統同時線上使用者數為1500人（U1）；
" 平均每個使用者每分鐘發出2次業務請求（N1）；
" 系統發出的業務請求中，更新、查詢、統計各佔1/3；
" 平均每次更新業務產生3個事務（T1）；
" 平均每次查詢業務產生8個事務（T2）；
" 平均每次統計業務產生13個事務（T3）；
" 一天內忙時的處理量為平均值的5倍；
" 經驗係數為1.6；(實際工程經驗)
" 考慮伺服器保留30％的冗餘；
伺服器需要的處理能力為：
TPC-C=U1*N1*（T1+T2+T3）/3*3*經驗係數/冗餘係數
則應用伺服器的處理效能估算為：
TPC-C= 1500*2*（3+8+13）/3*5*1.6/0.7= 274,285 tpmC
資料庫伺服器關係到整個系統的穩定運行，考慮到高可靠性和高可用性，並注重裝置的可擴充性和性價比，系統將配置兩台TPC-C值不小於28萬的高效能資料程式庫伺服器