TiDB实践安装及性能测试(上)

原创
2023/10/25 00:00
阅读数 22

作者: TiDBer_小阿飞 原文来源:https://tidb.net/blog/18405945

TIDB分布式数据库离线实施方案及相关测试(测试版)

第一部分 ~~ ~~硬件资源

一、硬件资源

现有硬件资源环境统计如下

| | | | | | | | | -- | ------------ | --- | ----- | ---- | --------- | ------------- | | 序号 | IP | CPU | 存储 | 内存 | Hostname | 描述信息 | | 1 | 21.72.124.38 | 16核 | 300GB | 46g | tidb | SQL 解析层,不存储数据 | | 2 | 21.72.124.39 | 8核 | 300GB | 15g | pd | 管理模块,调度计算 | | 3 | 21.72.124.40 | 16核 | 300GB | 62g | tikv | 分布式存储模块,存储数据 | | 4 | 21.72.124.41 | 48核 | 300GB | 125g | tiflash | 列式存储,分析场景加速 | | 5 | 21.72.124.42 | 16核 | 200GB | 62g | ticdc | 增量数据同步工具 | | 6 | 21.72.124.43 | 8核 | 200GB | 15g | localhost | 管理节点 |

二、模块详解

1.TiDB Server

SQL 层,对外暴露 MySQL 协议的连接 endpoint,负责接受客户端的连接,执行 SQL 解析和优化,最终生成分布式执行计划。TiDB 层本身是无状态的,实践中可以启动多个 TiDB 实例,通过负载均衡组件(如 LVS、HAProxy 或 F5)对外提供统一的接入地址,客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据,只是解析 SQL,将实际的数据读取请求转发给底层的存储节点 TiKV(或 TiFlash)。

2.PD Server

PD (Placement Driver), 整个 TiDB 集群的元信息管理模块,负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构,提供 TiDB Dashboard 管控界面,并为分布式事务分配事务 ID。PD 不仅存储元信息,同时还会根据 TiKV 节点实时上报的数据分布状态,下发数据调度命令给具体的 TiKV 节点,可以说是整个集群的“大脑”。此外,PD 本身也是由至少 3 个节点构成,拥有高可用的能力。建议部署奇数个 PD 节点。

3.TiKV Server

负责存储数据,从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region,每个 Region 负责存储一个 Key Range(从 StartKey 到 EndKey 的左闭右开区间)的数据,每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持,默认提供了 SI (Snapshot Isolation) 的隔离级别,这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后,会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以,数据都存储在 TiKV 中。另外,TiKV 中的数据都会自动维护多副本(默认为三副本),天然支持高可用和自动故障转移。

PS:TiKV底层为RocksDB,多版本并发控制 (MVCC)

4.TiFlash

TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是,在 TiFlash 内部,数据是以列式的形式进行存储,主要的功能是为分析型的场景加速。

5.TiCDC(非必须模块)

TiCDC 是一款 TiDB 增量数据同步工具,通过拉取上游 TiKV 的数据变更日志,TiCDC 可以将数据解析为有序的行级变更数据输出到下游。

6.Manager

 

第二部分 ** 系统及软件资源**

一、操作系统及对应软件

| | | | | | -- | ----------------- | ------------------------------------------------ | ---------- | | 序号 | 软件或包 | 名称 | 版本号 | | 1 | 操作系统版本 | CentOS Linux release 7.8.2003(Core) | 7.8 | | 2 | TiDB软件包 | tidb-community-server-v6.5.2-linux-amd64.tar.gz | V6.5.2 | | 3 | TiDB工具包 | tidb-community-toolkit-v6.5.2-linux-amd64.tar.gz | V6.5.2 | | 4 | 编译和构建 TiDB 所需的依赖库 | Golang | 1.19 | | 5 | | Rust  nightly-2022-07-31 |   | | 6 | | GCC | 7.X | | 7 | | LLVM | 13.0 |

二、软件包说明

操作系统支持详见https://docs.pingcap.com/zh/tidb/v6.5/hardware-and-software-requirements

官方软件包和工具包下载:

https://cn.pingcap.com/product/#SelectProduct

依赖库(包)下载:

https://centos.pkgs.org/

 

第三部分 ** 拓扑结构**

一、官方架构图

 image.png

二、物理结构图

** **1698218731695.png

说明:因最小化部署,每台服务器上部署了多个模块,此处模块名称是为区别每个模块的主节点而设置更改,无实际意义,正式环境每台服务器或多台服务器只能部署最多一个模块(管理节点除外)。

三、最小化节点部署模块分布详情

序号 IP 部署模块
1 21.72.124.38 TIDB\TIFLASH
2 21.72.124.39 PD\TIKV
3 21.72.124.40 PD
4 21.72.124.41 TIFLASH
5 21.72.124.42 PD\TIDB\TIKV\TICDC
6 21.72.124.43 TIKV\ALERTMANAGER\PROMETHEUS\GRAFANA

