TiDB PCTP 备战--TiDB Server

原创张玉龙 2022-03-24

2667

TiDB 数据库的整体架构

TiDB Server 的主要功能与架构

TiDB Server 的主要功能

处理客户端的连接
SQL 语句的解析和编译
关系型数据与 KV 的转化
SQL 语句的执行
在线 DDL 的执行
GC 垃圾回收

TiDB Server 的架构简单解释

处理客户端的连接，是由 Protocol Layer 负责的。
SQL 语句的解析和编译，是由 Parse + Compile 负责，解析和编译完成后交给 Executor 执行。
Executor、DistSQL 和 KV 负责 SQL 语句的执行
对于事务是由 Transaction 和 KV 协同执行
在线 DDL 的执行是由 schema load、worker 和 start job 负责的
PD Client 负责与 PD 节点进行信息交互，TiKV client 负责与 TiKV 节点进行信息交互
垃圾回收，MVCC 过期版本的数据是由 GC 模块负责

Parse 模块–SQL语句的解析和编译

Compile 模块–SQL语句的解析和编译

关系型数据与 KV 的转化

聚簇

所谓聚簇就是指以某个列为基准，把拥有相同聚簇键值的所有行都存储在相同位置上的物理存储方法，在指定的聚簇中只创建一个表的聚簇结构叫做单表聚簇。

TiDB 聚簇表(KEY使用了表中的主键)将关系型数据转化为 Key-Value

聚簇表

表中的行数据存储顺序与主键存储的顺序一致的表即为聚簇表
表的主键即为 KV 映射中 Key 的一部分
通过主键访问行记录时，可以直接获取行记录

-- 聚簇表案例，ID列为主键列，聚簇列
CREATE TABLE User(
  ID int not null PRIMARY KEY Clustered,  --Clustered
  Name varchar(20),
  Role varchar(20),
  Age int,
  KEY idxAge (Age)
);
复制

Region 默认是 96M，当 Region 达到 144M 时就会分裂
以 Region 为单位，Region 里面是 Key-Value 的键值对，将数据以分布式方式存储在 TiKV 里

TiDB 非聚簇表将关系型数据转化为 Key-Value

非聚簇表

表中的行数据存储顺序与主键存储的顺序不一定一致的表即为非聚簇表
行数据的键由 TiDB 内部隐式分配的 _tidb_rowid 构成，而主键本质上是唯一索引
通过主键访问行记录时，不可以直接获取行记录，需要先从额外存储的主键获取行的 _tidb_rowid ，再通过此行的 _tidb_rowid 获取行记录。这将比聚簇表多一次回表操作。

-- 非聚簇表案例
CREATE TABLE User(
  ID int not null PRIMARY KEY nonclustered,  --nonclustered
  Name varchar(20),
  Role varchar(20),
  Age int,
  KEY idxAge (Age)
);
复制

总结

TiDB 中的数据是在 RocksDB 中以 KV 键值对的方式存储的
数据存储管理的基本单位为 Region

每一个 Region 默认大小为 96MB
每一个 Region 按照左闭右开的区间划分数据存储范围，如[a_d),[dg)
每一个 SCHEMA 会被分配一个唯一的 TablelD

SQL 读写相关模块

Executor : 根据执行计划来执行SQL，当遇到比较复杂的SQL(比如范围查询，表连接，嵌套查询，子查询等)交给 DistSQL 模块进行处理，对于点查(比如根据主键或唯一索引的等值查询)的SQL交给 KV 模块处理。
DistSQL 将复杂的SQL转化为对单表的计算任务的组合经过 TiKV client 发送给 TiKV
DistSQL 和 KV 都是通过 TiKV client 向 TiKV 发送读写请求
如果 SQL 有事务相关的操作，执行器还会启动 Transaction 模块，Transaction 模块主要负责两阶段提交以及相关锁的管理，Transaction 模块通过 PD Client 从PD节点获取事务开始和提交的时间戳。

在线 DDL 相关模块

