TiDB Sysbench 性能對比測試報告 - v5.1.4 對比 v6.0.0 DMR

1. 背景

目前我們線上 TiDB 叢集統一更新到了 v5.1.4 版本，對于 v6.0.0 版本我們有很多期待，本文不會讨論 v6.0.0 的特性，但打算将其性能與 v5.1.4 進行對比，看看它的性能是否有提升。

2. 測試概述

使用 TiUP 部署 TiDB 叢集，叢集部署規模為 3 TiDB Server、3 PD Server、6 TiKV Server，使用 LVS 作為負載均衡器，Sysbench 測試工具部署在另一台伺服器上，作為用戶端的壓力測試伺服器，進行 OLTP 測試。本文主要對 TiDB v5.1.4 版本和 TiDB v6.0.0 DMR 版本進行對比性能測試。

3. 測試環境

3.1 硬體配置

使用 6 台浪潮伺服器，硬體配置如下(伺服器 IP 已脫敏)：

伺服器	CPU	記憶體	硬碟
192.168.1.1	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10
192.168.1.2	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10
192.168.1.3	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10
192.168.1.4	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10
192.168.1.5	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10
192.168.1.6	Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz 128 核	256G	448GB2 RAID1 + 3.57T6 SSD RAID10

備注：每台伺服器有 4 個 numa node。

3.2 軟體環境 

安裝的主要軟體及其版本如下：

軟體名稱	軟體用途	版本
CentOS	作業系統	7.4
TiDB 叢集	開源 NewSQL 資料庫	v5.1.4 / v6.0.0 DMR
Sysbench	壓力測試工具	1.0.9

3.3 參數配置

兩個版本使用相同的配置參數。

3.3.1 TiDB 參數配置

prepared-plan-cache.enabled: true
tikv-client.max-batch-wait-time: 2000000      

3.3.2 TiKV 參數配置

raftstore.store-pool-size: 4
raftstore.apply-pool-size: 4
rocksdb.max-background-jobs: 8
raftdb.max-background-jobs: 4
raftdb.allow-concurrent-memtable-write: true
server.grpc-concurrency: 6
pessimistic-txn.pipelined: true
server.enable-request-batch: false
storage.block-cache.capacity: "37GB"      

3.3.3 TiDB 全局變量配置

set global tidb_hashagg_final_concurrency=1;
set global tidb_hashagg_partial_concurrency=1;
set global tidb_enable_async_commit = 1;
set global tidb_enable_1pc = 1;
set global tidb_guarantee_linearizability = 0;
set global tidb_enable_clustered_index = 1;      

4. 測試方案

1. 通過 TiUP 部署 TiDB v5.1.4 和 v6.0.0。
2. 通過 Sysbench 導入 16 張表，每張表有 1000 萬行資料。
3. 分别對每個表執行 analyze table 指令。
4. 啟動 Sysbench 用戶端，進行 oltp_read_write、oltp_point_select、oltp_update_index 和 oltp_update_non_index 測試。通過 LVS 向 TiDB 加壓，測試 10 分鐘，每一輪測試中間間隔 5 分鐘。
5. 測試完 v5.1.4 版本之後，銷毀叢集，部署 v6.0.0 叢集重新測試。

4.1 初始化資料

執行以下指令來準備測試資料：

sysbench oltp_common.lua --db-driver=mysql --mysql-host=192.168.1.8 --mysql-port=4000 --mysql-db=sysbench --mysql-user=username --mysql-password=password --table-size=10000000 --tables=16 --rand-type=uniform --threads=16 prepare      

4.2 測試指令

執行以下指令來執行測試：

sysbench ${test_type}.lua --db-driver=mysql --mysql-host=192.168.1.8 --mysql-port=4000 --mysql-db=sysbench --mysql-user=username --mysql-password=password --table_size=10000000 --tables=16 --time=600 --report-interval=1 --rand-type=uniform --threads=${thread_num} run      

5. 測試結果

5.1 Point Select 性能

壓測線程	v5.1.4 TPS	v6.0.0 TPS	v5.1.4 95% latency (ms)	v6.0.0 95% latency (ms)	TPS 提升(%)
150	296958	291233	0.75	0.73	-1.93%
300	442315	450641	1.3	1.06	1.88%
600	536790	571275	2.61	1.96	6.42%
900	545976	592352	4.03	3.02	8.49%
1200	551751	595144	5.37	4.18	7.86%
1500	550086	591925	6.79	5.47	7.61%

v6.0.0 對比 v5.1.4，Point Select 性能提升了 5.055%。

5.2 Update Non-index 性能

壓測線程	v5.1.4 TPS	v6.0.0 TPS	v5.1.4 95% latency (ms)	v6.0.0 95% latency (ms)	TPS 提升(%)
150	72033	72148	3.02	2.86	0.16%
300	107671	108816	4.25	3.96	1.06%
600	151318	152488	6.32	5.77	0.77%
900	176967	182077	8.58	7.56	2.89%
1200	192294	196657	11.04	9.91	2.27%
1500	199978	206365	13.70	12.52	3.19%

v6.0.0 對比 v5.1.4，Update Non-index 性能提升了 1.72%。

-1653576160906.png>)