四、新增节点后扩容、缩容后模块分布详情

3PD \4TiDB \4TiKV \3TiFlash \1HA、manager

备注:A、B机房位于同城不同地点,直线距离约15公里

序号 IP 部署模块 CPU(C) MEM(g) Storge(GB) 机房
1 21.72.124.38 TiDB 16 46g 300 A
2 21.72.124.39 PD 8 15g 300 A
3 21.72.124.40 TiKV 16 62g 300 A
4 21.72.124.41 TiFlash 48 125g 300 A
5 21.72.124.42 TiCDC/HAproxy 16 62g 200 A
6 21.72.124.43 manager 8 15g 200 A
7 21.72.124.45 TiDB 8 15 200 A
8 21.72.124.46 TiDB 8 15 200 B
9 21.72.124.47 TiDB 8 15 200 B
10 21.72.124.48 PD 4 15 200 A
11 21.72.124.49 PD 4 15 200 B
12 21.72.124.50 TiKV 8 31 500 A
13 21.72.124.51 TiKV 8 31 500 B
14 21.72.124.52 TiKV 8 31 500 B
15 21.72.124.53 TiFlash 32 62 200 A
16 21.72.124.54 TiFlash 32 62 200 B
** 17** 预留
18 预留
--
19 预留
--

五、逻辑结构图

image.png

第四部分 TiDB及组件安装

一、基础环境检查

1.检查磁盘空间

命令:#df -h

生产环境官方建议

组件 硬盘类型 实例数量(最低要求)
TiDB SSD 2
PD SSD 3
TiKV SSD 3
TiFlash 1 or more SSDs 2
TiCDC SSD 2
监控 SAS 1

2.检查内存

命令:

#free -g

生产环境官方建议

组件 内存 实例数量(最低要求)
TiDB 48 GB+ 2
PD 16 GB+ 3
TiKV 64 GB+ 3
TiFlash 128 GB+ 2
TiCDC 64 GB+ 2
监控 16 GB+ 1

3.检查CPU

命令:

#nproc

生产环境官方建议

组件 CPU 实例数量(最低要求)
TiDB 16 核+ 2
PD 8 核+ 3
TiKV 16 核+ 3
TiFlash 48 核+ 2
TiCDC 16 核+ 2
监控 8 核+ 1

 

4.检查SWAP

官方建议:TiDB 运行需要有足够的内存。如果内存不足,不建议使用 swap 作为内存不足的缓冲,因为这会降低性能。建议永久关闭系统 swap。

free -g查看SWAP分配,并关闭SWAP

#echo "vm.swappiness = 0">> /etc/sysctl.conf

#swapoff -a && swapon -a

#sysctl -p

5.检查文件系统

生产环境部署,建议使用 EXT4 类型文件系统的 NVME 类型的 SSD 磁盘存储 TiKV 数据文件。这个配置方案为最佳实施方案,其可靠性、安全性、稳定性已经在大量线上场景中得到证实。

操作如下:

(1)检查数据盘

#fdisk -l

(2)创建分区

parted -s -a optimal /dev/vda3 mklabel gpt -- mkpart primary ext4 1 -1

(3)格式化文件系统

mkfs.ext4 /dev/vda3

此处如果报错,无法格式化,需执行 #partprobe命令同步内核参数

(4)查看UUID

#lsblk -f

(5)编辑 /etc/fstab 文件,添加 nodelalloc 挂载参数。

vi /etc/fstab

添加挂载参数,UUID为上一步查出

UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data ext4 defaults,nodelalloc,noatime 0 2

(6)挂载数据盘

#mkdir /data &&

> mount -a

(7)检查文件系统是否生效

#mount -t ext4

 

**6.tidb节点创建临时文件夹 **

#sudo mkdir /tmp/tidb

#sudo chmod -R 777 /tmp/tidb/

 

二、系统相关服务

1.关闭防火墙

#systemctl stop firewalld.service

#systemctl disable firewalld.service

#systemctl status firewalld.service

 

2.关闭透明大页

# cat /sys/kernel/mm/transparent_hugepage/enabled

[always] madvise never

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

# echo never > /sys/kernel/mm/transparent_hugepage/defrag

 

3.配置时间同步

(1)检查NTP服务是否开启

# systemctl status chronyd.service

(2)查看chrony服务是否同步

# chronyd tracking

(3)修改chrony服务,此处设置主控机(这里假设为21.72.124.43)作为时间同步服务器,先修改主控机(服务端)设置

# vi /etc/chrony.conf

添加allow 0.0.0.0/0 添加local stratum 10

注释掉上方的server iburst

(4)重启服务

# systemctl restart chronyd.service