当用户发出 DDL 操作，是由 TiDB Server 节点上的 start job 模块接收，start job 模块将 DDL 操作放到 TiKV 的任务队列(job queue)中。
TiDB 集群中有多个 TiDB Server 节点，当不同的 TiDB Server 节点的 start job 模块收到 DDL 操作时，都会放到 job queue中，而 TiKV 在同一时刻只能执行一个 DDL 操作。
TiDB Server 节点通过 worker 模块执行 DDL 操作，每个 TiDB Server 节点都有 worker，而只有 owner 角色的 TiDB Server 节点上的 worker 模块才会执行 DDL 操作，不管这个 DDL 是哪个节点发过来的。
当 worker 模块将 DDL 执行完成后，会将 DDL 的 job 放到历史队列(history queue)中
TiDB Server 的 owner 角色是有任期时间的，当超过一定时间会重新发起新 owner 角色的选举，所以 TiDB Server 节点是轮换着当 owner 角色，哪个节点作为 owner，这个节点上的 worker 就负责执行 job 队列里的 DDL 操作。
schema load 模块的作用是当前 TiDB Server 节点成为 owner 角色后，将最新的所有表、schema 同步到内部缓存中， worker 根据这些信息去执行 job 队列中的 job。
job 放到 TiKV 是为了持久化，防止 TiDB Server 异常导致 DDL 执行失败。

GC 机制与相关模块

历史版本数据保留时间默认是 gc_life_time = 10min

TiDB Server 的缓存

TiDB Server 缓存组成

SQL 结果
线程缓存
元数据，统计信息

TiDB Server 缓存管理

tidb_mem_quota_query：限制每个SQL占用缓存的大小
oom-action：当SQL占用缓存大于tidb_mem_quota_query参数值后的操作，比如中断这个SQL，记录日志等。

TiDB Server 关键性能参数与优化

CPU (Dynamic frequency scaling)

定义: CPU 动态节能技术用于降低服务器功耗，通过选择系统空闲状态不同的电源管理策略，可以实现不同程度降低服务器功耗，更低的功耗策略意味着 CPU 唤醒更慢对性能影响更大。
5种模式: 1. performance 2. userspace 3. powersave 4. ondemand 5. conservative
配置命令：cpupower frequency-set --governor performancecpupower frequency-set --governor performance

CPU (Numa Binding)

定义: 内存直接绑定在 CPU 上，CPU 只有访问自身管理的内存物理地址时，才会有较短的响应时间。
NUMA 架构的服务器，通过绑定 NUMA 节点，尽可能的避免跨 NUMA 访问内存，提升 tidb-server 的性能。
可使用 numactl 命令绑定

Memory

Transparent Huge Page (THP)
对于数据库应用，不推荐使用 THP,因为数据库往往具有稀疏而不是连续的内存访问模式，且当高阶内存碎片化比较严重时，分配THP页面会出现较大的延迟。若开启针对THP的直接内存规整功能，也会出现系统CPU使用率激增的现象，因此建议关闭THP。
Virtual Memory Parameters
dirty_ ratio、 dirty_ background_ ratio : 通常不需调整。对于高性能SSD，比如 NVMe 设备来说，降低其值有利于提高内存回收时的效率。

Disk

I/O scheduler
I/O 调度程序确定 I/O 操作何时在存储设备上运行以及持续多长时间，也称为 I/0 升降机。

NOOP
CFQ
DEADLINE

Mount Parameters
默认的方式下 linux 会把文件访问的时间 atime 做记录，文件系统在文件被访问、创建、修改等的时候记录下了文件的一些时间戳，比如:文件创建时间、最近一次修改时间和最近一次访问时间;
这在绝大部分的场合都是没有必要的。
可以尝试使用 noatime 和 nodiratime 禁止记录最近一次访问时间戳。

Performance 性能相关配置

max-proc
控制 tidb-server 使用的 CPU 核数，在单台机器上部署多个 tidb-server 设置这个变量可以限制tidb-server使用的资源，避免对其他进程造成影响。
token-limit
配置可以同时执行请求的 session 的数量，用于流量控制，避免并发请求数过多造成 tidb-server 资源耗尽，服务无法响应。
force-priority
控制 tidb-server 的优先级，设置后，所有请求都会使用该优先级来执行。
committer-concurrency
控制一个事务 commit 阶段的最大的并发数量。对于一个大事务来说，提交事务需要向 TiKV 发送大量写请求。设置更大的并发可能让大事务更快提交完成，但是也可能会造成 TiKV 瞬时压力过大，请求堆积，无法响应。

TiKV Client 性能相关配置

grpc-connection-count
设置 TiDB 和每个 TiKV 之间的 grpc 连接数量，当大量并发请求发送到一个 grpc 连接的时候，单个 gRPC 连接串行发送请求，可能会成为瓶颈，当 gPRC 连接成为瓶颈时，设置更大的 gRPC 连接数可以提升性能，但代价是更多消耗系统资源。

Prepared Plan Cache