5.3 Update Index 性能

壓測線程	v5.1.4 TPS	v6.0.0 TPS	v5.1.4 95% latency (ms)	v6.0.0 95% latency (ms)	TPS 提升(%)
150	40980	41539	5.47	5.09	1.36%
300	56463	57782	8.58	7.7	2.34%
600	71688	75408	14.73	12.98	5.19%
900	80166	84252	20.74	18.95	5.10%
1200	85066	90808	26.20	24.38	6.75%
1500	90039	95682	31.37	29.19	6.27%

v6.0.0 對比 v5.1.4，Update Index 性能提升了 4.5%。

-1653576170121.png>)

5.4 Read Write 性能

說明：
oltp read write 場景測試時使用的壓測線程數和前面三種場景有所不同，原因是：當 tidb-server 綁定到 numa node 之後，在并發 600 線程壓測時，cpu 使用率就達到了整個伺服器 cpu 資源的 25%，即到達一個 numa node 能使用的 cpu 資源的瓶頸了。是以，針對這個場景，單獨設計了壓測線程數。      

壓測線程	v5.1.4 TPS	v6.0.0 TPS	v5.1.4 95% latency (ms)	v6.0.0 95% latency (ms)	TPS 提升(%)
32	2521	2569	15.83	14.73	1.90%
64	4360	4533	18.61	17.32	3.97%
128	6728	6943	23.95	22.69	3.20%
200	8450	8577	29.72	29.72	1.50%
256	9311	9516	34.95	36.89	2.20%
300	9822	10142	40.37	42.61	3.26%

v6.0.0 對比 v5.1.4，Read Write 性能提升了 2.67%。

-1653576179608.png>)

6. 測試中遇到的問題和建議

6.1 遇到問題

• v6.0.0 相比 v5.1.4 在 point select 場景下性能下降嚴重 在測試 point select 場景時，v6.0.0 版本相比 v5.1.4 版本性能下降高達 38% 之多，經過分析是 tidb-server 跨 NUMA 通路記憶體導緻的問題，将 tidb-server 綁定到 numa node 之後重新測試，性能從未綁定時的 -38% 到綁定之後的 5.055%，差異巨大。是以，部署叢集時，強烈建議将 TiDB、PD、TiKV 與 NUMA node 一對一綁定，否則測試中可能遇到各種奇怪的問題，詳情可以參考文末參考文檔中的文章。
• 在 read write 場景下，并發達到 900 時 TPS 達到瓶頸 在測試 read write 場景時，當并發壓測線程數為 900 時，v6.0.0 和 v5.1.4 的 TPS 不再增加，但是 latency 增加，像是某種資源達到了瓶頸導緻的。經過分析得知：當 tidb-server 綁定到 numa node 之後，在并發 900 線程壓測時，cpu 使用率就達到了整個伺服器 cpu 資源的 25%，即到達一個 numa node 能使用的 cpu 資源的瓶頸了，此時，如果想獲得更高的性能，提升 TPS，需要擴容 TiDB。這裡有一個建議：在 OLTP 場景的壓測下，要合理設計并發線程數，觀察 TiDB CPU 資源使用率，盡量控制 TiDB CPU 使用率在 60% 以下。

<!---->

• TPS 掉底 在測試 update non index 場景時，TPS 不穩定，出現掉底現象，經過分析，原因是當 TiKV 綁定到 NUMA node 之後，相應的 storage.block-cache.capacity 沒調整，導緻 TiKV 出現 OOM 。假設一個 numa node 綁定一個 TiKV 執行個體，則單個 TiKV 執行個體的 storage.block-cache.capacity 配置應當小于 (伺服器總記憶體* 0.6) / numa node 個數，否則 TiKV 可能出現 OOM 問題，影響測試結果。
• raft store cpu 使用率高 v6.0.0 版本相比 v5.1.4 版本，raft store cpu 和 async apply cpu 的使用率要高點，建議線上使用時可以根據實際情況調整 raftstore.store-pool-size 和 raftstore.apply-pool-size 的個數，避免達到瓶頸，影響性能。

6.2 測試建議

• 強烈建議 TiDB、PD、TiKV 綁 Numa，壓測期間遇到過不綁 Numa 和綁 Numa 相差 5 倍以上的 TPS，在相同并發壓測線程數下。
• 注意分析監控、保留監控，便于對比分析性能瓶頸。
• 建議先看一遍本文參考文檔中的幾位大佬寫的文章，受益匪淺。

7. 測試小結

測試場景	v6.0.0 相比 v5.1.4 提升百分比
oltp point select	5.06%
oltp update non index	1.72%
oltp update index	4.50%
oltp read write	2.67%

本次測試對比了 TiDB v6.0.0 和 v5.1.4 在 OLTP 場景下的 Sysbench 性能表現。結果顯示，相比于 v5.1.4，v6.0.0 在 oltp_read_write、oltp_point_select、oltp_update_index 和 oltp_update_non_index 幾種場景性能均有提升，具體内容可以參考上述表格，v6.0.0 版本還是很值得我們期待的。

本文主要測試了在相同硬體和配置下 v6.0.0 和 v5.1.4 的性能，不代表最佳性能實踐和部署。