(5) 其他所有节点,需同步主控机,各节点操作如下

# vi /etc/chrony.conf

注释server iburst,新增

server 21.72.124.43 iburst

重启

# systemctl restart chronyd.service

检查是否同步

# chronyc sources -v

 

4.修改sysctl.conf参数

所有节点服务器配置如下文件:

# vim /etc/sysctl.conf

添加以下内容:

fs.file-max = 1000000

net.core.somaxconn = 32768

net.ipv4.tcp_tw_recycle = 0

net.ipv4.tcp_syncookies = 0

vm.overcommit_memory = 1

生效

sysctl -p

 

5.修改limits.conf文件

所有节点服务器配置如下文件:

#  vim /etc/security/limits.conf

添加如下内容:

tidb           soft     nofile          1000000

tidb           hard    nofile           1000000

tidb           soft     stack           32768

tidb           hard     stack          32768

三、配置互信

1.创建tidb用户

每个节点以root用户创建tidb用户和密码

#useradd tidb

#passwd tidb

 

2.配置sudo免密

每个节点配置sudo免密

# visudo

添加以下内容

tidb ALL=(ALL) NOPASSWD:ALL

 

3.配置中控机到其他节点互信

中控机(21.72.124.43)以tidb用户登录,执行以下命令

ssh-keygen -t rsa

根据路径配置到各节点的互信

ssh-copy-id -i /home/tidb/.ssh/id_rsa.pub 21.72.124.39

ssh-copy-id -i /home/tidb/.ssh/id_rsa.pub 21.72.124.40

。。。。。。

 

4.测试互信

中控机tidb用户登录 直接ssh到节点

[tidb@localhost]# ssh 21.72.124.39

#sudo -su root

如果以上命令可登录39节点并可直接切换至root用户,表示sudo免密配置成功。

四、安装

1.上传、解压安装包

上传tidb安装包至中控机

tidb-community-server-v6.5.2-linux-amd64.tar.gz  

tidb-community-toolkit-v6.5.2-linux-amd64.tar.gz

 

2.安装tiup组件

将离线包发送到目标集群的中控机后,执行以下命令安装 TiUP 组件:

# tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz && \

>sh tidb-community-server-${version}-linux-amd64/local_install.sh && \

>source /home/tidb/.bash_profile

 

3.合并离线包

如果是通过官方下载页面下载的离线软件包,需要将 TiDB-community-server 软件包和 TiDB-community-toolkit 软件包合并到离线镜像中。

执行以下命令合并离线组件到 server 目录下。${version}替换成版本号,例如:v6.5.2

tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz

ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64

cd tidb-community-server-${version}-linux-amd64/

cp -rp keys ~/.tiup/

tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64

 

4.创建配置文件

在中控机创建并配置topology.yaml文件,注意yaml文件格式,否则安装时,会报错和不识别

# vim topology.yaml

新增的yaml文件里添加配置模块信息

注:tikv节点至少3个,其他模块可混合部署

配置文件根据拓扑部署列出各模块所属节点,举例如下:

--global是全局变量配置,user用户名,ssh_port主机ssh端口号,deploy_dir部署文件夹位置,data_dir数据文件夹位置

--server_configs服务配置,将tidb日志级别选为info,慢阈值设为300

--monitoring_servers&grafana_servers&alertmanager_servers均部署到中控机节点

 

global:

  user: "tidb"

  ssh_port: 22

  deploy_dir: "/tidb-deploy"

  data_dir: "tidb-data"

server_configs:

  tidb:

log.level:”info”

log.slow-threshold:300

pd_servers:

  - host: 21.72.124.39

  - host: 21.72.124.38

  - host: 21.72.124.42

tidb_servers:

  - host: 21.72.124.38

  - host: 21.72.124.39

tikv_servers:

  - host: 21.72.124.40

  - host: 21.72.124.42

  - host: 21.72.124.43

monitoring_servers:

  - host: 21.72.124.43

grafana_servers:

  - host: 21.72.124.43

alertmanager_servers:

  - host: 21.72.124.43

 

5.安装环境校验

使用tidb用户检查安装环境并自动修复集群存在的潜在风险,要确保修复完成后无Fail的项目,如修复完还有Fail项,需手动检查描述并根据Fail描述调整,调整完成重新执行检查,直到无Fail项为止。

检查风险项

#tiup cluster check ./topology.yaml --user tidb

检查并修复

# tiup cluster check ./topology.yaml --apply --user tidb

 

6.集群的安装部署

执行下列安装部署命令

# tiup cluster deploy tidb v6.5.2 ./topology.yaml --user tidb

--tidb为集群名称

--v6.5.2为部署的集群版本

--topology.yaml为初始部署集群拓扑文件

--user tidb表示以tidb用户登录到目标主机完成部署

 

