TiDB 壓力測試報告
（轉載自公眾號DBATech）
一、測試環境
1、tidb 集群架構：
測試使用最基本的TiDB架構。即 3個tidb-server節點+ 3個tikv節點 + 3個pd節點。
2、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
3、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
二、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左右，可以忽略不計。
1、唯一索引只讀壓測：
結論： 唯一索引讀是數據庫最高效的查詢操作。從上圖看，唯一索引select 的qps 在 client thread 並發達到 108 之后增長趨於平緩。大約qps在10萬左右。平均時延也相對較低。在1ms以下。越大的並發，平均qps時延增加。
2、只讀壓測(包括聚合，去重，關聯等復雜查詢
結論：以上是各類讀操作，包括 聚合，關聯，去重等復雜的select操作的壓測結果。比較符合分析系統型壓測。根據上圖壓測，QPS 在 client thread 108 之后增長趨於平緩。QPS 大約在55000左右。
3、讀寫混合測試（讀寫比例為默認的7:3）：
結論：讀寫混合壓測針對OLTP在線系統，壓測結果展示 ，大約在 client thread 為108並發之后，QPS增長趨於平緩。在 40000左右。時延隨着並發數的增加不斷的增大。
4、總結：
通過以上壓測。架構為 3 tikv + 3 tidb-server+ 3 pd 架構的tidb分布式集群 在給定環境的下性能表現很好。client thread 並發支持在108 線程達到最大。繼續增大並發，QPS 增長並不明顯，會增大操作時延。在讀寫混合型的oltp系統中，QPS 達到 40000萬左右。並發上比mysql更優，得益於tidb的分布式架構。但對於單個簡單查詢語句，mysql的響應時間更快。在大部分OLTP 系統上，都是簡單select操作，tidb的響應時間在1毫秒一下。與mysql 相差不大。但 tidb 的分布式架構 支持更好的橫向擴展。