enabled: 开启后减少执行计划造成的计算开销，让同样类型的语句使用相同的执行计划，提升性能，代价是当数据或查询条件变化时，执行计划可能会不是最好的。
capacity: 用来限制 cache 的大小(缓存条数)，避免占用过多内存，如果应用使用了大量不同类型的请求，超过了 capacity 上限，plan cache 的效果会打折扣。

TiDB System Variables

Concurrency

系统资源空闲较多时，设置更高并发度让资源利用的更充分，可以提升整体性能，但是更高并发往往消耗更多系统资源，在资源紧张时反而会降低整体性能。

属性名	含义
tidb_distsql_scan_concurrency	控制 TableScan 和 IndexScan 算子的并发度
tidb_index_lookup_concurrency	控制 IndexLookUp 算子的并发度
tidb_build_stats_concurrency	控制 Analyze 执行的并发度，可能会影响在线业务的延迟
tidb_hash_join_concurrency	控制 HashJoin 算子的并发度
tidb_index_lookup_join_concurrency	控制 IndexLookUpJoin 算子的并发度
tidb_ddl_reorg_worker_cnt	控制 DDL 加索引的并发度

Batch Size

一个 Chunk 包含多行数据，SQL 语句执行时，执行器以 Chunk 为单位来执行获取数据、表达式求值和 JOIN 等操作，当结果集较大时，更大的 Chunk size 可以提升性能，如果结果集很小，小于 Chunk size, 申请过大 chunk 的内存会造成性能的损失。
tidb_init_chunk_size / tidb_max_chunk_size

tidb_index_join_batch_size

Limit

tidb_store_limit: 控制同时发往一个 TiKV 节点的请求数量，避免单个 TiKV 节点因为请求量太大，超过处理能力，造成大量请求超时或返回错误。
tidb_retry_limit: 控制乐观事务的重试次数，乐观事务在遇到事务冲突的时候会进行重试，但是重试次数过多会使冲突加剧，造成性能下降，重试次数太少会造成事务执行成功率下降。

Backoff

在请求遇到可重试的错误时，在重试前需要等待一段时间，这个时间设置的过大，会增加延迟，如果设置的过小，会造成很多无谓的重试，消耗过多的系统资源。

tidb_backoff_weight: TiDB backoff 最大时间的权重，通过这个变量来调整最大重试时间。
tidb_backoff_lock_fast: 读请求遇到锁的 backoff 时间。

TiDB Server 常用监控指标

Duration 相关

Grafana 监控TiDB --> Query Summary --> Duration
Grafana 监控TiDB --> Query Summary --> 999 Duration/99 Duration/95 Duration/80 Duration
Grafana 监控TiDB --> Query Detail - Duration 80/95/99/999 By instance

QPS相关

Grafana 监控TiDB --> Query Summary --> QPS
Grafana 监控TiDB --> Query Summary --> CPS By Instance
Grafana 监控TiDB --> Query Detail - Internal SQL QPS

Transaction相关

Grafana 监控TiDB --> Transaction - Duration
Grafana 监控TiDB --> Transaction - Transaction Statement Num
Grafana 监控TiDB --> Transaction - Transaction Retry Num

资源相关

Grafana 监控TiDB --> Server - CPU Usage
Grafana 监控TiDB --> Server - Memory Usage
Grafana 监控TiDB --> Server - Connection Count
Grafana 监控TiDB --> Server -Get Token Duration

PD/TiKV相关

Grafana 监控TiDB --> PD Client - PD TSO Wait/RPC Duration
Grafana 监控TiDB --> KV Request - KV Request Duration 99 by store/type
Grafana 监控TiDB --> KV Errors - KV Backoff OPS
Grafana 监控TiDB --> KV Errors - KV Backoff Duration

TiDB Server 的 OOM 问题诊断与处理

TiDB Server OOM 对业务的影响

TiDB Server 上的业务 SQL 会失败
业务响应时间升高
前端体验变差

TiDB Server OOM的诊断方法

客户端应用

ERROR 2013 (HY000): Lost connection to MySQL server during query
复制

日志

dmesg -T | grep tidb-server 结果中有事故发生附近时间点的 OOM-killer 的日志;
tidb.log (事故发生后附近时间的 “Welcome to TiDB” 的日志<即 TiDB server 发生重启>)
tidb_stderr.log ( grep 到 fatal error: “runtime: out of memory” 或 “cannot allocate memory”)
Grafana 监控TiDB --> Server - Memory Usage
Grafana 监控TiDB --> Server --> Uptime，和配合一起使用，确认 TiDB Server 实例的运行情况，观察
是否同时有内存使用率飙高的情况。