五、初始化集群

1.查看 TiUP 管理的集群情况

# tiup cluster list

 

2.检查部署的 TiDB 集群情况

# tiup cluster display tidb

--预期输出包括 tidb 集群中实例 ID、角色、主机、监听端口和状态(由于还未启动,所以状态为 Down/inactive)、目录信息。

 

3.启动集群

# tiup cluster start tidb

最后输出以下内容,表示集群启动成功

Started cluster `tidb-test` successfully.

The root password of TiDB database has been changed.

The new password is: 'y_+3Hwp=*AWz8971s6'.

Copy and record it to somewhere safe, it is only displayed once, and will not be stored.

The generated password can NOT be got again in future.

 

4.检查集群运行状态

# tiup cluster display tidb

--所有节点状态均为up表明正常。

 

**5.Dashboard 和 Grafana **

(1)Dashboard

通过 {pd-ip}:{pd-port}/dashboard 登录 TiDB Dashboard,登录用户和口令为 TiDB 数据库 root 用户和口令。如果你修改过数据库的 root 密码,则以修改后的密码为准,默认密码为空。

例如本次部署登录地址为:

Dashboard

http://21.72.124.43:2379/dashboard

(2)Grafana

通过 {Grafana-ip}:3000 登录 Grafana 监控,默认用户名及密码为 admin/admin。

点击 Overview 监控页面检查 TiDB 端口和负载监控信息。

例如本次部署登录地址为:

Grafana

http://21.72.124.43:3000

 

6.dashboard监控面板指标项解释

QPS 该区域显示最近一小时整个集群的每秒成功和失败查询数量

数据库时间

Database Time by SQL Type

-database time: 每秒的总数据库时间

-sql_type: 每种 SQL 语句每秒消耗的数据库时间

Database Time by SQL Phase

-database time: 每秒的总数据库时间

-get token/parse/compile/execute: 4 个 SQL 处理阶段每秒消耗的数据库时间

execute 执行阶段为绿色,其他三个阶段偏红色系,如果非绿色的颜色占比明显,意味着在执行阶段之外数据库消耗了过多时间,需要进一步分析根源。

SQL Execute Time Overview

-execute time: execute 阶段每秒消耗的数据库时间

-tso_wait: execute 阶段每秒同步等待 TSO 的时间

-kv request type: execute 阶段每秒等待每种 KV 请求类型的时间,总的 KV request 等待时间可能超过 execute time,因为 KV request 是并发的。

绿色系标识代表常规的写 KV 请求(例如 Prewrite 和 Commit),蓝色系标识代表常规的读 KV 请求,其他色系标识需要注意的问题。例如,悲观锁加锁请求为红色,TSO 等待为深褐色。如果非蓝色系或者非绿色系占比明显,意味着执行阶段存在异常的瓶颈。例如,当发生严重锁冲突时,红色的悲观锁时间会占比明显;当负载中 TSO 等待的消耗时间过长时,深褐色会占比明显。

** **

应用连接

Connection Count

-total:所有 TiDB 的连接数

-active connections:所有 TiDB 总的活跃连接数

Disconnection

-undetermined 不确定的连接数

-ok 确定的连接数

-error 错误的连接数

SQL数量

Query Per Second

-total

-alter tables

-analyze tables

-begin

-commit

-createdatabase

-createtable

-CreateUser

-CreatView

-Delete

-DescTable

-DropTable

-DropDatabase

-grant

-insert

-replace

-rollback

-savepoint

-select

-set

-show

-truncatetable

-update

-use

-other

Failed Queries

**-**parser 解析

-planner 计划

-schema 实例

-server 服务

-unknown 未知

Command Per Second

6.grafana面板指标解释

六、扩容、缩容

1.TiDB扩容

(1)新建yaml文件

# vim tidb-scales-out.yaml

加入以下内容,注意yaml文件格式

tidb_servers:

  - host: 21.72.124.45

(2)执行检查

# tiup cluster check tidb tidb-scales-out.yaml --cluster

(3)执行扩容

# tiup cluster scales-out tidb tidb-scales-out.yaml

显示Scaled cluster ‘tidb’ out successfully表示扩容成功。

(4)扩容后检查

# tiup cluster display tidb

 

2.PD扩容

(1)新建yaml文件

# vim pd-scales-out.yaml

加入以下内容,注意yaml文件格式

pd_servers:

  - host: 21.72.124.48

(2)执行检查

# tiup cluster check tidb pd-scales-out.yaml --cluster

(3)执行扩容

# tiup cluster scales-out tidb pd-scales-out.yaml

(4)扩容后检查

# tiup cluster display tidb

 

3.TiKV扩容

(1)新建yaml文件

# vim tikv-scales-out.yaml

加入以下内容,注意yaml文件格式

tikv_servers:

  - host: 21.72.124.50

