TiDB 壓力測試報告

TiDB 壓力測試報告

（轉載自公衆號DBATech）

1、測試環境

一、tidb 集羣架構：

測試使用最基本的TiDB架構。即 3個tidb-server節點+ 3個tikv節點 + 3個pd節點。

 

二、tidb集羣的部署環境(混合部署)：

192.168.xx.A 1*server +1*PD +1*tikv

192.168.xx.B 1*server +1*PD +1*tikv

192.168.xx.C 1*server +1*PD+1*tikv

IDC機器環境：

0S ：CentOS7

CPU ：Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz  *24

RAM ：48GB

DISK ：SSD, 480GB RAID0

 

TiDB 重要配置參數

如下這些參數都是會對tidb形成性能影響的參數。設置儘可能折中。較少對性能的影響。

tidb-server節點的設置：

[log]

level = "warn"

[prepared-plan-cache]

enabled = true

log-level = "warning"

[raftstore]

sync-log = false

 tikv節點的設置：

log-level = "warning"

[rocksdb.defaultcf]

[rocksdb.writecf]

block-cache-size = "6GB"    #關於寫的緩存塊大小  大概設置爲讀的1/3

max-background-jobs = 8  #後臺線程,用於壓縮數據與刷新數據

[raftstore]

sync-log = false

[storage.block-cache]

capacity = "20GB"   # 3.0以後 tikv的緩存，包括  rocksdb.defaultcf rocksdb.writecf  rocksdb.lockcf raftdb.defaultcf 都由改參數設置，緩存共享。

集羣正常啓動後，在每一個節點執行如下語句，關閉 失敗事務重試。

set global tidb_disable_txn_auto_retry = off

三、sysbench client：

6 臺機器 sysbench client （配置與tidb-server機器如出一轍）。每次測試6個機器同時發起6個sysbench進程。sysbech client 均勻鏈接到 3 tidb-server節點上（每2臺sysbench client 鏈接一個tidb-server節點）

因爲測試由6個機器併發發起，所以執行結果的 TPS QPS error  reconnects 是 6 個sysbench client 之和。min max 爲 6個節點的最小於最大值。avg 95th 爲6個節點值的平均值。

sysbench 壓測語句以下：

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=xxxx --mysql-port=xxxx --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sysbench --db-driver=mysql --tables=50 --table-size=10000000 --report-interval=1 --threads=[線程從2-24變化]  --rand-type=uniform   --time=300 --max-requests=0  run

說明：每一個sysbech client一次發起長達300秒測試。--max-requests=0 表示不限制測試達到的總qps。

測試數據準備：

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=xxxx --mysql-port=xxxx --mysql-user=xxxx --mysql-password=xxxx --mysql-db=sysbench --db-driver=mysql --tables=50 --table-size=10000000 --report-interval=100 --threads=24  --rand-type=uniform   --time=0 --max-requests=0 prepare

數據量：50張表，每一個表1000萬數據。大約200GB數據。緩存參數capacity爲20GB。緩存與持久化數據比例 大約爲1:10

 

5 測試腳本：

本猿編寫一小py小腳本（ https://github.com/jiasirVan/dbtool/blob/master/bench2.py ） 。

配置文件sysbench.cnf：

[mysql]

ip=192.168.xx.x

port=xxxx

user=xxxx

password=xxxx

dbname=sysbench

[sysbench]

#生成的表數量

table_amount=50

#限制總的執行時間(秒) 0表示不限制

exectime=300

#每一個表初始化多少行數據

rows=10000000

#請求的最大數目。默認爲1000000，0表明不限制

max_request=0

#每n秒輸出一次測試進度報告

interval=10

#指定sysbench的輸出日誌目錄

logdir=/tmp/log

##併發壓測的線程數

threadnumber=2,4,6,8,10,12,14,16,18,20,22,24

#指定用哪一個lua腳本測試

lua_script=/usr/share/sysbench/oltp_update_index.lua

 

執行腳本：./bench2.py  -c sysbench.cnf  -r -f  

測試結果直接格式化輸出，大約以下（每一行爲配置文件的一個threadnumber值，例如如下的2,4,6線程的輸出）。

輸出結果：

TPS    QPS    error/s    reconnects/s    min    avg    max    95th 

110.98    1775.60    0.00    0.00    10.95    18.02    164.74    23.10

250.54    4008.68    0.00    0.00    9.72    15.96    243.09    19.65

415.15    6642.39    0.00    0.00    9.04    14.45    281.74    18.28

 

---

 

2、sysbench測試說明：

sysbench mysql 的測試類型：

#1. bulk_insert.lua  批量寫入操做

#2. oltp_delete.lua 寫入和刪除並行操做

#3. oltp_insert.lua  純寫入操做

#4. oltp_point_select.lua  只讀操做，條件爲惟一索引列

#5. oltp_read_only.lua  只讀操做，包含聚合，去重等操做 大多數狀況用於統計的壓測

#6. oltp_read_write.lua 讀寫混合操做，最經常使用的腳本  用於oltp系統的壓測。

#7. oltp_update_index.lua 更新操做，經過主鍵進行更新

#8. oltp_update_non_index.lua 更新操做，不經過索引列

#9. oltp_write_only.lua 純寫操做，經常使用腳本，包括insert update delete

#10. select_random_points.lua 隨機集合只讀操做，經常使用腳本，彙集索引列的selete in操做

#11. select_random_ranges.lua 隨機範圍只讀操做，經常使用腳本，彙集索引列的selete between操做

注：由於sysbench測試客戶端機器與tidb服務器都在同機房。網絡ping延遲大約爲0.08ms 。能夠忽略不計。

 

---

三 、開始測試

 

說明：全部的tidb-server與 sysbench 測試機器在同機房，屢次ping 網絡延遲大約在0.08ms左右，能夠忽略不計。

 

一、惟一索引只讀壓測：

 

結論： 惟一索引讀是數據庫最高效的查詢操做。從上圖看，惟一索引select 的qps 在 client thread 併發達到 108 以後增加趨於平緩。大約qps在10萬左右。平均時延也相對較低。在1ms如下。越大的併發，平均qps時延增長。

 

---

 

二、只讀壓測(包括聚合，去重，關聯等複雜查詢

結論：以上是各種讀操做，包括 聚合，關聯，去重等複雜的select操做的壓測結果。比較符合分析系統型壓測。根據上圖壓測，QPS 在 client thread 108 以後增加趨於平緩。QPS 大約在55000左右。

---

 

三、讀寫混合測試（讀寫比例爲默認的7:3）：

結論：讀寫混合壓測針對OLTP在線系統，壓測結果展現 ，大約在 client thread 爲108併發以後，QPS增加趨於平緩。在 40000左右。時延隨着併發數的增長不斷的增大。

 

---

四、總結：

經過以上壓測。架構爲 3 tikv + 3 tidb-server+ 3 pd 架構的tidb分佈式集羣 在給定環境的下性能表現很好。client thread 併發支持在108 線程達到最大。繼續增大併發，QPS 增加並不明顯，會增大操做時延。在讀寫混合型的oltp系統中，QPS 達到 40000萬左右。併發上比mysql更優，得益於tidb的分佈式架構。但對於單個簡單查詢語句，mysql的響應時間更快。在大部分OLTP 系統上，都是簡單select操做，tidb的響應時間在1毫秒一下。與mysql 相差不大。但 tidb 的分佈式架構 支持更好的橫向擴展。