使用BenchmarkSQL測試PostgreSQL

時間 2019-11-19

標籤使用 benchmarksql 測試 postgresql 欄目 Postgre SQL 简体版

原文原文鏈接

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 CLASSPATHhtml

修改postgres.properties文件，即設置正確的數據庫名和密碼python

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數目，而後進行測試。linux

Ø 標準測試模擬的程序環境ios

測試用到的模型是一個大型的批發銷售公司，在地理分佈的多個區域有業務，而且使用倉庫管理。當業務擴展的時候，公司將添加新的倉庫。每一個倉庫負責十個區域的供貨，每一個區域 3000 個客戶服務，每一個倉庫維護 100000 種商品的庫存紀錄。以下圖所示：sql

TPC-C 標準測試系統的數據庫有 9 個表組成，他們之間的關係以下圖所示：shell

其中W 表明倉庫數,框中的數字表示該表將存放的記錄條數，K表明1000，倉庫數的調整在測試中可以體現數據庫所能支持的數據規模的能力。每一個 Warehouse 的數據量，其大小約爲 76823.04KB，能夠有小量的變化，由於測試過程當中將會插入或刪除現有記錄。能夠根據每一個Warehouse的數據量，計算測試過程當中的數據總量。數據庫

計算公式爲：數據總量（KB）≈ Warehouse個數*76823.04KBapache

以10個Warehouse的數據量爲例計算其數據總量大小約爲：768230.4KBwindows

Ø 標準測試模擬的事務處理bash

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
---------------------

2、測試前提
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文件中看到該軟件的使用說明，下面用中文具體介紹一下它的使用方法。

3、測試步驟
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）；

2.運行過程當中若是想要修改終端數等參數，最好關閉GUI界面，從新運行runBenchmark.bat

參考資料：
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目錄下，能夠打開看是否有報錯退出。