(2)执行检查

# tiup cluster check tidb tikv-scales-out.yaml --cluster

(3)执行扩容

# tiup cluster scales-out tidb tikv-scales-out.yaml

(4)扩容后检查

# tiup cluster display tidb

 

4.TiFlash扩容

(1)开启PD的Placement Rules功能

# tiup ctl:v6.5.2 pd -u http://21.72.124.38:2379 config set enable-placement-rules true

(2)新建yaml文件

# vim tiflash-scales-out.yaml

加入以下内容,注意yaml文件格式

tiflash_servers:

  - host: 21.72.124.53

(3)执行检查

# tiup cluster check tidb tiflash-scales-out.yaml --cluster

(4)执行扩容

# tiup cluster scales-out tidb tiflash-scales-out.yaml

(5)扩容后检查

# tiup cluster display tidb

 

5.缩容

(1)下线tidb、PD

下线tidb 39节点

# tiup cluster scales-in tidb --node 21.72.124.39:4000

下线PD 38节点

# tiup cluster scales-in tidb --node 21.72.124.38:2379

(2)下线tikv、tiflash

tikv、tiflah下线为异步下线,下线过程较慢,待状态变为tombstone后,还需手动执行命令清理这些节点

下线tikv 40节点

# tiup cluster scales-in tidb --node 21.72.124.40:20160

下线tiflash 41节点

# tiup cluster scales-in tidb --node 21.72.124.41:9000

使用命令观察节点状态

# tidb cluster display tidb

待tikv、tiflash下线节点status变为tombstone后,执行以下命令清除下线节点

# tiup cluster prune tidb

该命令执行以下操作:

    停止节点服务

    清理节点相关数据文件

更新集群拓扑,移除已下线节点

注意事项:TiFlash节点下线前,需检查目前副本数,副本数需小于缩容后的节点数,否则,不可进行TiFlash节点的缩容操作。

tobe_left_nodes代表所容后的TiFlash节点数

查询命令:

select * from information_schema.tiflash_replica where REPLICA_COUNT >’tobe_left_nodes’;

如果查询结果为空,可进行缩容操作;

如果结果不为空,则需要修改相关表的副本数:

alter table <db-name>.<table-name> set tiflash replica ‘new_replica_num’;

再次执行查询命令,确保没有数据表的TiFlash副本数大于缩容后的节点数。

第五部分 相关测试及结果分析

一、sysbench测试

1.测试模式

单一节点测试后把结果相加,

注:安装HAproxy的集群无需单节点测试

后面章节会说明正式环境离线安装HAproxy的步骤和部署

测试tidb节点:21.72.124.38  21.72.124.39

 

2.mysql客户端安装

正常情况下,将兼容的mysql客户端安装包上传到中控机节点进行安装即可。

此次,使用Docker部署mysql客户端和sysbench工具包

 

3.创建测试库

# mysql -uroot -h21.72.124.38 -P4000

mysql>create database sbtset;

 

4.sysbench配置

创建配置文件(非必须),主要将数据库连接信息和测试并发等编辑好,方便后续测试简化

#vim config

mysql-host=

mysql-user=

mysql-db=

mysql-passwd=

mysql-port=

time=

threads=

report-interval=

 

5.导入测试数据

# sysbench --config-file=config oltp.point_select --tables=32 --table-size=10000000 prepare

 

6.lua测试

(1)Point select 测试命令

# sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

(2)Update index 测试命令

# sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

(3)Read-only 测试命令

# sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

 

说明:/usr/share/sysbench目录里有部分已写好的lua测试文件,可根据情况进行测试,此次主要测试tidb数据库的DDL性能,故只测试了查询、update、数据读写。

 

二、TPC-C测试

1.说明和环境准备

TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试,其中包含五类事务:

 

NewOrder – 新订单的生成

Payment – 订单付款

OrderStatus – 最近订单查询

Delivery – 配送

StockLevel – 库存缺货状态分析

在测试开始前,TPC-C Benchmark 规定了数据库的初始状态,也就是数据库中数据生成的规则,其中 ITEM 表中固定包含 10 万种商品,仓库的数量可进行调整,假设 WAREHOUSE 表中有 W 条记录,那么:

 

STOCK 表中应有 W * 10 万条记录(每个仓库对应 10 万种商品的库存数据)

DISTRICT 表中应有 W * 10 条记录(每个仓库为 10 个地区提供服务)

CUSTOMER 表中应有 W * 10 * 3000 条记录(每个地区有 3000 个客户)

HISTORY 表中应有 W * 10 * 3000 条记录(每个客户一条交易历史)

ORDER 表中应有 W * 10 * 3000 条记录(每个地区 3000 个订单),并且最后生成的 900 个订单被添加到 NEW-ORDER 表中,每个订单随机生成 5 ~ 15 条 ORDER-LINE 记录。

