diff --git a/benchmark/benchmark-sysbench-v5-vs-v4.md b/benchmark/benchmark-sysbench-v5-vs-v4.md deleted file mode 100644 index 12cae52e7780..000000000000 --- a/benchmark/benchmark-sysbench-v5-vs-v4.md +++ /dev/null @@ -1,223 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v5.0 对比 v4.0 -summary: TiDB v5.0 在 OLTP 场景下的性能测试结果显示，Point Select 性能提升了 2.7%，Update Non-index 性能提升了 81%，Update Index 性能提升了 28%，Read Write 性能提升了 9%。这表明在 AWS EC2 环境下，TiDB v5.0 相对于 v4.0 在各项性能指标上都有所提升。 ---- - -# TiDB Sysbench 性能对比测试报告 - v5.0 对比 v4.0 - -## 测试目的 - -测试对比 TiDB v5.0 和 v4.0 在 OLTP 场景下的性能。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | 4.0、5.0 | -| TiDB | 4.0、5.0 | -| TiKV | 4.0、5.0 | -| Sysbench | 1.0.20 | - -### 参数配置 - -#### TiDB v4.0 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV v4.0 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 3 -raftdb.max-background-jobs: 3 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -``` - -#### TiDB v5.0 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV v5.0 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -server.enable-request-batch: false -``` - -#### TiDB v4.0 全局变量配置 - -{{< copyable "sql" >}} - -```sql -set global tidb_hashagg_final_concurrency=1; -set global tidb_hashagg_partial_concurrency=1; -``` - -#### TiDB v5.0 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; - -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.0 和 v4.0。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 AWS NLB 向 TiDB 加压，单轮预热 1 分钟，测试 5 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=300 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v4.0 QPS | v4.0 95% latency (ms) | v5.0 QPS | v5.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -| 150 | 159451.19 | 1.32 | 177876.25 | 1.23 | 11.56% | -| 300 | 244790.38 | 1.96 | 252675.03 | 1.82 | 3.22% | -| 600 | 322929.05 | 3.75 | 331956.84 | 3.36 | 2.80% | -| 900 | 364840.05 | 5.67 | 365655.04 | 5.09 | 0.22% | -| 1200 | 376529.18 | 7.98 | 366507.47 | 7.04 | -2.66% | -| 1500 | 368390.52 | 10.84 | 372476.35 | 8.90 | 1.11% | - -v5.0 对比 v4.0，Point Select 性能提升了 2.7%。 - -![Point Select](/media/sysbench_v5vsv4_point_select.png) - -### Update Non-index 性能 - -| Threads | v4.0 QPS | v4.0 95% latency (ms) | v5.0 QPS | v5.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -| 150 | 17243.78 | 11.04 | 30866.23 | 6.91 | 79.00% | -| 300 | 25397.06 | 15.83 | 45915.39 | 9.73 | 80.79% | -| 600 | 33388.08 | 25.28 | 60098.52 | 16.41 | 80.00% | -| 900 | 38291.75 | 36.89 | 70317.41 | 21.89 | 83.64% | -| 1200 | 41003.46 | 55.82 | 76376.22 | 28.67 | 86.27% | -| 1500 | 44702.84 | 62.19 | 80234.58 | 34.95 | 79.48% | - -v5.0 对比 v4.0，Update Non-index 性能提升了 81%。 - -![Update Non-index](/media/sysbench_v5vsv4_update_non_index.png) - -### Update Index 性能 - -| Threads | v4.0 QPS | v4.0 95% latency (ms) | v5.0 QPS | v5.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -| 150 | 11736.21 | 17.01 | 15631.34 | 17.01 | 33.19% | -| 300 | 15435.95 | 28.67 | 19957.06 | 22.69 | 29.29% | -| 600 | 18983.21 | 49.21 | 23218.14 | 41.85 | 22.31% | -| 900 | 20855.29 | 74.46 | 26226.76 | 53.85 | 25.76% | -| 1200 | 21887.64 | 102.97 | 28505.41 | 69.29 | 30.24% | -| 1500 | 23621.15 | 110.66 | 30341.06 | 82.96 | 28.45% | - -v5.0 对比 v4.0，Update Index 性能提升了 28%。 - -![Update Index](/media/sysbench_v5vsv4_update_index.png) - -### Read Write 性能 - -| Threads | v4.0 QPS | v4.0 95% latency (ms) | v5.0 QPS | v5.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -| 150 | 59979.91 | 61.08 | 66098.57 | 55.82 | 10.20% | -| 300 | 77118.32 | 102.97 | 84639.48 | 90.78 | 9.75% | -| 600 | 90619.52 | 183.21 | 101477.46 | 167.44 | 11.98% | -| 900 | 97085.57 | 267.41 | 109463.46 | 240.02 | 12.75% | -| 1200 | 106521.61 | 331.91 | 115416.05 | 320.17 | 8.35% | -| 1500 | 116278.96 | 363.18 | 118807.5 | 411.96 | 2.17% | - -v5.0 对比 v4.0，Read Write 性能提升了 9%。 - -![Read Write](/media/sysbench_v5vsv4_read_write.png) diff --git a/benchmark/benchmark-sysbench-v5.1.0-vs-v5.0.2.md b/benchmark/benchmark-sysbench-v5.1.0-vs-v5.0.2.md deleted file mode 100644 index a45240256eb9..000000000000 --- a/benchmark/benchmark-sysbench-v5.1.0-vs-v5.0.2.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v5.1.0 对比 v5.0.2 -summary: TiDB v5.1.0 在 OLTP 场景下的 Sysbench 性能表现对比 v5.0.2。Point Select 性能提升了 19.4%，Read Write 和 Update Index 性能略有下降。测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 Sysbench。软件版本为 v5.0.2、v5.1.0。参数配置相同。测试方案包括部署、数据准备和执行测试。测试结果显示各场景性能对比情况。 ---- - -# TiDB Sysbench 性能对比测试报告 - v5.1.0 对比 v5.0.2 - -## 测试概况 - -本次测试对比了 TiDB v5.1.0 和 v5.0.2 在 OLTP 场景下的 Sysbench 性能表现。结果显示，v5.1.0 相比于 v5.0.2，Point Select 场景性能提升了 19.4%，Read Write 和 Update Index 场景性能略有下降。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.0.2、v5.1.0 | -| TiDB | v5.0.2、v5.1.0 | -| TiKV | v5.0.2、v5.1.0 | -| Sysbench | 1.0.20 | - -### 参数配置 - -两个版本使用相同的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -server.enable-request-batch: false -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; - -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.1.0 和 v5.0.2。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，测试 5 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=300 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v5.0.2 QPS | v5.0.2 95% latency (ms) | v5.1.0 QPS | v5.1.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|137732.27|1.86|158861.67|2|15.34%| -|300|201420.58|2.91|238038.44|2.71|18.18%| -|600|303631.52|3.49|428573.21|2.07|41.15%| -|900|383628.13|3.55|464863.22|3.89|21.18%| -|1200|391451.54|5.28|413656.74|13.46|5.67%| -|1500|410276.93|7.43|471418.78|10.65|14.90%| - -v5.1.0 对比 v5.0.2，Point Select 性能提升了 19.4%。 - -![Point Select](/media/sysbench_v510vsv502_point_select.png) - -### Update Non-index 性能 - -| Threads | v5.0.2 QPS | v5.0.2 95% latency (ms) | v5.1.0 QPS | v5.1.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|29248.2|7.17|29362.7|8.13|0.39%| -|300|40316.09|12.52|39651.52|13.7|-1.65%| -|600|51011.11|22.28|47047.9|27.66|-7.77%| -|900|58814.16|27.66|59331.84|28.67|0.88%| -|1200|65286.52|32.53|67745.39|31.37|3.77%| -|1500|68300.86|39.65|67899.17|44.17|-0.59%| - -v5.1.0 对比 v5.0.2，Update Non-index 性能下降了 0.8%。 - -![Update Non-index](/media/sysbench_v510vsv502_update_non_index.png) - -### Update Index 性能 - -| Threads | v5.0.2 QPS | v5.0.2 95% latency (ms) | v5.1.0 QPS | v5.1.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|15066.54|14.73|14829.31|14.73|-1.57%| -|300|18535.92|24.83|17401.01|29.72|-6.12%| -|600|22862.73|41.1|21923.78|44.98|-4.11%| -|900|25286.74|57.87|24916.76|58.92|-1.46%| -|1200|27566.18|70.55|27800.62|69.29|0.85%| -|1500|28184.76|92.42|28679.72|86|1.76%| - -v5.1.0 对比 v5.0.2，Update Index 性能下降了 1.8%。 - -![Update Index](/media/sysbench_v510vsv502_update_index.png) - -### Read Write 性能 - -| Threads | v5.0.2 QPS | v5.0.2 95% latency (ms) | v5.1.0 QPS | v5.1.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|66415.33|56.84|66591.49|57.87|0.27%| -|300|82488.39|97.55|81226.41|101.13|-1.53%| -|600|99195.36|173.58|97357.86|179.94|-1.85%| -|900|107382.76|253.35|101665.95|267.41|-5.32%| -|1200|112389.23|337.94|107426.41|350.33|-4.42%| -|1500|113548.73|450.77|109805.26|442.73|-3.30%| - -v5.1.0 对比 v5.0.2，Read Write 性能下降了 2.7%。 - -![Read Write](/media/sysbench_v510vsv502_read_write.png) diff --git a/benchmark/benchmark-sysbench-v5.2.0-vs-v5.1.1.md b/benchmark/benchmark-sysbench-v5.2.0-vs-v5.1.1.md deleted file mode 100644 index e7c4769ac2fe..000000000000 --- a/benchmark/benchmark-sysbench-v5.2.0-vs-v5.1.1.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v5.2.0 对比 v5.1.1 -summary: TiDB v5.2.0 在 OLTP 场景下的 Sysbench 性能对比测试显示，Point Select 性能提升了 11.03%，但其余场景性能略有下降。硬件配置为 PD m5.xlarge 3 台、TiKV i3.4xlarge 3 台、TiDB c5.4xlarge 3 台、Sysbench c5.9xlarge 1 台。软件版本为 PD v5.1.1、v5.2.0、TiDB v5.1.1、v5.2.0、TiKV v5.1.1、v5.2.0、Sysbench 1.1.0-ead2689。测试方案包括数据准备、执行测试命令和测试结果。Point Select 性能提升 11.03%，Update Non-index 性能下降 1.98%，Update Index 性能下降 4.33%，Read Write 性能下降 1.24%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v5.2.0 对比 v5.1.1 - -## 测试概况 - -本次测试对比了 TiDB v5.2.0 和 v5.1.1 在 OLTP 场景下的 Sysbench 性能表现。结果显示，v5.2.0 相比于 v5.1.1，Point Select 场景性能提升了 11.03%，其余场景性能略有下降。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.1.1、v5.2.0 | -| TiDB | v5.1.1、v5.2.0 | -| TiKV | v5.1.1、v5.2.0 | -| Sysbench | 1.1.0-ead2689 | - -### 参数配置 - -两个版本使用相同的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -server.enable-request-batch: false -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; - -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.2.0 和 v5.1.1。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，测试 5 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=300 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v5.1.1 QPS | v5.1.1 95% latency (ms) | v5.2.0 QPS | v5.2.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|143014.13|2.35|174402.5|1.23|21.95%| -|300|199133.06|3.68|272018|1.64|36.60%| -|600|389391.65|2.18|393536.4|2.11|1.06%| -|900|468338.82|2.97|447981.98|3.3|-4.35%| -|1200|448348.52|5.18|468241.29|4.65|4.44%| -|1500|454376.79|7.04|483888.42|6.09|6.49%| - -v5.2.0 对比 v5.1.1，Point Select 性能提升了 11.03%。 - -![Point Select](/media/sysbench_v511vsv520_point_select.png) - -### Update Non-index 性能 - -| Threads | v5.1.1 QPS | v5.1.1 95% latency (ms) | v5.2.0 QPS | v5.2.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|31198.68|6.43|30714.73|6.09|-1.55%| -|300|43577.15|10.46|42997.92|9.73|-1.33%| -|600|57230.18|17.32|56168.81|16.71|-1.85%| -|900|65325.11|23.1|64098.04|22.69|-1.88%| -|1200|71528.26|28.67|69908.15|28.67|-2.26%| -|1500|76652.5|33.12|74371.79|33.72|-2.98%| - -v5.2.0 对比 v5.1.1，Update Non-index 性能下降了 1.98%。 - -![Update Non-index](/media/sysbench_v511vsv520_update_non_index.png) - -### Update Index 性能 - -| Threads | v5.1.1 QPS | v5.1.1 95% latency (ms) | v5.2.0 QPS | v5.2.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|15641.04|13.22|15320|13.46|-2.05%| -|300|19787.73|21.89|19161.35|22.69|-3.17%| -|600|24566.74|36.89|23616.07|38.94|-3.87%| -|900|27516.57|50.11|26270.04|54.83|-4.53%| -|1200|29421.10|63.32|28002.65|69.29|-4.82%| -|1500|30957.84|77.19|28624.44|95.81|-7.54%| - -v5.2.0 对比 v5.1.1，Update Index 性能下降了 4.33%。 - -![Update Index](/media/sysbench_v511vsv520_update_index.png) - -### Read Write 性能 - -| Threads | v5.1.1 QPS | v5.1.1 95% latency (ms) | v5.2.0 QPS | v5.2.0 95% latency (ms) | QPS 提升 | -|:----------|:----------|:----------|:----------|:----------|:----------| -|150|68471.02|57.87|69246|54.83|1.13%| -|300|86573.09|97.55|85340.42|94.10|-1.42%| -|600|101760.75|176.73|102221.31|173.58|0.45%| -|900|111877.55|248.83|109276.45|257.95|-2.32%| -|1200|117479.4|337.94|114231.33|344.08|-2.76%| -|1500|119662.91|419.45|116663.28|434.83|-2.51%| - -v5.2.0 对比 v5.1.1，Read Write 性能下降了 1.24%。 - -![Read Write](/media/sysbench_v511vsv520_read_write.png) diff --git a/benchmark/benchmark-sysbench-v5.3.0-vs-v5.2.2.md b/benchmark/benchmark-sysbench-v5.3.0-vs-v5.2.2.md deleted file mode 100644 index 6ab0cb0d16d2..000000000000 --- a/benchmark/benchmark-sysbench-v5.3.0-vs-v5.2.2.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v5.3.0 对比 v5.2.2 -summary: TiDB v5.3.0 和 v5.2.2 在 OLTP 场景下的 Sysbench 性能对比测试结果显示，v5.3.0 相比于 v5.2.2，性能基本持平。具体测试结果如下：Point Select 性能：v5.3.0 略下降了 0.81%、Update Non-index 性能：v5.3.0 略上升了 0.95%、Update Index 性能：v5.3.0 略上升了 1.83%、Read Write 性能：v5.3.0 略下降了 0.62%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v5.3.0 对比 v5.2.2 - -## 测试概况 - -本次测试对比了 TiDB v5.3.0 和 v5.2.2 在 OLTP 场景下的 Sysbench 性能表现。结果显示，v5.3.0 相比于 v5.2.2，性能基本持平。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.2.2、v5.3.0 | -| TiDB | v5.2.2、v5.3.0 | -| TiKV | v5.2.2、v5.3.0 | -| Sysbench | 1.1.0-ead2689 | - -### 参数配置 - -两个版本使用相同的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限，从而提高安全性。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance roundrobin # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.3.0 和 v5.2.2。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，每种负载每个并发数各测试 20 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=1200 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v5.2.2 TPS | v5.3.0 TPS | v5.2.2 95% latency (ms) | v5.3.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|267673.17|267516.77|1.76|1.67|-0.06| -|600|369820.29|361672.56|2.91|2.97|-2.20| -|900|417143.31|416479.47|4.1|4.18|-0.16| - -v5.3.0 对比 v5.2.2，Point Select 性能基本持平，略下降了 0.81%。 - -![Point Select](/media/sysbench_v522vsv530_point_select.png) - -### Update Non-index 性能 - -| Threads | v5.2.2 TPS | v5.3.0 TPS | v5.2.2 95% latency (ms) | v5.3.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|39715.31|40041.03|11.87|12.08|0.82| -|600|50239.42|51110.04|20.74|20.37|1.73| -|900|57073.97|57252.74|28.16|27.66|0.31| - -v5.3.0 对比 v5.2.2，Update Non-index 性能基本持平，略上升了 0.95%。 - -![Update Non-index](/media/sysbench_v522vsv530_update_non_index.png) - -### Update Index 性能 - -| Threads | v5.2.2 TPS | v5.3.0 TPS | v5.2.2 95% latency (ms) | v5.3.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|17634.03|17821.1|25.74|25.74|1.06| -|600|20998.59|21534.13|46.63|45.79|2.55| -|900|23420.75|23859.64|64.47|62.19|1.87| - -v5.3.0 对比 v5.2.2，Update Index 性能基本持平，略上升了 1.83%。 - -![Update Index](/media/sysbench_v522vsv530_update_index.png) - -### Read Write 性能 - -| Threads | v5.2.2 TPS | v5.3.0 TPS | v5.2.2 95% latency (ms) | v5.3.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|3872.01|3848.63|106.75|106.75|-0.60| -|600|4514.17|4471.77|200.47|196.89|-0.94| -|900|4877.05|4861.45|287.38|282.25|-0.32| - -v5.3.0 对比 v5.2.2，Read Write 性能基本持平，略下降了 0.62%。 - -![Read Write](/media/sysbench_v522vsv530_read_write.png) diff --git a/benchmark/benchmark-sysbench-v5.4.0-vs-v5.3.0.md b/benchmark/benchmark-sysbench-v5.4.0-vs-v5.3.0.md deleted file mode 100644 index edf021fb5224..000000000000 --- a/benchmark/benchmark-sysbench-v5.4.0-vs-v5.3.0.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v5.4.0 对比 v5.3.0 -summary: TiDB v5.4.0 在 OLTP 场景下的 Sysbench 性能比 v5.3.0 有所提升，其中写负载性能提升了 2.59% ~ 4.85%。测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 Sysbench 实例。两个版本使用相同的配置，通过 TiUP 部署。测试结果显示 Point Select 性能基本持平，Update Non-index 性能提升了 2.59%，Update Index 性能提升了 4.85%，Read Write 性能提升了 3.30%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v5.4.0 对比 v5.3.0 - -## 测试概况 - -本次测试对比了 TiDB v5.4.0 和 v5.3.0 在 OLTP 场景下的 Sysbench 性能表现。结果显示，相比于 v5.3.0，v5.4.0 的写负载 (Write-heavy Workload) 性能有 2.59% ~ 4.85% 的提升。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.3.0、v5.4.0 | -| TiDB | v5.3.0、v5.4.0 | -| TiKV | v5.3.0、v5.4.0 | -| Sysbench | 1.1.0-ead2689 | - -### 参数配置 - -两个版本使用相同的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.unified.min-thread-count: 5 -readpool.unified.max-thread-count: 20 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限，从而提高安全性。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance roundrobin # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.4.0 和 v5.3.0。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，每种负载每个并发数各测试 20 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=1200 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v5.3.0 TPS | v5.4.0 TPS | v5.3.0 95% latency (ms) | v5.4.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|266041.84|264345.73|1.96|2.07|-0.64| -|600|351782.71|348715.98|3.43|3.49|-0.87| -|900|386553.31|399777.11|5.09|4.74|3.42| - -v5.4.0 对比 v5.3.0，Point Select 性能基本持平，略提升了 0.64%。 - -![Point Select](/media/sysbench_v530vsv540_point_select.png) - -### Update Non-index 性能 - -| Threads | v5.3.0 TPS | v5.4.0 TPS | v5.3.0 95% latency (ms) | v5.4.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|40804.31|41187.1|11.87|11.87|0.94| -|600|51239.4|53172.03|20.74|19.65|3.77| -|900|57897.56|59666.8|27.66|27.66|3.06| - -v5.4.0 对比 v5.3.0，Update Non-index 性能提升了 2.59%。 - -![Update Non-index](/media/sysbench_v530vsv540_update_non_index.png) - -### Update Index 性能 - -| Threads | v5.3.0 TPS | v5.4.0 TPS | v5.3.0 95% latency (ms) | v5.4.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|17737.82|18716.5|26.2|24.83|5.52| -|600|21614.39|22670.74|44.98|42.61|4.89| -|900|23933.7|24922.05|62.19|61.08|4.13| - -v5.4.0 对比 v5.3.0，Update Index 性能提升了 4.85%。 - -![Update Index](/media/sysbench_v530vsv540_update_index.png) - -### Read Write 性能 - -| Threads | v5.3.0 TPS | v5.4.0 TPS | v5.3.0 95% latency (ms) | v5.4.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|3810.78|3929.29|108.68|106.75|3.11| -|600|4514.28|4684.64|193.38|186.54|3.77| -|900|4842.49|4988.49|282.25|277.21|3.01| - -v5.4.0 对比 v5.3.0，Read Write 性能提升了 3.30%。 - -![Read Write](/media/sysbench_v530vsv540_read_write.png) diff --git a/benchmark/benchmark-sysbench-v6.0.0-vs-v5.4.0.md b/benchmark/benchmark-sysbench-v6.0.0-vs-v5.4.0.md deleted file mode 100644 index 4a9ea0df0ebc..000000000000 --- a/benchmark/benchmark-sysbench-v6.0.0-vs-v5.4.0.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v6.0.0 对比 v5.4.0 -summary: TiDB v6.0.0 在 OLTP 场景下的 Sysbench 性能表现对比 v5.4.0。结果显示，Read Write 负载性能有大幅提升，提升了 16.17%，其他负载性能基本持平。测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 Sysbench 实例。软件版本为 v5.4.0 和 v6.0.0，参数配置相同。测试方案包括部署 TiDB、导入数据、执行测试命令和备份数据。测试结果显示 Point Select 性能基本持平，Update Non-index 性能基本持平，Update Index 性能下降了 3.05%。Update Index 性能下降了 3.05%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v6.0.0 对比 v5.4.0 - -## 测试概况 - -本次测试对比了 TiDB v6.0.0 和 v5.4.0 在 OLTP 场景下的 Sysbench 性能表现。结果显示，相比于 v5.4.0，v6.0.0 的 Read Write 负载性能有大幅提升，提升了 16.17%。其他负载性能基本与 v5.4.0 的持平。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.4.0、v6.0.0 | -| TiDB | v5.4.0、v6.0.0 | -| TiKV | v5.4.0、v6.0.0 | -| Sysbench | 1.1.0-df89d34 | - -### 参数配置 - -两个版本使用相同的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -raftdb.max-background-jobs: 4 -raftdb.allow-concurrent-memtable-write: true -server.grpc-concurrency: 6 -readpool.storage.normal-concurrency: 10 -pessimistic-txn.pipelined: true -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.0.0 和 v5.4.0。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，每种负载每个并发数各测试 20 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=1200 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v5.4.0 TPS | v6.0.0 TPS | v5.4.0 95% latency (ms) | v6.0.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|260085.19|265207.73|1.82|1.93|1.97| -|600|378098.48|365173.66|2.48|2.61|-3.42| -|900|441294.61|424031.23|3.75|3.49|-3.91| - -v6.0.0 对比 v5.4.0，Point Select 性能基本持平，略下降了 1.79%。 - -![Point Select](/media/sysbench_v540vsv600_point_select.png) - -### Update Non-index 性能 - -| Threads | v5.4.0 TPS | v6.0.0 TPS | v5.4.0 95% latency (ms) | v6.0.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|41528.7|40814.23|11.65|11.45|-1.72| -|600|53220.96|51746.21|19.29|20.74|-2.77| -|900|59977.58|59095.34|26.68|28.16|-1.47| - -v6.0.0 对比 v5.4.0，Update Non-index 性能基本持平，略下降了 1.98%。 - -![Update Non-index](/media/sysbench_v540vsv600_update_non_index.png) - -### Update Index 性能 - -| Threads | v5.4.0 TPS | v6.0.0 TPS | v5.4.0 95% latency (ms) | v6.0.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|18659.11|18187.54|23.95|25.74|-2.53| -|600|23195.83|22270.81|40.37|44.17|-3.99| -|900|25798.31|25118.78|56.84|57.87|-2.63| - -v6.0.0 对比 v5.4.0，Update Index 性能下降了 3.05%。 - -![Update Index](/media/sysbench_v540vsv600_update_index.png) - -### Read Write 性能 - -| Threads | v5.4.0 TPS | v6.0.0 TPS | v5.4.0 95% latency (ms) | v6.0.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|4141.72|4829.01|97.55|82.96|16.59| -|600|4892.76|5693.12|173.58|153.02|16.36| -|900|5217.94|6029.95|257.95|235.74|15.56| - -v6.0.0 对比 v5.4.0，Read Write 性能有大幅提升，提升了 16.17%。 - -![Read Write](/media/sysbench_v540vsv600_read_write.png) diff --git a/benchmark/benchmark-sysbench-v6.1.0-vs-v6.0.0.md b/benchmark/benchmark-sysbench-v6.1.0-vs-v6.0.0.md deleted file mode 100644 index 3b8953af1e02..000000000000 --- a/benchmark/benchmark-sysbench-v6.1.0-vs-v6.0.0.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v6.1.0 对比 v6.0.0 -summary: TiDB v6.1.0 在 OLTP 场景下的 Sysbench 性能表现优于 v6.0.0。写性能有提升，Write-heavy 负载性能提升了 2.33% 到 4.61%。Point Select 性能基本持平，略下降了 2.1%。Update Non-index 性能提升了 3.88%。Update Index 性能提升了 4.61%。Read Write 性能提升了 2.23%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v6.1.0 对比 v6.0.0 - -## 测试概况 - -本次测试对比了 TiDB v6.1.0 和 v6.0.0 在 OLTP 场景下的 Sysbench 性能表现。结果显示，相比于 v6.0.0，v6.1.0 的写性能有提升，Write-heavy 负载性能有 2.33% 到 4.61% 的提升。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| Sysbench | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v6.0.0、v6.1.0 | -| TiDB | v6.0.0、v6.1.0 | -| TiKV | v6.0.0、v6.1.0 | -| Sysbench | 1.1.0-df89d34 | - -### 参数配置 - -两个版本使用相同的配置。 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -readpool.storage.normal-concurrency: 10 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -set global tidb_prepared_plan_cache_size=1000; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.1.0 和 v6.0.0。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，每种负载每个并发数各测试 20 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=1200 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v6.0.0 TPS | v6.1.0 TPS | v6.0.0 95% latency (ms) | v6.1.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|268934.84|265353.15|1.89|1.96|-1.33| -|600|365217.96|358976.94|2.57|2.66|-1.71| -|900|420799.64|407625.11|3.68|3.82|-3.13| - -v6.1.0 对比 v6.0.0，Point Select 性能基本持平，略下降了 2.1%。 - -![Point Select](/media/sysbench_v600vsv610_point_select.png) - -### Update Non-index 性能 - -| Threads | v6.0.0 TPS | v6.1.0 TPS | v6.0.0 95% latency (ms) | v6.1.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|41778.95|42991.9|11.24|11.45|2.90 | -|600|52045.39|54099.58|20.74|20.37|3.95| -|900|59243.35|62084.65|27.66|26.68|4.80| - -v6.1.0 对比 v6.0.0，Update Non-index 性能提升了 3.88%。 - -![Update Non-index](/media/sysbench_v600vsv610_update_non_index.png) - -### Update Index 性能 - -| Threads | v6.0.0 TPS | v6.1.0 TPS | v6.0.0 95% latency (ms) | v6.1.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|18085.79|19198.89|25.28|23.95|6.15| -|600|22210.8|22877.58|42.61|41.85|3.00| -|900|25249.81|26431.12|55.82|53.85|4.68| - -v6.1.0 对比 v6.0.0，Update Index 性能提升 4.61%。 - -![Update Index](/media/sysbench_v600vsv610_update_index.png) - -### Read Write 性能 - -| Threads | v6.0.0 TPS | v6.1.0 TPS | v6.0.0 95% latency (ms) | v6.1.0 95% latency (ms) | TPS 提升 (%) | -|:----------|:----------|:----------|:----------|:----------|:----------| -|300|4856.23|4914.11|84.47|82.96|1.19| -|600|5676.46|5848.09|161.51|150.29|3.02| -|900|6072.97|6223.95|240.02|223.34|2.49| - -v6.1.0 对比 v6.0.0，Read Write 性能提升了 2.23%。 - -![Read Write](/media/sysbench_v600vsv610_read_write.png) diff --git a/benchmark/benchmark-sysbench-v6.2.0-vs-v6.1.0.md b/benchmark/benchmark-sysbench-v6.2.0-vs-v6.1.0.md deleted file mode 100644 index 37c4b5ae941f..000000000000 --- a/benchmark/benchmark-sysbench-v6.2.0-vs-v6.1.0.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -title: TiDB Sysbench 性能对比测试报告 - v6.2.0 对比 v6.1.0 -summary: TiDB v6.2.0 和 v6.1.0 在 OLTP 场景下的 Sysbench 性能对比测试结果显示，两个版本性能基本持平。然而，v6.2.0 的 Point Select 性能下降了 3.58%，而 Update Non-index、Update Index 和 Read Write 性能基本持平或下降了不到 1.5%。 ---- - -# TiDB Sysbench 性能对比测试报告 - v6.2.0 对比 v6.1.0 - -## 测试概况 - -本次测试对比了 TiDB v6.2.0 和 v6.1.0 在 OLTP 场景下的 Sysbench 性能表现。结果显示，两个版本性能基本持平，相比于 v6.1.0，v6.2.0 的 Point Select 性能下降了 3.58%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -| :------- | :--------- | :----- | -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge | 3 | -| TiDB | c5.4xlarge | 3 | -| Sysbench | c5.9xlarge | 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -| :------- | :------------- | -| PD | v6.1.0、v6.2.0 | -| TiDB | v6.1.0、v6.2.0 | -| TiKV | v6.1.0、v6.2.0 | -| Sysbench | 1.1.0-df89d34 | - -### 参数配置 - -两个版本使用相同的配置。 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -storage.scheduler-worker-pool-size: 5 -raftstore.store-pool-size: 3 -raftstore.apply-pool-size: 3 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -readpool.unified.max-thread-count: 10 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -set global tidb_prepared_plan_cache_size=1000; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.2.0 和 v6.1.0。 -2. 通过 Sysbench 导入 16 张表，每张表有 1000 万行数据。 -3. 分别对每个表执行 `analyze table` 命令。 -4. 备份数据，用于不同并发测试前进行数据恢复，以保证每次数据一致。 -5. 启动 Sysbench 客户端，进行 `point_select`、`read_write`、`update_index` 和 `update_non_index` 测试。通过 HAProxy 向 TiDB 加压，每种负载每个并发数各测试 20 分钟。 -6. 每轮完成后停止集群，使用之前的备份的数据覆盖，再启动集群。 - -### 准备测试数据 - -执行以下命令来准备测试数据： - -{{< copyable "shell-regular" >}} - -```bash -sysbench oltp_common \ - --threads=16 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - --mysql-user=root \ - --mysql-password=password \ - prepare --tables=16 --table-size=10000000 -``` - -### 执行测试命令 - -执行以下命令来执行测试： - -{{< copyable "shell-regular" >}} - -```bash -sysbench $testname \ - --threads=$threads \ - --time=1200 \ - --report-interval=1 \ - --rand-type=uniform \ - --db-driver=mysql \ - --mysql-db=sbtest \ - --mysql-host=$aws_nlb_host \ - --mysql-port=$aws_nlb_port \ - run --tables=16 --table-size=10000000 -``` - -## 测试结果 - -### Point Select 性能 - -| Threads | v6.1.0 TPS | v6.2.0 TPS | v6.1.0 95% latency (ms) | v6.2.0 95% latency (ms) | TPS 提升 (%) | -| :------ | :--------- | :--------- | :---------------------- | :---------------------- | :----------- | -| 300 | 243530.01 | 236885.24 | 1.93 | 2.07 | -2.73 | -| 600 | 304121.47 | 291395.84 | 3.68 | 4.03 | -4.18 | -| 900 | 327301.23 | 314720.02 | 5 | 5.47 | -3.84 | - -v6.2.0 对比 v6.1.0，Point Select 性能下降了 3.58%。 - -![Point Select](/media/sysbench_v610vsv620_point_select.png) - -### Update Non-index 性能 - -| Threads | v6.1.0 TPS | v6.2.0 TPS | v6.1.0 95% latency (ms) | v6.2.0 95% latency (ms) | TPS 提升 (%) | -| :------ | :--------- | :--------- | :---------------------- | :---------------------- | :----------- | -| 300 | 42608.8 | 42372.82 | 11.45 | 11.24 | -0.55 | -| 600 | 54264.47 | 53672.69 | 18.95 | 18.95 | -1.09 | -| 900 | 60667.47 | 60116.14 | 26.2 | 26.68 | -0.91 | - -v6.2.0 对比 v6.1.0，Update Non-index 性能基本持平，下降了 0.85%。 - -![Update Non-index](/media/sysbench_v610vsv620_update_non_index.png) - -### Update Index 性能 - -| Threads | v6.1.0 TPS | v6.2.0 TPS | v6.1.0 95% latency (ms) | v6.2.0 95% latency (ms) | TPS 提升 (%) | -| :------ | :--------- | :--------- | :---------------------- | :---------------------- | :----------- | -| 300 | 19384.75 | 19353.58 | 23.52 | 23.52 | -0.16 | -| 600 | 24144.78 | 24007.57 | 38.25 | 37.56 | -0.57 | -| 900 | 26770.9 | 26589.84 | 51.94 | 52.89 | -0.68 | - -v6.2.0 对比 v6.1.0，Update Index 性能基本持平，下降了 0.47%。 - -![Update Index](/media/sysbench_v610vsv620_update_index.png) - -### Read Write 性能 - -| Threads | v6.1.0 TPS | v6.2.0 TPS | v6.1.0 95% latency (ms) | v6.2.0 95% latency (ms) | TPS 提升 (%) | -| :------ | :--------- | :--------- | :---------------------- | :---------------------- | :----------- | -| 300 | 4849.67 | 4797.59 | 86 | 84.47 | -1.07 | -| 600 | 5643.89 | 5565.17 | 161.51 | 161.51 | -1.39 | -| 900 | 5954.91 | 5885.22 | 235.74 | 235.74 | -1.17 | - -v6.2.0 对比 v6.1.0，Read Write 性能下降了 1.21%。 - -![Read Write](/media/sysbench_v610vsv620_read_write.png) diff --git a/benchmark/v5.0-performance-benchmarking-with-tpcc.md b/benchmark/v5.0-performance-benchmarking-with-tpcc.md deleted file mode 100644 index aef70a124bd0..000000000000 --- a/benchmark/v5.0-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v5.0 对比 v4.0 -summary: TiDB v5.0 在 TPC-C 性能上提升了 36%，比 v4.0 更优。 ---- - -# TiDB TPC-C 性能对比测试报告 - v5.0 对比 v4.0 - -## 测试目的 - -测试对比 TiDB v5.0 和 v4.0 OLTP 场景下的性能。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | 4.0、5.0 | -| TiDB | 4.0、5.0 | -| TiKV | 4.0、5.0 | -| BenchmarkSQL | 无 | - -### 配置参数 - -#### TiDB v4.0 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV v4.0 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -``` - -#### TiDB v5.0 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV v5.0 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -server.enable-request-batch: false -``` - -#### TiDB v4.0 全局变量配置 - -{{< copyable "sql" >}} - -```sql -set global tidb_hashagg_final_concurrency=1; -set global tidb_hashagg_partial_concurrency=1; -``` - -#### TiDB v5.0 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.0 和 v4.0。 - -2. 通过 BenchmarkSQL 导入 TPC-C 5000 Warehouse 数据。 - - 1. 编译 BenchmarkSQL： - - {{< copyable "bash" >}} - - ```bash - git clone https://github.com/pingcap/benchmarksql && cd benchmarksql && ant - ``` - - 2. 进入 `run` 目录，根据实际情况编辑 `props.mysql` 文件，调整 `conn`、`warehouses`、`loadWorkers`、`terminals`、`runMins` 配置项。 - - 3. 运行 `runSQL.sh ./props.mysql sql.mysql/tableCreates.sql` 命令。 - - 4. 运行 `runSQL.sh ./props.mysql sql.mysql/indexCreates.sql` 命令。 - - 5. 运行 MySQL client 并对每个表执行 `analyze table` 语句。 - -3. 运行 `runBenchmark.sh ./props.mysql` 命令。 - -4. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v5.0 比 v4.0 在 TPC-C 性能上**提升了 36%**。 - -![TPC-C](/media/tpcc_v5vsv4_corrected_v2.png) diff --git a/benchmark/v5.1-performance-benchmarking-with-tpcc.md b/benchmark/v5.1-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 8a523f3cf0a3..000000000000 --- a/benchmark/v5.1-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v5.1.0 对比 v5.0.2 -summary: TiDB v5.1.0 在 TPC-C 性能上提升了 2.8%，测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 TPC-C 实例，软件版本为 v5.0.2 和 v5.1.0，配置参数相同。测试方案包括部署、创建数据库、导入数据和运行压力测试，结果显示性能提升。 ---- - -# TiDB TPC-C 性能对比测试报告 - v5.1.0 对比 v5.0.2 - -## 测试概况 - -本次测试对比了 TiDB v5.1.0 和 v5.0.2 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v5.1.0 相比于 v5.0.2 在 TPC-C 性能上提升了 2.8%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.0.2、v5.1.0 | -| TiDB | v5.0.2、v5.1.0 | -| TiKV | v5.0.2、v5.1.0 | -| TiUP | 1.5.1 | - -### 配置参数 - -两个版本使用同样的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -server.enable-request-batch: false -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.1.0 和 v5.0.2。 -2. 创建数据库 tpcc：`create database tpcc;` -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -p 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 300s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v5.1.0 比 v5.0.2 在 TPC-C 性能上**提升了 2.8%**。 - -![TPC-C](/media/tpcc_v510_vs_v502.png) diff --git a/benchmark/v5.2-performance-benchmarking-with-tpcc.md b/benchmark/v5.2-performance-benchmarking-with-tpcc.md deleted file mode 100644 index f82f66b87c69..000000000000 --- a/benchmark/v5.2-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v5.2.0 对比 v5.1.1 -summary: TiDB v5.2.0 在 TPC-C 性能上下降了 4.22%，测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 TPC-C 实例，软件版本为 v5.1.1 和 v5.2.0，配置参数相同。测试方案包括部署、创建数据库、导入数据和运行压力测试，结果显示性能下降。 ---- - -# TiDB TPC-C 性能对比测试报告 - v5.2.0 对比 v5.1.1 - -## 测试概况 - -本次测试对比了 TiDB v5.2.0 和 v5.1.1 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v5.2.0 相比于 v5.1.1 在 TPC-C 性能上下降了 4.22%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.1.1、v5.2.0 | -| TiDB | v5.1.1、v5.2.0 | -| TiKV | v5.1.1、v5.2.0 | -| TiUP | 1.5.1 | - -### 配置参数 - -两个版本使用同样的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -server.enable-request-batch: false -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.2.0 和 v5.1.1。 -2. 创建数据库 tpcc：`create database tpcc;` -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -p 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 300s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v5.2.0 相比 v5.1.1 在 TPC-C 性能上**下降了 4.22%**。 - -![TPC-C](/media/tpcc_v511_vs_v520.png) diff --git a/benchmark/v5.3-performance-benchmarking-with-tpcc.md b/benchmark/v5.3-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 2130833a9c44..000000000000 --- a/benchmark/v5.3-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v5.3.0 对比 v5.2.2 -summary: TiDB v5.3.0 在 TPC-C 性能上略下降了 2.99%，与 v5.2.2 相比。测试结果显示，不同线程下，v5.3.0 的 tpmC 提升率分别为 -1.54%，-2.33%，-2.99%，-5.10%。 ---- - -# TiDB TPC-C 性能对比测试报告 - v5.3.0 对比 v5.2.2 - -## 测试概况 - -本次测试对比了 TiDB v5.3.0 和 v5.2.2 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v5.3.0 相比于 v5.2.2 在 TPC-C 性能上略下降了 2.99%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.2.2、v5.3.0 | -| TiDB | v5.2.2、v5.3.0 | -| TiKV | v5.2.2、v5.3.0 | -| TiUP | 1.5.1 | - -### 配置参数 - -两个版本使用同样的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限，从而提高安全性。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance roundrobin # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.3.0 和 v5.2.2。 -2. 创建数据库 tpcc：`create database tpcc;` -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -p 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压，每个并发数各测试 30 分钟。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v5.3.0 相比 v5.2.2 在 TPC-C 性能上**略下降了 2.99%**。 - -| Threads | v5.2.2 tpmC | v5.3.0 tpmC | tpmC 提升 (%) | -|:----------|:----------|:----------|:----------| -|50|42228.8|41580|-1.54| -|100|49400|48248.2|-2.33| -|200|54436.6|52809.4|-2.99| -|400|57026.7|54117.1|-5.10| - -![TPC-C](/media/tpcc_v522_vs_v530.png) diff --git a/benchmark/v5.4-performance-benchmarking-with-tpcc.md b/benchmark/v5.4-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 3831300d64f6..000000000000 --- a/benchmark/v5.4-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v5.4.0 对比 v5.3.0 -summary: TiDB v5.4.0 在 TPC-C 性能上提升了 3.16%，测试结果显示不同并发下，性能均有提升。 ---- - -# TiDB TPC-C 性能对比测试报告 - v5.4.0 对比 v5.3.0 - -## 测试概况 - -本次测试对比了 TiDB v5.4.0 和 v5.3.0 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v5.4.0 相比于 v5.3.0 在 TPC-C 性能提升了 3.16%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.3.0、v5.4.0 | -| TiDB | v5.3.0、v5.4.0 | -| TiKV | v5.3.0、v5.4.0 | -| TiUP | 1.5.1 | - -### 配置参数 - -两个版本使用同样的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -performance.max-procs: 20 -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -readpool.unified.max-thread-count: 20 -readpool.unified.min-thread-count: 5 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -storage.scheduler-worker-pool-size: 20 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - chroot /var/lib/haproxy # 更改当前目录并为启动进程设置超级用户权限，从而提高安全性。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance roundrobin # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v5.4.0 和 v5.3.0。 -2. 创建数据库 tpcc：`create database tpcc;`。 -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -P 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压，每个并发数各测试 30 分钟。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v5.4.0 相比 v5.3.0 在 TPC-C 性能上**提升了 3.16%**。 - -| Threads | v5.3.0 tpmC | v5.4.0 tpmC | tpmC 提升 (%) | -|:----------|:----------|:----------|:----------| -|50|43002.4|44204.4|2.80| -|100|50162.7|52305|4.27| -|200|55768.2|57690.7|3.45| -|400|56836.8|58034.6|2.11| - -![TPC-C](/media/tpcc_v530_vs_v540.png) diff --git a/benchmark/v5.4-performance-benchmarking-with-tpch.md b/benchmark/v5.4-performance-benchmarking-with-tpch.md deleted file mode 100644 index f3fedd1e231c..000000000000 --- a/benchmark/v5.4-performance-benchmarking-with-tpch.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: TiDB TPC-H 性能对比测试报告 - v5.4 MPP 模式对比 Greenplum 6.15.0 以及 Apache Spark 3.1.1 -summary: TiDB v5.4 MPP 模式在 TPC-H 100 GB 数据下的性能测试结果显示，相对于 Greenplum 6.15.0 和 Apache Spark 3.1.1，有 2-3 倍的性能提升。测试环境包括 TiDB v5.4 MPP、Greenplum 6.15.0 和 Apache Spark 3.1.1 + Parquet。测试结果显示 TiDB v5.4 在各个查询中的处理时间明显低于其他两者，表现更优。 ---- - -# TiDB TPC-H 性能对比测试报告 - v5.4 MPP 模式对比 Greenplum 6.15.0 以及 Apache Spark 3.1.1 - -## 测试概况 - -本次测试对比了 TiDB v5.4 MPP 模式下和主流分析引擎例如 Greenplum 和 Apache Spark 最新版本在 TPC-H 100 GB 数据下的性能表现。结果显示，TiDB v5.4 MPP 模式下相对这些方案有 2-3 倍的性能提升。 - -TiDB v5.0 中引入的 [TiFlash](/tiflash/tiflash-overview.md) 组件的 MPP 模式大大幅增强了 TiDB HTAP 形态。本文的测试对象如下： - -+ TiDB v5.4 MPP 执行模式下的列式存储 -+ Greenplum 6.15.0 -+ Apache Spark 3.1.1 + Parquet - -## 测试环境 - -### 硬件配置 - -| 实例类型 | 实例数 | -|:----------|:----------| -| PD | 1 | -| TiDB | 1 | -| TiKV | 3 | -| TiFlash | 3 | - -+ CPU：Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz，40 核 -+ 内存：189 GB -+ 磁盘：NVMe 3TB * 2 - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| TiDB | 5.4 | -| Greenplum | 6.15.0 | -| Apache Spark | 3.1.1 | - -### 配置参数 - -#### TiDB v5.4 配置 - -v5.4 的 TiDB 集群除以下配置项外均使用默认参数配置。所有 TPC-H 测试表均以 TiFlash 列存进行同步，无额外分区和索引。 - -在 TiFlash 的 `users.toml` 配置文件中进行如下配置： - -```toml -[profiles.default] -max_memory_usage = 10000000000000 -``` - -使用 SQL 语句设置以下会话变量： - -```sql -set @@tidb_isolation_read_engines='tiflash'; -set @@tidb_allow_mpp=1; -set @@tidb_mem_quota_query = 10 << 30; -``` - -#### Greenplum 配置 - -Greenplum 集群使用额外的一台 Master 节点部署（共四台），每台 Segment Server 部署 8 Segments（每个 NVMe SSD 各 4 个），总共 24 Segments。存储格式为 append-only / 列式存储，分区键为主键。 - -{{< copyable "" >}} - -``` -log_statement = all -gp_autostats_mode = none -statement_mem = 2048MB -gp_vmem_protect_limit = 16384 -``` - -#### Apache Spark 配置 - -Apache Spark 测试使用 Apache Parquet 作为存储格式，数据存储在 HDFS 上。HDFS 为三节点，为每个节点指定两块 NVMe SSD 盘作为数据盘。通过 Standalone 方式启动 Spark 集群，使用 NVMe SSD 盘作为 `spark.local.dir` 本地目录以借助快速盘加速 Shuffle Spill 过程，无额外分区和索引。 - -{{< copyable "" >}} - -``` ---driver-memory 20G ---total-executor-cores 120 ---executor-cores 5 ---executor-memory 15G -``` - -## 测试结果 - -> **注意：** -> -> 以下测试结果均为 3 次测试的平均值，单位均为秒。 - -| Query ID | TiDB v5.4 | Greenplum 6.15.0 | Apache Spark 3.1.1 + Parquet | -| :-------- | :----------- | :------------ | :-------------- | -| 1 | 8.08 | 64.1307 | 52.64 | -| 2 | 2.53 | 4.76612 | 11.83 | -| 3 | 4.84 | 15.62898 | 13.39 | -| 4 | 10.94 | 12.88318 | 8.54 | -| 5 | 12.27 | 23.35449 | 25.23 | -| 6 | 1.32 | 6.033 | 2.21 | -| 7 | 5.91 | 12.31266 | 25.45 | -| 8 | 6.71 | 11.82444 | 23.12 | -| 9 | 44.19 | 22.40144 | 35.2 | -| 10 | 7.13 | 12.51071 | 12.18 | -| 11 | 2.18 | 2.6221 | 10.99 | -| 12 | 2.88 | 7.97906 | 6.99 | -| 13 | 6.84 | 10.15873 | 12.26 | -| 14 | 1.69 | 4.79394 | 3.89 | -| 15 | 3.29 | 10.48785 | 9.82 | -| 16 | 5.04 | 4.64262 | 6.76 | -| 17 | 11.7 | 74.65243 | 44.65 | -| 18 | 12.87 | 64.87646 | 30.27 | -| 19 | 4.75 | 8.08625 | 4.7 | -| 20 | 8.89 | 15.47016 | 8.4 | -| 21 | 24.44 | 39.08594 | 34.83 | -| 22 | 1.23 | 7.67476 | 4.59 | - -![TPC-H](/media/tidb-v5.4-tpch-100-vs-gp-spark.png) - -以上性能图中蓝色为 TiDB v5.4，红色为 Greenplum 6.15.0，黄色为 Apache Spark 3.1.1，纵坐标是查询的处理时间。纵坐标数值越低，表示 TPC-H 性能越好。 diff --git a/benchmark/v6.0-performance-benchmarking-with-tpcc.md b/benchmark/v6.0-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 033c382ddc37..000000000000 --- a/benchmark/v6.0-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v6.0.0 对比 v5.4.0 -summary: TiDB v6.0.0 在 TPC-C 性能上比 v5.4.0 提升了 24.20%，表现更好。测试环境为 AWS EC2，硬件配置包括 PD、TiKV、TiDB 和 TPC-C 实例。软件版本为 v5.4.0 和 v6.0.0，配置参数相同。测试方案包括通过 TiUP 部署 TiDB，创建数据库 tpcc，导入数据，运行压力测试，提取结果。测试结果显示 v6.0.0 在不同并发下的 tpmC 均有提升，最高达 26.97%。 ---- - -# TiDB TPC-C 性能对比测试报告 - v6.0.0 对比 v5.4.0 - -## 测试概况 - -本次测试对比了 TiDB v6.0.0 和 v5.4.0 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v6.0.0 相比于 v5.4.0 在 TPC-C 性能提升了 24.20%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v5.4.0、v6.0.0 | -| TiDB | v5.4.0、v6.0.0 | -| TiKV | v5.4.0、v6.0.0 | -| TiUP | 1.9.3 | -| HAProxy | 2.5.0 | - -### 配置参数 - -两个版本使用同样的配置 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -pessimistic-txn.pipelined: true -raftdb.allow-concurrent-memtable-write: true -raftdb.max-background-jobs: 4 -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 3 -readpool.storage.normal-concurrency: 10 -rocksdb.max-background-jobs: 8 -server.grpc-concurrency: 6 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.0.0 和 v5.4.0。 -2. 创建数据库 tpcc：`create database tpcc;`。 -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -p 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压，每个并发数各测试 30 分钟。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v6.0.0 相比 v5.4.0 在 TPC-C 性能上有大幅提升，**平均提升了 24.20%**。 - -| Threads | v5.4.0 tpmC | v6.0.0 tpmC | tpmC 提升 (%) | -|:----------|:----------|:----------|:----------| -|50|44822.8|54956.6|22.61| -|100|52150.3|66216.6|26.97| -|200|57344.9|72116.7|25.76| -|400|58675|71254.8|21.44| - -![TPC-C](/media/tpcc_v540_vs_v600.png) diff --git a/benchmark/v6.0-performance-benchmarking-with-tpch.md b/benchmark/v6.0-performance-benchmarking-with-tpch.md deleted file mode 100644 index 0d20f8c38b76..000000000000 --- a/benchmark/v6.0-performance-benchmarking-with-tpch.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: TiFlash 与 Greenplum/Spark 性能比较 -summary: TiFlash 与 Greenplum/Spark 性能进行了比较。请参考 TiDB v5.4 TPC-H 性能对比测试报告。 ---- - -# TiFlash 与 Greenplum/Spark 性能比较 - -请参考 [TiDB v5.4 TPC-H 性能对比测试报告](https://docs.pingcap.com/zh/tidb/stable/v5.4-performance-benchmarking-with-tpch)。 \ No newline at end of file diff --git a/benchmark/v6.1-performance-benchmarking-with-tpcc.md b/benchmark/v6.1-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 045caf09cc99..000000000000 --- a/benchmark/v6.1-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v6.1.0 对比 v6.0.0 -summary: TiDB v6.1.0 在 TPC-C 性能上平均提升了 2.85%，分别为：50 线程提升 2.31%，100 线程提升 2.71%，200 线程提升 3.86%，400 线程提升 2.52%。 ---- - -# TiDB TPC-C 性能对比测试报告 - v6.1.0 对比 v6.0.0 - -## 测试概况 - -本次测试对比了 TiDB v6.1.0 和 v6.0.0 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v6.1.0 相比于 v6.0.0 在 TPC-C 性能提升了 2.85%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -|:----------|:----------|:----------| -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge| 3 | -| TiDB | c5.4xlarge| 3 | -| TPC-C | c5.9xlarge| 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -|:----------|:-----------| -| PD | v6.0.0、v6.1.0 | -| TiDB | v6.0.0、v6.1.0 | -| TiKV | v6.0.0、v6.1.0 | -| TiUP | 1.9.3 | -| HAProxy | 2.5.0 | - -### 配置参数 - -两个版本使用同样的配置。 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 2 -readpool.storage.normal-concurrency: 10 -server.grpc-concurrency: 6 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -set global tidb_prepared_plan_cache_size=1000; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.1.0 和 v6.0.0。 -2. 创建数据库 tpcc：`create database tpcc;`。 -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -p 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压，每个并发数各测试 30 分钟。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v6.1.0 相比 v6.0.0 在 TPC-C 性能上**平均提升了 2.85%**。 - -| Threads | v6.0.0 tpmC | v6.1.0 tpmC | tpmC 提升 (%) | -|:----------|:----------|:----------|:----------| -|50|59059.2|60424.4|2.31| -|100|69357.6|71235.5|2.71| -|200|71364.8|74117.8|3.86| -|400|72694.3|74525.3|2.52| - -![TPC-C](/media/tpcc_v600_vs_v610.png) diff --git a/benchmark/v6.1-performance-benchmarking-with-tpch.md b/benchmark/v6.1-performance-benchmarking-with-tpch.md deleted file mode 100644 index 6533d99ced5c..000000000000 --- a/benchmark/v6.1-performance-benchmarking-with-tpch.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: TiFlash 与 Greenplum/Spark 性能比较 -summary: TiFlash 与 Greenplum/Spark 性能比较。请参考 TiDB v5.4 TPC-H 性能对比测试报告。 ---- - -# TiFlash 与 Greenplum/Spark 性能比较 - -请参考 [TiDB v5.4 TPC-H 性能对比测试报告](https://docs.pingcap.com/zh/tidb/stable/v5.4-performance-benchmarking-with-tpch)。 \ No newline at end of file diff --git a/benchmark/v6.2-performance-benchmarking-with-tpcc.md b/benchmark/v6.2-performance-benchmarking-with-tpcc.md deleted file mode 100644 index 0b83fbe7e552..000000000000 --- a/benchmark/v6.2-performance-benchmarking-with-tpcc.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: TiDB TPC-C 性能对比测试报告 - v6.2.0 对比 v6.1.0 -summary: TiDB v6.2.0 在 TPC-C 性能测试中相比 v6.1.0 下降了 2.00%，平均性能下降了 2.00%。在不同并发数下，v6.2.0 的性能都有所下降，最高下降达到 3.60%。 ---- - -# TiDB TPC-C 性能对比测试报告 - v6.2.0 对比 v6.1.0 - -## 测试概况 - -本次测试对比了 TiDB v6.2.0 和 v6.1.0 在 OLTP 场景下的 TPC-C 性能表现。结果显示，v6.2.0 相比于 v6.1.0 在 TPC-C 性能下降了 2.00%。 - -## 测试环境 (AWS EC2) - -### 硬件配置 - -| 服务类型 | EC2 类型 | 实例数 | -| :------- | :--------- | :----- | -| PD | m5.xlarge | 3 | -| TiKV | i3.4xlarge | 3 | -| TiDB | c5.4xlarge | 3 | -| TPC-C | c5.9xlarge | 1 | - -### 软件版本 - -| 服务类型 | 软件版本 | -| :------- | :------------- | -| PD | v6.1.0、v6.2.0 | -| TiDB | v6.1.0、v6.2.0 | -| TiKV | v6.1.0、v6.2.0 | -| TiUP | 1.9.3 | -| HAProxy | 2.5.0 | - -### 配置参数 - -两个版本使用同样的配置。 - -#### TiDB 参数配置 - -{{< copyable "" >}} - -```yaml -log.level: "error" -prepared-plan-cache.enabled: true -tikv-client.max-batch-wait-time: 2000000 -``` - -#### TiKV 参数配置 - -{{< copyable "" >}} - -```yaml -raftstore.apply-max-batch-size: 2048 -raftstore.apply-pool-size: 3 -raftstore.store-max-batch-size: 2048 -raftstore.store-pool-size: 2 -readpool.storage.normal-concurrency: 10 -server.grpc-concurrency: 6 -``` - -#### TiDB 全局变量配置 - -{{< copyable "sql" >}} - -```sql -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; -set global tidb_prepared_plan_cache_size=1000; -``` - -#### HAProxy 配置 - haproxy.cfg 文件 - -更多有关 HAProxy 在 TiDB 上的使用，可参阅 [HAProxy 在 TiDB 中的最佳实践](/best-practices/haproxy-best-practices.md)。 - -{{< copyable "" >}} - -```yaml -global # 全局配置。 - pidfile /var/run/haproxy.pid # 将 HAProxy 进程的 PID 写入 pidfile。 - maxconn 4000 # 每个 HAProxy 进程所接受的最大并发连接数。 - user haproxy # 同 UID 参数。 - group haproxy # 同 GID 参数，建议使用专用用户组。 - nbproc 64 # 在后台运行时创建的进程数。在启动多个进程转发请求时，确保该值足够大，保证 HAProxy 不会成为瓶颈。 - daemon # 让 HAProxy 以守护进程的方式工作于后台，等同于命令行参数“-D”的功能。当然，也可以在命令行中用“-db”参数将其禁用。 - -defaults # 默认配置。 - log global # 日志继承全局配置段的设置。 - retries 2 # 向上游服务器尝试连接的最大次数，超过此值便认为后端服务器不可用。 - timeout connect 2s # HAProxy 与后端服务器连接超时时间。如果在同一个局域网内，可设置成较短的时间。 - timeout client 30000s # 客户端与 HAProxy 连接后，数据传输完毕，即非活动连接的超时时间。 - timeout server 30000s # 服务器端非活动连接的超时时间。 - -listen tidb-cluster # 配置 database 负载均衡。 - bind 0.0.0.0:3390 # 浮动 IP 和 监听端口。 - mode tcp # HAProxy 要使用第 4 层的传输层。 - balance leastconn # 连接数最少的服务器优先接收连接。`leastconn` 建议用于长会话服务，例如 LDAP、SQL、TSE 等，而不是短会话协议，如 HTTP。该算法是动态的，对于启动慢的服务器，服务器权重会在运行中作调整。 - server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3 # 检测 4000 端口，检测频率为每 2000 毫秒一次。如果 2 次检测为成功，则认为服务器可用；如果 3 次检测为失败，则认为服务器不可用。 - server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3 - server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3 -``` - -## 测试方案 - -1. 通过 TiUP 部署 TiDB v6.2.0 和 v6.1.0。 -2. 创建数据库 tpcc：`create database tpcc;`。 -3. 通过 tiup bench 导入 TPC-C 5000 Warehouse 数据：`tiup bench tpcc prepare --warehouses 5000 --db tpcc -H 127.0.0.1 -P 4000`。 -4. 运行 `tiup bench tpcc run -U root --db tpcc --host 127.0.0.1 --port 4000 --time 1800s --warehouses 5000 --threads {{thread}}` 命令，通过 HAProxy 向 TiDB 加压，每个并发数各测试 30 分钟。 -5. 从结果中提取 New Order 的 tpmC 的数据。 - -## 测试结果 - -v6.2.0 相比 v6.1.0 在 TPC-C 性能上**平均下降了 2.00%**。 - -| Threads | v6.1.0 tpmC | v6.2.0 tpmC | tpmC 提升 (%) | -| :------ | :---------- | :---------- | :------------ | -| 50 | 62212.4 | 61874.4 | -0.54 | -| 100 | 72790.7 | 71317.5 | -2.02 | -| 200 | 75818.6 | 73090.4 | -3.60 | -| 400 | 74515.3 | 73156.9 | -1.82 | - -![TPC-C](/media/tpcc_v610_vs_v620.png) diff --git a/benchmark/v6.2-performance-benchmarking-with-tpch.md b/benchmark/v6.2-performance-benchmarking-with-tpch.md deleted file mode 100644 index 50487b04284f..000000000000 --- a/benchmark/v6.2-performance-benchmarking-with-tpch.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: TiFlash 与 Greenplum/Spark 性能比较 -summary: TiFlash 与 Greenplum/Spark 性能进行了比较。请参考 TiDB v5.4 TPC-H 性能对比测试报告。 ---- - -# TiFlash 与 Greenplum/Spark 性能比较 - -请参考 [TiDB v5.4 TPC-H 性能对比测试报告](https://docs.pingcap.com/zh/tidb/stable/v5.4-performance-benchmarking-with-tpch)。 diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index c8c0c70e7011..96ea32aaa4bf 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -334,23 +334,19 @@ Region 不是前期划分好的，但确实有 Region 分裂机制。当 Region ### TiKV 是否有类似 MySQL 的 `innodb_flush_log_trx_commit` 参数，来保证提交数据不丢失？ -是的。TiKV 单机的存储引擎目前使用两个 RocksDB 实例，其中一个存储 raft-log。TiKV 有个 sync-log 参数，在 true 的情况下，每次提交都会强制刷盘到 raft-log，如果发生 crash 后，通过 raft-log 进行 KV 数据的恢复。 +TiKV 没有类似的参数，但是 TiKV 上的每次提交都会强制落盘到 Raft 日志 (TiKV 使用 [Raft Engine](/glossary.md#raft-engine) 存储 Raft 日志，在提交时会强制刷盘)。如果 TiKV 发生 crash，KV 的数据将会根据 Raft 日志自动恢复。 ### 对 WAL 存储有什么推荐的硬件配置，例如 SSD，RAID 级别，RAID 卡 cache 策略，NUMA 设置，文件系统选择，操作系统的 IO 调度策略等？ WAL 属于顺序写，目前我们并没有单独对他进行配置，建议 SSD。RAID 如果允许的话，最好是 RAID 10，RAID 卡 cache、操作系统 I/O 调度目前没有针对性的最佳实践，Linux 7 以上默认配置即可。NUMA 没有特别建议，NUMA 内存分配策略可以尝试使用 `interleave = all`，文件系统建议 ext4。 -### 在最严格的 `sync-log = true` 数据可用模式下，写入性能如何？ +### 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠？ -一般来说，开启 `sync-log` 会让性能损耗 30% 左右。关闭 `sync-log` 时的性能表现，请参见 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 +通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。 -### 是否可以利用 TiKV 的 Raft + 多副本达到完全的数据可靠，单机存储引擎是否需要最严格模式？ +理论上两个节点也可能同时发生故障，因此从 v5.0 版本开始，写入 TiKV 的数据会默认落盘，即每次提交都会强制落盘到 Raft 日志。如果 TiKV 发生 crash，KV 的数据将会根据 Raft 日志自动恢复。 -通过使用 [Raft 一致性算法](https://raft.github.io/)，数据在各 TiKV 节点间复制为多副本，以确保某个节点挂掉时数据的安全性。只有当数据已写入超过 50% 的副本时，应用才返回 ACK（三副本中的两副本）。但理论上两个节点也可能同时发生故障，所以除非是对性能要求高于数据安全的场景，一般都强烈推荐开启 `sync-log`。 - -另外，还有一种 `sync-log` 的替代方案，即在 Raft group 中用五个副本而非三个。这将允许两个副本同时发生故障，而仍然能保证数据安全性。 - -对于单机存储引擎也同样推荐打开 `sync-log` 模式。否则如果节点宕机可能会丢失最后一次写入数据。 +此外，也可以考虑在 Raft group 中使用五个副本而非三个。这将允许两个副本同时发生故障，而仍然能保证数据安全性。 ### 使用 Raft 协议，数据写入会有多次网络的 roundtrip，实际写入延迟如何？ @@ -384,12 +380,17 @@ TiKV 的内存占用主要来自于 RocksDB 的 block-cache，默认为系统总 本小节介绍 TiDB 测试中的常见问题、原因及解决方法。 +### 如何对 TiDB 进行 Sysbench 基准测试？ + +参考[如何用 Sysbench 测试 TiDB](/benchmark/benchmark-tidb-using-sysbench.md)。 + ### TiDB Sysbench 基准测试结果如何？ -很多用户在接触 TiDB 都习惯做一个基准测试或者 TiDB 与 MySQL 的对比测试，官方也做了一个类似测试。我们汇总很多测试结果后，发现虽然测试的数据有一定的偏差，但结论或者方向基本一致，由于 TiDB 与 MySQL 由于架构上的差别非常大，很多方面是很难找到一个基准点，所以官方的建议两点： +很多用户在接触 TiDB 时都习惯做一个基准测试，或者将 TiDB 与 MySQL 进行对比测试。官方也曾进行过类似的测试，发现尽管不同的测试数据之间存在一定的偏差，但整体结论和方向大致一致。由于 TiDB 和 MySQL 在架构上的差异非常大，许多方面都很难找到完全对等的基准点。 + +因此，无需纠结于这类基准测试，可以更多关注 TiDB 在使用场景上的区别。 -- 大家不要用过多精力纠结这类基准测试上，应该更多关注 TiDB 的场景上的区别。 -- 大家可以直接参考 [TiDB Sysbench 性能测试报告](/benchmark/v3.0-performance-benchmarking-with-sysbench.md)。 +如需了解 TiDB v8.5 的性能表现，可以参考 TiDB Cloud Dedicated 集群的[性能测试报告](https://docs.pingcap.com/tidbcloud/v8.5-performance-highlights)（英文版）。 ### TiDB 集群容量 QPS 与节点数之间关系如何，和 MySQL 对比如何？ diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index b468c2e9a188..022cdf65f4b9 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -225,7 +225,6 @@ select * from information_schema.inspection_rules where type='inspection'; | 组件 | 配置项 | 预期值 | | :---- | :---- | :---- | | TiDB | log.slow-threshold | 大于 0 | - | TiKV | raftstore.sync-log | true | ### version 诊断规则 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 36f11525971e..ae4fa87c254d 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -197,11 +197,9 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与 ### 4.1 TiKV panic 启动不了 -- 4.1.1 `sync-log = false`，机器断电之后出现 `unexpected raft log index: last_index X < applied_index Y` 错误。符合预期，需通过 `tikv-ctl` 工具恢复 Region。 +- 4.1.1 虚拟机部署 TiKV，`kill` 虚拟机或物理机断电，出现 `entries[X, Y] is unavailable from storage` 错误。符合预期，虚拟机的 fsync 不可靠，需通过 `tikv-ctl` 工具恢复 Region。 -- 4.1.2 虚拟机部署 TiKV，`kill` 虚拟机或物理机断电，出现 `entries[X, Y] is unavailable from storage` 错误。符合预期，虚拟机的 fsync 不可靠，需通过 `tikv-ctl` 工具恢复 Region。 - -- 4.1.3 其他原因（非预期，[需报 bug](https://github.com/tikv/tikv/issues/new?template=bug-report.md)）。 +- 4.1.2 其他原因（非预期，[需报 bug](https://github.com/tikv/tikv/issues/new?template=bug-report.md)）。 ### 4.2 TiKV OOM diff --git a/tikv-control.md b/tikv-control.md index 645f9761f896..7f21662405ef 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -343,7 +343,7 @@ middle_key_by_approximate_size: ### 设置一个 Region 副本为 tombstone 状态 -`tombstone` 命令常用于没有开启 sync-log，因为机器掉电导致 Raft 状态机丢失部分写入的情况。它可以在一个 TiKV 实例上将一些 Region 的副本设置为 Tombstone 状态，从而在重启时跳过这些 Region，避免因为这些 Region 的副本的 Raft 状态机损坏而无法启动服务。这些 Region 应该在其他 TiKV 上有足够多的健康的副本以便能够继续通过 Raft 机制进行读写。 +`tombstone` 命令常用于因为机器掉电导致 Raft 状态机丢失部分写入的情况。它可以在一个 TiKV 实例上将一些 Region 的副本设置为 Tombstone 状态，从而在重启时跳过这些 Region，避免因为这些 Region 的副本的 Raft 状态机损坏而无法启动服务。这些 Region 应该在其他 TiKV 上有足够多的健康的副本以便能够继续通过 Raft 机制进行读写。 一般情况下，可以先在 PD 上将 Region 的副本通过 `remove-peer` 命令删除掉： @@ -471,14 +471,6 @@ tikv-ctl --host ip:port modify-tikv-config -n raftdb.defaultcf.disable-auto-comp success ``` -```shell -tikv-ctl --host ip:port modify-tikv-config -n raftstore.sync-log -v false -``` - -``` -success -``` - 如果 compaction 的流量控制导致待 compact 数据量 (compaction pending bytes) 堆积，可以禁用 `rate-limiter-auto-tuned` 配置项或调高 compaction 相关的流量阈值。示例如下： ```shell