BenchmarkSQL是一款經典的開源數據庫測試工具，內嵌了TPCC測試腳本，可以對EnterpriseDB、PostgreSQL、MySQL、Oracle以及SQL Server等數據庫直接進行測試，下面筆者就如何在Linux下使用這款測試工具測試PostgreSQL的性能來做一些簡單介紹（操作系統為Fedora 12，PostgreSQL版本為8.0.22）。
首先，在Linux下安裝JDK。因為BenchmarkSQL本身是使用Java語言編寫的，所以如果在Linux系統下還沒有安裝JDK的話，我們首先需要對其進行安裝。
1）下載Linux Platform JDK（如jdk-6u20-linux-i586.bin）；
2）鍵入命令./jdk-6u20-linux-i586.bin運行安裝程序，這時會有一段Sun的協議，敲幾次Enter鍵，當詢問是否同意的時候敲Yes就可以了，之后程序會自行安裝JDK並創建一個文件夾jdk1.6.0-20；
3）將安裝后的文件夾移動到一個指定的地方，如mv jdk1.6.0-20 /usr/local，當然這一步不是必須的；
4）設置環境變量。環境變量的設置方法有多種如用export直接在shell下設置、修改文件.bashrc設置以及修改/etc/profile設置，我們這里直接使用最后一種方法，雖然第二種方法比較受推崇。我們在profile文件末尾直接添加如下內容：
JAVA_HOME=/usr/local/jdk1.6.0-20
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export JAVA_HOME
export PATH
export CLASSPATH
修改postgres.properties文件，即設置正確的數據庫名和密碼
4)運行BenchmarkSQL進行測試。我們首先進入到BenchmarkSQL-2.3.2/run的目錄下，然后運行如下命令：
./runSQL.sh postgres.properties sqlTableCreates
此命令用於創建我們進行TPCC測試所需的數據庫表
./loadData.sh postgres.properties numWarehouses=10
此命令用於加載我們進行TPCC測試所需的數據
./runSQL.sh postgres.properties sqlIndexCreates
此命令用於創建我們進行TPCC測試所需的索引
./runBenchmark.sh postgres.properties
開始TPCC測試，這時會跳出一個對話框，用戶可以根據自己的測試需要設定相關的warehouse數目和terminal數目，然后進行測試。
Ø 標准測試模擬的程序環境
測試用到的模型是一個大型的批發銷售公司，在地理分布的多個區域有業務，並且使用倉庫管理。當業務擴展的時候，公司將添加新的倉庫。每個倉庫負責十個區域的供貨，每個區域 3000 個客戶服務，每個倉庫維護 100000 種商品的庫存紀錄。如下圖所示：
TPC-C 標准測試系統的數據庫有 9 個表組成，他們之間的關系如下圖所示：
其中W 代表倉庫數,框中的數字表示該表將存放的記錄條數，K代表1000，倉庫數的調整在測試中能夠體現數據庫所能支持的數據規模的能力。每個 Warehouse 的數據量，其大小約為 76823.04KB，可以有小量的變化，因為測試過程中將會插入或刪除現有記錄。可以根據每個Warehouse的數據量，計算測試過程中的數據總量。
計算公式為：數據總量（KB）≈ Warehouse個數*76823.04KB
以10個Warehouse的數據量為例計算其數據總量大小約為：768230.4KB
Ø 標准測試模擬的事務處理
TPC-C 標准測試模擬了 5 種事務處理，通過這些事務處理來模擬真實的用戶操作,事務分別為新訂單（New-Order）、支付操作(Payment)、訂單狀態查詢(Order-Status)、發貨(Delivery)、庫存狀態查詢(Stock-Level)。下面將對其執行的事務內容及特點進行詳細介紹.
1．新訂單（New-Order）
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取 5-15 件商品,創建新訂單.其中 1%的訂單要由假想的用戶操作失敗而回滾。
主要特點：中量級、讀寫頻繁、要求響應快.
2．支付操作(Payment)
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取一個轄區及其內用
戶,采用隨機的金額支付一筆訂單,並作相應歷史紀錄。
主要特點：輕量級，讀寫頻繁，要求響應快
3．訂單狀態查詢(Order-Status)
事務內容：對於任意一個客戶端,從固定的倉庫隨機選取一個轄區及其內用戶,讀取其最后一條訂單,顯示訂單內每件商品的狀態。
主要特點：中量級，只讀頻率低，要求響應快
4．發貨(Delivery)
事務內容：對於任意一個客戶端,隨機選取一個發貨包,更新被處理訂單的用戶余額,並把該訂單從新訂單中刪除.
主要特點：1-10 個批量，讀寫頻率低，較寬松的響應時間
5．庫存狀態查詢(Stock-Level)
事物內容：對於任意一個客戶端,從固定的倉庫和轄區隨機選取最后 20 條訂單,查看訂單中所有的貨物的庫存,計算並顯示所有庫存低於隨機生成域值的商品數量.
主要特點：重量級,只讀頻率低,較寬松的響應時間.
Ø 標准中事務處理需要滿足的條件
TPC-C 標准測試要求事務處理必須滿足下面的兩組條件.
1. 事務處理要滿足的時間及占有的比例
五種事務要滿足的時間要求，包括鍵盤操作時間（Keying Time）,思考時間
因子(Think Time Distribution)以及 90%的響應時間（90th Percentile Response Time）限制。
2. 事務要滿足的隔離級別
TPC-C 測試過程中應該滿足的隔離級別要求。要求只能高不能低。
T1到T5分別指五種事務：New-Order，Payment，Order-Status，Delivery，Stock-Level。
P0到P3分別指：臟寫，臟讀，非重復性讀，幻影
Ø 測試指標
TPC-C測試的結果主要有兩個指標，即流量指標（Throughput,簡稱tpmC)和性價比（Price/Performance,簡稱Price/tpmC)。
流量指標(Throughput,簡稱tpmC)：按照TPC組織的定義，流量指標描述了系統在執行支付操作、訂單狀態查詢、發貨和庫存狀態查詢這4種交易的同時，每分鍾可以處理多少個新訂單交易。所有交易的響應時間必須滿 足TPC-C測試規范的要求，且各種交易數量所占的比例也應該滿足TPC-C測試規范的要求。在這種情況下，流量指標值越大說明系統的聯機事務處理能力越高。
性價比（Price/Performance,簡稱Price/tpmc)：即測試系統的整體價格與流量指標的比值，在獲得相同的tpmC值的情況下，價格越低越好。
Ø TPC-C的測試工具
常用的開源TPC-C基准測試工具有BenchmarkSQL, dbt2-v0.23等等。
benchmarkSQL的安裝部署
（1）.JDK1.7
（2）.apache ant
benchmarkSQL的配置文件解析:
第一個部分是JDBC連接信息。
第二個部分是場景設置，其中runTxnsPerTerminal是每分鍾執行事務數，runMins是執行多少分鍾，limitTxnsPerMin是每分鍾執行的事務總數，並且這里時間的單位是分鍾。場景執行的最低條件是第二項大於0。
第三個部分是TPCC中，五個事務執行的比例，總數等於100，通常不用修改。
典型配置：
Oracle配置需要修改的地方：
ü 每個倉庫要100M的空間1000個需要100G的存儲表空間。
ü 設置ORACLE 批量提交參數：
SQL> alter system set commit_write='batch,nowait';
ü 使用強制軟解析
SQL> alter system set cursor_sharing=force;
ü 使用O_DIRECT
SQL>alter system set filesystemio_options=directioscope=spfile;
SQL> alter system set disk_asynch_io=falsescope=spfile;
ü 修改最大連接數，打開游標數
SQL> alter system set processes=3000 scope=spfile;
SQL> ALTER SYSTEM SET open_cursors=900 SCOPE=BOTH;
SQL> alter system set session_cached_cursors=0scope=spfile;
ü 重啟數據庫
Ø Benchmarksql 操作<和howTO.txt不同>：
在Oracle目標庫創建了表空間和用戶之后：
(1).runSQL.sh profile./sql.common/tableCreate.sql
(2).LoadSQL.shprofile
(3).runSQL.shprofile ./sql.common/indexCreate.sql
(4).runBenchmarkSQL.sh
---------------------
二、測試前提
1. 安裝JDK。因為BenchmarkSQL本身是使用Java語言編寫的，所以如果在Linux系統下還沒有安裝JDK的話，我們首先需要對其進行安裝；
2. 安裝PostgreSQL數據庫系統。俗話說巧婦難為無米之炊，測試之前肯定需要有測試對象，本文是測試PG系統，故需安裝有PG；
3. 安裝BenchmarkSQL
可到http://sourceforge.net中搜索BenchmarkSQL即可下到，windows，linux版均有。我下載的是linux版的軟件包BenchmarkSQL-2.3.3.zip，unzip解壓后可以在README文件中看到該軟件的使用說明，下面用中文具體介紹一下它的使用方法。
三、測試步驟
1. 啟動待測試的數據庫系統，這里即指啟動PostgreSQL
2. 在BenchmarkSQL-2.3.3/run目錄下找到postgres.properties配置文件，修改該文件如下：
driver=org.postgresql.Driver
conn=jdbc:postgresql://localhost:5432/test #鏈接數據庫地址
user=postgres #鏈接數據庫用戶名
password=password #密碼
如果想測試其他數據庫系統，則修改其他相應的配置文件即可，如oracle.properties等等。
3. 創建TPC-C基礎表（即上篇博文中介紹的TPC-C模擬場景中9張表）
命令： runSQL.sh postgres.properties sqlTableCreates
4. 向數據庫中導入指定大小的數據(參考資料2中此步有個小問題，多寫一個等號)
命令：loadData.sh postgres.properties numWarehouses 10
numWarehouse指的是倉庫數（具體含義見上篇博文），默認為1，導入9張表的數據大小大概70多M，
當 numWarehouse為10時，數據大小可以近似當作1GB數據。
5. 為基礎表創建必要的索引
命令： runSQL.sh postgres.properties sqlIndexCreates
6. 運行runBenchmark.sh借助GUI程序測試數據庫
命令：runBenchmark.sh postgres.properties
注意：不要忘記設置圖形界面的倉庫數時要與第4步中設置的數量相符；此外，測試的結果報告除了顯示在圖形界面有顯示以外，還在run/reports目錄下有備份，隨時可以查閱。
1. 測試完后在界面下方會顯示簡要的測試結果，包括平均tpmC值（每分鍾執行的事務數），當前tpmC值，內存使用情況等等；出結果以后盡量記錄下來，以為之后如果亂點界面按鈕的話，測試結果將會被重寫（感覺是一個bug）；
參考資料：
1.http://blog.sina.com.cn/s/blog_4485748101019wsh.html
2.http://blog.sina.com.cn/s/blog_48c95a190100j35g.html
3.http://www.docin.com/p-242425868.html
創建BenchmarkSQL配置文件：
切換到run路徑下，復制一個props.pg文件，該文件是設置測試運行參數的文件，需要根據具體的測試要求進行修改：
[wieck@localhost benchmarksql] $ cd run
[wieck@localhost run] $ cp props.pg my_postgres.properties
[wieck@localhost run] $ vi my_postgres.properties
[wieck@localhost run] $
配置文件重要參數如下：
1）warehouse：
BenchmarkSQL數據庫每個warehouse大小大概是100MB，如果該參數設置為10，那整個數據庫的大小大概在1000MB。建議將數據庫的大小設置為服務器物理內存的2-5倍，如果服務器內存為16GB，那么warehouse設置建議在328～819之間。
2）terminals：
terminals指的是並發連接數，建議設置為服務器CPU總線程數的2-6倍。如果服務器為雙核16線程（單核8線程），那么建議配置在32～96之間。
4.配置文件詳解：
db=postgres //數據庫類型，postgres代表我們對PG數據庫進行測試，不需要更改
driver=org.postgresql.Driver //驅動，不需要更改
conn=jdbc:postgresql://localhost:5432/postgres //PG數據庫連接字符串，正常情況下，需要更改localhost為對應PG服務IP、5432位對應PG服務端口、postgres為對應測試數據庫名
user=benchmarksql //數據庫用戶名，通常建議用默認，這就需要我們提前在數據庫中建立benchmarksql用戶
password=PWbmsql //如上用戶密碼
warehouses=1 //倉庫數量，數量根據實際服務器內存配置，配置方法見第3步
loadWorkers=4 //用於在數據庫中初始化數據的加載進程數量，默認為4，實際使用過程中可以根據實際情況調整，加載速度會隨worker數量的增加而有所提升
terminals=1 //終端數，即並發客戶端數量，通常設置為CPU線程總數的2～6倍
//每個終端（terminal）運行的固定事務數量，例如：如果該值設置為10，意味着每個terminal運行10個事務，如果有32個終端，那整體運行320個事務后，測試結束。該參數配置為非0值時，下面的runMins參數必須設置為0
runTxnsPerTerminal=10
//要測試的整體時間，單位為分鍾，如果runMins設置為60，那么測試持續1小時候結束。該值設置為非0值時，runTxnsPerTerminal參數必須設置為0。這兩個參數不能同時設置為正整數，如果設置其中一個，另一個必須為0，主要區別是runMins定義時間長度來控制測試時間；runTxnsPerTerminal定義事務總數來控制時間。
runMins=0
//每分鍾事務總數限制，該參數主要控制每分鍾處理的事務數，事務數受terminals參數的影響，如果terminals數量大於limitTxnsPerMin值，意味着並發數大於每分鍾事務總數，該參數會失效，想想也是如此，如果有1000個並發同時發起，那每分鍾事務數設置為300就沒意義了，上來就是1000個並發，所以要讓該參數有效，可以設置數量大於並發數，或者讓其失效，測試過程中目前采用的是默認300。
//測試過程中的整體邏輯通過一個例子來說明：假如limitTxnsPerMin參數使用默認300，termnals終端數量設置為150並發，實際會計算一個值A=limitTxnsPerMin/terminals=2（此處需要注意，A為int類型，如果terminals的值大於limitTxnsPerMin，得到的A值必然為0，為0時該參數失效），此處記住A=2；接下來，在整個測試運行過程中，軟件會記錄一個事務的開始時間和結束時間，假設為B=2000毫秒；然后用60000（毫秒，代表1分鍾）除以A得到一個值C=60000/2=30000，假如事務運行時間B<C，那么該事務執行完后，sleep C-B秒再開啟下一個事務；假如B>C，意味着事務超過了預期時間，那么馬上進行下一個事務。在本例子中，每分鍾300個事務，設置了150個並發，每分鍾執行2個並發，每個並發執行2秒鍾完成，每個並發sleep 28秒，這樣可以保證一分鍾有兩個並發，反推回來整體並發數為300/分鍾。
limitTxnsPerMin=300
//終端和倉庫的綁定模式，設置為true時可以運行4.x兼容模式，意思為每個終端都有一個固定的倉庫。設置為false時可以均勻的使用數據庫整體配置。TPCC規定每個終端都必須有一個綁定的倉庫，所以一般使用默認值true。
terminalWarehouseFixed=true
//下面五個值的總和必須等於100，默認值為：45, 43, 4, 4 & 4 ，與TPC-C測試定義的比例一致，實際操作過程中，可以調整比重來適應各種場景。
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
//測試數據生成目錄，默認無需修改，默認生成在run目錄下面，名字形如my_result_xxxx的文件夾。
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
//操作系統性能收集腳本，默認無需修改，需要操作系統具備有python環境
osCollectorScript=./misc/os_collector_linux.py
//操作系統收集操作間隔，默認為1秒
osCollectorInterval=1
//操作系統收集所對應的主機，如果對本機數據庫進行測試，該參數保持注銷即可，如果要對遠程服務器進行測試，請填寫用戶名和主機名。
//osCollectorSSHAddr=user@dbhost
//操作系統中被收集服務器的網卡名稱和磁盤名稱，例如：使用ifconfig查看操作系統網卡名稱，找到測試所走的網卡，名稱為enp1s0f0，那么下面網卡名設置為net_enp1s0f0（net_前綴固定）；使用df -h查看數據庫數據目錄，名稱為（/dev/sdb 33T 18T 16T 54% /hgdata），那么下面磁盤名設置為blk_sdb（blk_前綴固定）
osCollectorDevices=net_eth0 blk_sda
5. 創建數據庫表並加載數據：
執行runDatabaseBuild.sh腳本，腳本后跟上面編輯好的配置文件，例如：
[wieck@localhost run]$ ./runDatabaseBuild.sh my_postgres.properties
# ------------------------------------------------------------
# Loading SQL file ./sql.common/tableCreates.sql
# ------------------------------------------------------------
create table bmsql_config (
cfg_name varchar(30) primary key,
cfg_value varchar(50)
);
create table bmsql_warehouse (
w_id integer not null,
w_ytd decimal(12,2),
[...]
Starting BenchmarkSQL LoadData
driver=org.postgresql.Driver
conn=jdbc:postgresql://localhost:5432/benchmarksql
user=benchmarksql
password=***********
warehouses=30
loadWorkers=10
fileLocation (not defined)
csvNullValue (not defined - using default 'NULL')
Worker 000: Loading ITEM
Worker 001: Loading Warehouse 1
Worker 002: Loading Warehouse 2
Worker 003: Loading Warehouse 3
[...]
Worker 000: Loading Warehouse 30 done
Worker 008: Loading Warehouse 29 done
# ------------------------------------------------------------
# Loading SQL file ./sql.common/indexCreates.sql
# ------------------------------------------------------------
alter table bmsql_warehouse add constraint bmsql_warehouse_pkey
primary key (w_id);
alter table bmsql_district add constraint bmsql_district_pkey
primary key (d_w_id, d_id);
[...]
vacuum analyze;
[wieck@localhost run]$
6. 運行測試：
執行腳本runBenchmark.sh，后面緊跟上面定義的配置文件作為參數，例如：
[wieck@localhost run]$ ./runBenchmark.sh my_postgres.properties
The benchmark should run for the number of configured concurrent
connections (terminals) and the duration or number of transactions.
The end result of the benchmark will be reported like this:
01:58:09,081 [Thread-1] INFO jTPCC : Term-00,
01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Measured tpmC (NewOrders) = 179.55
01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Measured tpmTOTAL = 329.17
01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Session Start = 2016-05-25 01:58:07
01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Session End = 2016-05-25 01:58:09
01:58:09,082 [Thread-1] INFO jTPCC : Term-00, Transaction Count = 10
至此整個測試流程完成。
7. 重新運行測試：
執行runDatabaseDestroy.sh腳本帶配置文件可以將所有的數據和表都刪除，然后再重新修改配置文件，重新運行build和benchmark腳本進行新一輪測試。
[wieck@localhost run]$ ./runDatabaseDestroy.sh my_postgres.properties
[wieck@localhost run]$ ./runDatabaseBuild.sh my_postgres.properties
8. 生成結果報告：
BenchmarkSQL測試會收集詳細的性能指標，如果配置了操作系統參數收集，同樣也會收集操作系統級別網卡和磁盤的性能指標，默認生成的數據在run/my_result_xx目錄下。生成的報告，可以通過腳本文件generateReport.sh + my_result_xx生成帶有圖形的HTML文件。生成圖形的腳本generateReport.sh要求操作系統環境中已經安裝了R語言，R語言的安裝在這里不贅述。
9.日志：
如果運行過程中產生日志和錯誤，都會存儲在run目錄下，可以打開看是否有報錯退出。