我们将以 1000 WAREHOUSE 为例进行测试。

 

TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput),其中 Transactions 以 NewOrder Transaction 为准,即最终衡量单位为每分钟处理的新订单数。

 

本文使用 go-tpc 作为 TPC-C 测试实现

需提前安装TIUP BENCH程序

离线环境,需在TOOL工具包里找到bench的tar包解压使用

测试:

tiup bench -h

 

2.导入数据

导入数据通常是整个 TPC-C 测试中最耗时,也是最容易出问题的阶段。

在 shell 中运行 TiUP 命令:

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 1000 --threads 20 prepare

基于不同的机器配置,这个过程可能会持续几个小时。如果是小型集群,可以使用较小的 WAREHOUSE 值进行测试。

数据导入完成后,可以通过命令 tiup bench tpcc -H 21.72.124.38 -P 4000 -D tpcc --warehouses 4 check 验证数据正确性。

 

3.运行测试

运行测试的命令是:

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 1000 --threads 100 --time 10m run

运行过程中控制台上会持续打印测试结果:

[Current] NEW_ORDER - Takes(s): 4.6, Count: 5, TPM: 65.5, Sum(ms): 4604, Avg(ms): 920, 90th(ms): 1500, 99th(ms): 1500, 99.9th(ms): 1500

[Current] ORDER_STATUS - Takes(s): 1.4, Count: 1, TPM: 42.2, Sum(ms): 256, Avg(ms): 256, 90th(ms): 256, 99th(ms): 256, 99.9th(ms): 256

[Current] PAYMENT - Takes(s): 6.9, Count: 5, TPM: 43.7, Sum(ms): 2208, Avg(ms): 441, 90th(ms): 512, 99th(ms): 512, 99.9th(ms): 512

[Current] STOCK_LEVEL - Takes(s): 4.4, Count: 1, TPM: 13.8, Sum(ms): 224, Avg(ms): 224, 90th(ms): 256, 99th(ms): 256, 99.9th(ms): 256

...

运行结束后,会打印测试统计结果:

[Summary] DELIVERY - Takes(s): 455.2, Count: 32, TPM: 4.2, Sum(ms): 44376, Avg(ms): 1386, 90th(ms): 2000, 99th(ms): 4000, 99.9th(ms): 4000

[Summary] DELIVERY_ERR - Takes(s): 455.2, Count: 1, TPM: 0.1, Sum(ms): 953, Avg(ms): 953, 90th(ms): 1000, 99th(ms): 1000, 99.9th(ms): 1000

[Summary] NEW_ORDER - Takes(s): 487.8, Count: 314, TPM: 38.6, Sum(ms): 282377, Avg(ms): 899, 90th(ms): 1500, 99th(ms): 1500, 99.9th(ms): 1500

[Summary] ORDER_STATUS - Takes(s): 484.6, Count: 29, TPM: 3.6, Sum(ms): 8423, Avg(ms): 290, 90th(ms): 512, 99th(ms): 1500, 99.9th(ms): 1500

[Summary] PAYMENT - Takes(s): 490.1, Count: 321, TPM: 39.3, Sum(ms): 144708, Avg(ms): 450, 90th(ms): 512, 99th(ms): 1000, 99.9th(ms): 1500

[Summary] STOCK_LEVEL - Takes(s): 487.6, Count: 41, TPM: 5.0, Sum(ms): 9318, Avg(ms): 227, 90th(ms): 512, 99th(ms): 1000, 99.9th(ms): 1000

测试完成之后,也可以运行 tiup bench tpcc -H 172.16.5.140 -P 4000 -D tpcc --warehouses 4 check 进行数据正确性验证。

 

4.清理测试数据

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 4 cleanup

 

三、CH-benCHmark 测试

1.说明

在测试数据库性能时,经常需要对数据库进行压测,为了满足这一需求,TiUP 集成了 bench 组件。TiUP bench 组件提供多种压测的 workloads,命令分别如下:

 

tiup bench tpcc   # 以 TPC-C 作为 workload 压测

tiup bench tpch   # 以 TPC-H 作为 workload 压测

tiup bench ch     # 以 CH-benCHmark 作为 workload 压测

tiup bench ycsb   # 以 YCSB 作为 workload 压测

tiup bench rawsql # 以自定义 SQL 文件作为 workload 压测

