tpcc使用說明
說明：文章內容起源於網絡並結合自己的實驗而得；但參考的文章地址當時沒記錄下來，如果發現有侵權問題，請留言。
一、介紹
壓力測試是指在MySQL上線前，需要進行大量的壓力測試，從而達到交付的標準。壓力測試不僅可以測試MySQL服務的穩定性，還可以測試出MySQL和系統的瓶頸。
TPCC測試：Transaction Processing Performance Council，要熟練使用TPC是一系列事務處理和數據庫基準測試的規範。其中TPC-C是針對OLTP的基準測試模型，一方面可以衡量數據庫的性能，另一方面可以衡量硬件性價比，也是廣泛應用並關注的一種測試模型。
TPC-C測試模型給基準測試提供了一種統一的測試標準，並非實際應用系統中的真實測試結果，但通過測試結果，可以大體觀察出MySQL數據庫服務穩定性、性能以及系統性能等一系列問題。TPC-C僅僅是一個測試模型，而在實際測試中，需要參考和使用一些測試工具，對系統和MySQL數據庫進行壓力測試、穩定性測試。
TPC-C模型是以一個在線零售業爲例，設計的一種模型，具體架構圖參考
tpcc測試庫數據比例圖
和
tpcc測試庫數據表關係圖
二、編譯安裝
1、下載地址
https://github.com/Percona-Lab/tpcc-mysql
2、修改程序，以實現對MGR的支持
如果是測試MGR模式，則需要手動修改與history表相關內容，因爲該表沒有主鍵，而MGR卻要求表必須有主鍵：否則，可跳過。
# unzip tpcc-mysql-master.zip1）在建表語句中，新增主鍵列：
# vim tpcc-mysql-master/create_table.sql 大約在62行處爲history表的建表語句；在其中添加建立主鍵id的語句：
create table history (
id bigint not null auto_increment, -- 新增id自增列
h_c_id int,
h_c_d_id tinyint,
h_c_w_id smallint,
h_d_id tinyint,
h_w_id smallint,
h_date datetime,
h_amount decimal(6,2),
h_data varchar(24),
PRIMARY KEY (id) -- 新增主鍵(注意與上一行的逗號分隔)
) Engine=InnoDB;2）修改INSERT語句
# vim tpcc-mysql-master/src/load.c大約在234行處爲history表的INSERT語句，修改爲如下內容:
"INSERT INTO history values(null,?,?,?,?,?,?,?,?)", 48) ) goto Error_SqlCall_close; 修改說明:
對主鍵列id在插入時新增null值，以便id自增；
將記錄原INSERT語句字符數校驗的數字從43改爲48；
以上2不修改完成後可以繼續，執行編譯了。
3、解壓編譯
# cd tpcc-mysql-master/src/
# make (沒有make install)執行成功後，在tpcc-mysql-master解壓目錄下生成了tpcc_load和tpcc_start命令
4、查看libmysqlclient.so.xx庫文件
備註:
當前的版本的tpcc必須使用libmysqlclient.so.xx版本的mysql庫文件。
mysql5.6爲libmysqlclient.so.18
mysql5.7爲libmysqlclient.so.20
設置方式有如下2種：
方式1：mysql5.7的libmysqlclient.so.20
# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
# echo "/usr/local/mysql-5.7.24/lib/" >> /etc/ld.so.conf
# cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/local/mysql-5.7.24/lib/
# /sbin/ldconfig -v 方式2：mysql5.6的libmysqlclient.so.18
# ls -l /usr/lib64/libmysqlclient.so*如果不存在，則後面執行tpcc_load和tpcc_start命令時會報錯。
將Mysql程序目錄下lib目錄中的libmysqlclient.so.18拷貝放入系統庫並賦權限(也可在環境變量的PATH中指定該庫文件地址)：
# mv libmysqlclient.so.18 /usr/lib64/
# chmod 777 /usr/lib64/libmysqlclient.so.18 在測試完成後，刪除該庫文件
# rm /usr/lib64/libmysqlclient.so.18三、加載測試數據
進入工作目錄(解壓後的目錄)
# cd tpcc-mysql-master1、在目標MySQL上創建測試數據庫
mysqladmin -uroot -p -S /data/s1/mysql.sock create tpcc10002、創建表
mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < create_table.sqltpcc創建了九張測試表：
客 戶：customer 表
地 區：district 表
商 品：item 表
歷史訂單：history 表
新訂單 ：new_orders 表
訂單狀態：order_line 表
訂 單：orders 表
庫存狀態：stock 表
倉 庫：warehouse 表
tpcc-mysql的業務邏輯及其相關的幾個表作用如下：
New-Order==>新訂單，一次完整的訂單事務，幾乎涉及到全部表
Payment ==>支付，主要對應 orders、history 表
Order-Status==>訂單狀態，主要對應 orders、order_line 表
Delivery ==>發貨，主要對應 order_line 表
Stock-Level==>庫存，主要對應 stock 表
3、對錶添加外鍵
mysql -uroot -p -S /data/s1/mysql.sock tpcc1000 < add_fkey_idx.sql4、載入測試數據
# ./tpcc_load --help
Usage: tpcc_load -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -l part -m min_wh -n max_wh
* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS例如：創建5個倉庫，加載全部表的測試數據
# ./tpcc_load -h 127.0.0.1 -P 3306 -d tpcc1000 -u root -p '123456' -w 5 備註:
1）這個過程有點慢 ，1個warehouse對應10個地區，1地區對應3000的用戶，10個倉庫剛導入進去的大小約爲1G；
2）倉數可根據需要來設置，總結網上資料所說，設置40-100個是對CPU的測試，400-1000個是對IO的測試，40以下無論事務多少，鎖競爭情況也不太容易發生；
3）真實測試場景中，倉庫數一般不建議少於100個，視服務器硬件配置而定，如果是配備了SSD或者PCIE SSD這種高IOPS設備的話，建議最少不低於1000個。
如果要並行加載測試數據，可以使用load.sh腳本。
四、執行測試
1、非MGR多主模式壓測
./tpcc_start -h127.0.0.1 -P 3306 -dtpcc1000 -uroot -p '123456' -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx-h：測試主機
-d：測試的數據庫
-u：測試的用戶
-p：測試用戶的密碼
-w：測試的warehouse數
-c：測試的連接線程數
-r：預熱時間，warmup_time，以秒爲單位，默認是10秒，目的是爲了將數據加載到內存
-l：測試時間，默認爲20秒
-i：report_interval指定生成報告的間隔時間
-f：report_file將測試中各項操作的記錄輸出到指定文件內保存
-t：trx_file輸出更詳細的操作信息到指定文件內保存
備註：
真實測試場景中，建議預熱時間不小於5分鐘，持續壓測時長不小於30分鐘，否則測試數據可能不具參考意義。
2、MGR多主模式壓測
由於MGR在對大事務支持和事務衝突檢測上的限制和不足，導致對MGR直接並行壓測是不可能的。Oracle官方的Multi-Primary Mode測試是在每個結點上，
對不同的測試庫進行壓測，即這樣可以避免了工具無法並行壓測的問題，同時，這樣也減少了衝突的可能性。切記，Multi-Primary Mode一定要避免熱點數據衝突的場景。
例如MGR集羣中有3個節點，分別爲A、B、C；那麼，壓測時需要建立至少3個庫；這樣每個tpcc壓測都使用1個線程來測試一個庫，並且同時啓動多個tpcc來測試。
可以這樣測試：
A節點：
./tpcc_start -h188.188.0.68 -P3306 -uroot -p '123456' -d tpcc1 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....B節點：
./tpcc_start -h188.188.0.69 -P3306 -uroot -p '123456' -d tpcc2 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....C節點：
./tpcc_start -h188.188.0.70 -P3306 -uroot -p '123456' -d tpcc3 -w 5 -c 1 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
.....不過對Multi-Primary Mode壓測並不會有一個很好的結果，因爲熱點太過集中，會導致提交失敗很多，或許反而會導致了性能的下降。
五、結果分析
[root@localhost tpcc-mysql-master]# ./tpcc_start -h127.0.0.1 -P24801 -dtpcc1000 -uroot -p '' -w 5 -c 32 -r 10 -l 30 -i 10 -f tpcc_mysql.log -t tpcc_mysql.rtx
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value '127.0.0.1'
option P with value '24801'
option d with value 'tpcc1000'
option u with value 'root'
option p with value ''
option w with value '5'
option c with value '32'
option r with value '10'
option l with value '30'
option i with value '10'
option f with value 'tpcc_mysql.log'
option t with value 'tpcc_mysql.rtx'
<Parameters>
[server]: 127.0.0.1
[port]: 24801
[DBname]: tpcc1000
[user]: root
[pass]:
[warehouse]: 5
[connection]: 32
[rampup]: 10 (sec.)
[measure]: 30 (sec.)
RAMP-UP TIME.(10 sec.)
MEASURING START. -- 預熱結束，開始進行壓測
-- 設置的每10秒鐘輸出一次壓測數據
10, trx: 1500, 95%: 204.109, 99%: 430.483, max_rt: 666.515, 1502|936.479, 150|225.372, 151|995.094, 151|650.192
20, trx: 1349, 95%: 191.559, 99%: 458.275, max_rt: 659.284, 1342|842.605, 134|191.606, 136|981.992, 135|522.363
30, trx: 1211, 95%: 209.746, 99%: 519.825, max_rt: 766.855, 1213|987.708, 122|142.544, 121|1085.795, 121|386.247
說明:分爲6項，依次爲操作時間(秒)、創建訂單、訂單支付、查詢訂單狀態、物流發貨以及查詢庫存倉儲
10, ==>測試進行的時間(秒)
trx: 1500, ==>在給定間隔期間執行的新訂單交易數；它基本上是每個間隔內的吞吐量，該值越大越好。
95%: 204.109,==>每個給定間隔的95％的新訂單交易響應時間，這裏是204.109秒。
99%: 430.483,==>每個給定間隔的99％的新訂單交易響應時間，這裏是430.483秒。
max_rt: 666.515,==>每個給定間隔的新訂單交易的最大響應時間，這裏是666.515秒。
1502|936.479, 150|225.372, 151|995.094, 151|650.192==>是其他類型事務的吞吐量和最大響應時間，可以忽略。(訂單支付、查詢訂單狀態、物流發貨以及查詢庫存倉儲)
STOPPING THREADS................................ -- 壓測結束
<Raw Results>
[0] sc:0 lt:4060 rt:0 fl:0 avg_rt: 86.8 (5)
[1] sc:1 lt:4056 rt:0 fl:0 avg_rt: 167.6 (5)
[2] sc:345 lt:61 rt:0 fl:0 avg_rt: 8.6 (5)
[3] sc:0 lt:408 rt:0 fl:0 avg_rt: 449.4 (80)
[4] sc:15 lt:392 rt:0 fl:0 avg_rt: 132.6 (20)
in 30 sec.
-- 第一次結果統計說明
[0] ==>New-Order，新訂單業務成功(success,簡寫sc)次數，延遲(late,簡寫lt)次數，重試(retry,簡寫rt)次數，失敗(failure,簡寫fl)次數；一次完整的訂單事務，幾乎涉及到全部表。
[1] ==>Payment，支付業務統計，其他同上，主要對應 orders、history 表；
[2] ==>Order-Status，訂單狀態統計，其他同上，主要對應 orders、order_line 表；
[3] ==>Delivery，發貨業務統計，其他同上，主要對應 order_line 表；
[4] ==>Stock-Level，庫存業務統計，其他同上，主要對應 stock 表；
<Raw Results2(sum ver.)>
[0] sc:0 lt:4060 rt:0 fl:0
[1] sc:1 lt:4060 rt:0 fl:0
[2] sc:345 lt:61 rt:0 fl:0
[3] sc:0 lt:408 rt:0 fl:0
[4] sc:15 lt:392 rt:0 fl:0
<Constraint Check> (all must be [OK]) -- 下面所有業務邏輯結果都必須爲 OK 才行
[transaction percentage]
Payment: 43.45% (>=43.0%) [OK] -- 支付成功次數(上述統計結果中 sc + lt)必須大於43.0%，否則結果爲NG，而不是OK
Order-Status: 4.35% (>= 4.0%) [OK] -- 訂單狀態，其他同上
Delivery: 4.37% (>= 4.0%) [OK] -- 發貨，其他同上
Stock-Level: 4.36% (>= 4.0%) [OK] -- 庫存，其他同上
[response time (at least 90% passed)] -- 響應耗時指標必須超過90%通過才行
New-Order: 0.00% [NG] * -- 下面幾個響應耗時指標全部 未 通過
Payment: 0.02% [NG] *
Order-Status: 84.98% [NG] *
Delivery: 0.00% [NG] *
Stock-Level: 3.69% [NG] *
<TpmC>
8120.000 TpmC -- TpmC結果值（每分鐘事務數，該值是第一次統計結果中的新訂單事務數除以總耗時分鐘數）完畢！