其中 tpcc, tpch, ch, rawsql 支持如下命令行参数。ycsb 使用方法较为不同,它主要通过 properties 文件进行配置,详见 go-ycsb 使用说明。

  -t, --acThreads int         OLAP 并发线程数,仅适用于 CH-benCHmark (默认 1)

                               --conn-params string    数据库连接参数,例如:

                              `--conn-params tidb_isolation_read_engines='tiflash'` 设置 TiDB 通过 TiFlash 进行查询

                              `--conn-params sslmode=disable` 设置连接 PostgreSQL 不启用加密

      --count int             总执行次数,0 表示无限次

  -D, --db string             被压测的数据库名 (默认为 "test")

  -d, --driver string         数据库驱动: mysql, postgres (默认 "mysql")

      --dropdata              在 prepare 数据之前清除历史数据

  -h, --help                  输出 bench 命令的帮助信息

  -H, --host strings          数据库的主机地址 (默认 ["127.0.0.1"])

      --ignore-error          忽略压测时数据库报出的错误

      --interval duration     两次报告输出时间的间隔 (默认 10s)

      --isolation int         隔离级别 0:Default,1:ReadUncommitted,

                              2:ReadCommitted,3:WriteCommitted,4:RepeatableRead,

                              5:Snapshot,6:Serializable,7:Linerizable

      --max-procs int         Go Runtime 能够使用的最大系统线程数

      --output string         输出格式 plain,table,json (默认为 "plain")

  -p, --password string       数据库密码

  -P, --port ints             数据库端口 (默认 [4000])

      --pprof string          pprof 地址

      --silence               压测过程中不打印错误信息

  -S, --statusPort int        TiDB 状态端口 (默认 10080)

  -T, --threads int           压测并发线程数 (默认 16)

      --time duration         总执行时长 (默认 2562047h47m16.854775807s)

  -U, --user string           压测时使用的数据库用户 (默认 "root")

 

--host 和 --port 支持以逗号分隔传入多个值,以启用客户端负载均衡。例如,当指定 --host 172.16.4.1,172.16.4.2 --port 4000,4001 时,负载程序将以轮询调度的方式连接到 172.16.4.1:4000, 172.16.4.1:4001, 172.16.4.2:4000, 172.16.4.2:4001 这 4 个实例上。

 

--conn-params 需要符合 query string 格式,不同数据库支持不同参数,

如:

--conn-params tidb_isolation_read_engines='tiflash' 设置 TiDB 通过 TiFlash 进行查询。

--conn-params sslmode=disable 设置连接 PostgreSQL 不启用加密。

 

当运行 CH-benCHmark 时,可以通过 --ap-host, --ap-port, --ap-conn-params 来指定独立的 TiDB 实例用于 OLAP 查询。

 

2.使用 TiUP 运行 TPC-C 测试

TiUP bench 组件支持如下运行 TPC-C 测试的命令和参数:

 

Available Commands:

      check       检查数据一致性

      cleanup     清除数据

      prepare     准备数据

      run         开始压测

 

Flags:

      --check-all            运行所有的一致性检测

      -h, --help                 输出 TPC-C 的帮助信息

      --partition-type int   分区类型 (默认为 1)

                             1 代表 HASH 分区类型

                             2 代表 RANGE 分区类型

                             3 代表 LIST 分区类型并按 HASH 方式划分

                             4 代表 LIST 分区类型并按 RANGE 方式划分

      --parts int            分区仓库的数量 (默认为 1)

      --warehouses int       仓库的数量 (默认为 10)

 

3.TPC-C 测试步骤

以下为简化后的关键步骤。完整的测试流程可以参考如何对 TiDB 进行 TPC-C 测试

 

通过 HASH 使用 4 个分区创建 4 个仓库:

tiup bench tpcc --warehouses 4 --parts 4 prepare

运行 TPC-C 测试:

tiup bench tpcc --warehouses 4 --time 10m run

检查一致性:

tiup bench tpcc --warehouses 4 check

清理数据:

tiup bench tpcc --warehouses 4 cleanup

 

当需要测试大数据集时,直接写入数据通常较慢,此时可以使用如下命令生成 CSV 数据集,然后通过 TiDB Lightning 导入数据。

 

生成 CSV 文件:

tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv

 

为指定的表生成 CSV 文件:

tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv --tables history,orders

 

4.使用 TiUP 运行 TPC-H 测试

TiUP bench 组件支持如下运行 TPC-H 测试的命令和参数:

 

Available Commands:

  cleanup     清除数据

  prepare     准备数据

  run         开始压测

 

Flags:

      --check            检查输出数据,只有 scale 因子为 1 时有效

  -h, --help             tpch 的帮助信息

      --queries string   所有的查询语句

      --sf int           scale 因子

 

5.TPC-H 测试步骤

(1)准备数据

tiup bench tpch --sf=1 prepare

运行 TPC-H 测试,根据是否检查结果执行相应命令:

(2)检查结果

tiup bench tpch --count=22 --sf=1 --check=true run

(3)不检查结果

tiup bench tpch --count=22 --sf=1 run

(4)清理数据

tiup bench tpch cleanup

 

6.使用 TiUP 运行 YCSB 测试

你可以使用 TiUP 对 TiDB 和 TiKV 节点分别进行 YCSB 测试。

(1)测试 TiDB

准备数据:

tiup bench ycsb load tidb -p tidb.instances="127.0.0.1:4000" -p recordcount=10000

运行 YCSB 测试:

# 默认读写比例为 95:5

tiup bench ycsb run tidb -p tidb.instances="127.0.0.1:4000" -p operationcount=10000

 

(2)测试 TiKV

(1)准备数据:

tiup bench ycsb load tikv -p tikv.pd="127.0.0.1:2379" -p recordcount=10000

(2)运行 YCSB 测试:

# 默认读写比例为 95:5

tiup bench ycsb run tikv -p tikv.pd="127.0.0.1:2379" -p operationcount=10000

 

7.使用 TiUP 运行 RawSQL 测试

你可以将 OLAP 查询写到 SQL 文件中,通过 tiup bench rawsql 执行测试,步骤如下:

(1)准备数据和需要执行的查询:

-- 准备数据

CREATE TABLE t (a int);

INSERT INTO t VALUES (1), (2), (3);

-- 构造查询,保存为 demo.sql

SELECT a, sleep(rand()) FROM t WHERE a < 4*rand();

(2)运行 RawSQL 测试

tiup bench rawsql run --count 60 --query-files demo.sql

 

四、节点增删性能测试

1.混合节点

(1)混合节点构成

3PD+2tidb+3tikv+2tiflash

序号 IP 部署模块
1 21.72.124.38 TIDB\TIFLASH
2 21.72.124.39 PD\TIKV
3 21.72.124.40 PD
4 21.72.124.41 TIFLASH
5 21.72.124.42 PD\TIDB\TIKV
6 21.72.124.43 TIKV

(2)测试

插入数据

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计:9.2GB

插入数据用时:11min

TIKV分配数据

21.72.124.39: 7.9GB

21.72.124.42: 6.9GB

21.72.124.43: 8.5GB

合计:23.3GB

TOP SQL用时:16min

TOP SQL语句

SELECT

c_id,

c_last,

sum(ol_amount) as revenue,

c_city,

c_phone,

n_name

FROM

customer,

orders,

order_line,

nation

WHERE

  c_id = o_c_id and

  c_w_id = o_w_id and

  c_d_id = o_d_id and

  ol_w_id = o_w_id and

  ol_d_id = o_d_id and

  ol_o_id = o_id and

  o_entry_d >= ‘2007-01-02 00:00:00.000000’ and

  o_entry_d <= ol_delivery_d and

  n_nationkey = ascii(substr(c_stat,1,1)) -65

GROUP BY

  c_id,c_last,c_city,c_phone,n_name

ORDER BY

  revenue DESC;

   

(3)清理数据

# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

清理数据时间约10秒,可忽略不计。

TIKV数据盘数据自动清理

通过GC机制删除TIKV节点数据大约需要1-2小时,按每10分钟运行一次GC的频率,并会有相关日志生成。

 

2.扩容一个PD节点

(1)扩容

扩容操作参照本文档(第四部分第六项),新增节点扩容需配置主机,具体参考本文档(第四部分第一、二、三项)

(2)测试

插入数据同上

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计:9.2GB

插入数据用时:11min

TIKV数据:38.76GB

 

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时,因GC机制根据PD返回的命令,只访问其中一个数据节点,各节点数据清理时间有差异。

(3)结论

扩容PD节点对数据插入用时无差别,但对TIKV节点的数据存储和节点分配有影响。

 

3.扩容一个TIKV节点

(1)扩容

扩容操作参照本文档(第四部分第六项),新增节点扩容需配置主机,具体参考本文档(第四部分第一、二、三项)

(2)测试

插入数据同上

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计:9.2GB

插入数据用时:10min

TIKV数据:38.2GB

 

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时,因GC机制根据PD返回的命令,只访问其中一个数据节点,各节点数据清理时间有差异。

(3)结论

扩容TIKV节点对数据插入用时无差别,但对TIKV节点的数据存储和存储时间变化有影响。

 

4.3PD+4TIDB+6TIKV+3TIFLASH(无混合节点)

(1)扩容

扩容操作参照本文档(第四部分第六项),新增节点扩容需配置主机,具体参考本文档(第四部分第一、二、三项)

(2)测试

插入数据同上,四tidb节点同时参与导入

tiup bench tpcc -H 21.72.124.38,21.72.124.45,21.72.124.46,21.72.124.47 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计:9.2GB

插入数据用时:6min

TIKV数据:32GB

 

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时,因GC机制根据PD返回的命令,只访问其中一个数据节点,各节点数据清理时间有差异。

(3)结论

数据导入速度提升明显,导入用时提升一倍,TIKV数据写入趋于平缓大约用时12分钟

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部