一、 背景：
中小客户比较在意成本且业务量数据量不是很大，为了兼顾资源和业务使用虚拟机3节点集群，本文档介绍中小客户使用虚拟机三节点集群架构和内存控制。
二、三节点集群机器配置
2.1 推荐机器配置
| 组件 | CPU | 内存 | 硬盘类型 | 网络 | 实例数量(最低要求) |
| TiDB | 16 核+ | 48 GB+ | SSD | 万兆网卡（2 块最佳） | 2 |
| PD | 8 核+ | 16 GB+ | SSD | 万兆网卡（2 块最佳） | 3 |
| TiKV | 16 核+ | 64 GB+ | SSD | 万兆网卡（2 块最佳） | 3 |
| TiFlash | 48 核+ | 128 GB+ | 1 or more SSDs | 万兆网卡（2 块最佳） | 2 |
| TiCDC | 16 核+ | 64 GB+ | SSD | 万兆网卡（2 块最佳） | 2 |
| 监控 | 8 核+ | 16 GB+ | SAS | 千兆网卡 | 1 |
2.2 生产配置参考
| 客户名称/业务系统 | tidb机器配置 xxG xxC | 每个机器几个tidb实例 | tikv机器配置 | 每个机器几个tikv实例 | tifalsh机器配置 | 磁盘是不是ssd (cat /sys/block/vda/queue/rotational) | 虚拟机/物理机 |
| 某客户 | 96G ,24C | 1 | 128G,64C | 2 | 128G,64C | 虚拟机 | |
| 某客户 | 32G 16C | 1 | 32G 16C | 1 | 无 | ssd | 虚拟机 |
| 某客户 | 32G 8C | 1 | 32G 8C | 1 | HDD | 虚拟机 |
三、 三节点集群架构
3.1 架构一
3 节点 3 tidb 模式，中控和监控共用一个节点。
优点：每个节点资源使用充分。
缺点：布置监控的机器负载可能会高一些。
暂时无法在飞书文档外展示此内容
3.2 架构二
3 节点 2 tidb 模式，2tidb 3pd 3tikv 部署中控和监控的节点不布置 tidb 实例。
优点：由于中控和监控节点少一个 tidb 实例各个节点的负载更平均一些。
缺点： 少一个 tidb 实例承载业务。
暂时无法在飞书文档外展示此内容
四、内存控制
4.1 TiDB 内存结构
TiDB实例内存结构主要分为两部分 SQL 语句占用内存、go语言占用内存
暂时无法在飞书文档外展示此内容
4.2 TiDB 实例内存参数
- OS 内存参数
绑定numa（虚拟机没有numa可忽略）
关闭透明大页（即 Transparent Huge Pages，缩写为 THP)
- tidb 实例内存参数
| 参数名称 | 适用版本 | 推荐值 | 作用域 | 默认值 | 参数含义 |
| tidb_mem_quota_query | >=v6.1.0 | SESSION | GLOBAL | 1073741824 (1 GiB) | V6.5以后该变量用来设置单个会话整体的内存使用限制，如果某个会话执行过程中使用的内存量超过该阈值，会触发系统变量 tidb_mem_oom_action 中指定的行为。其中包含事物占用的内存。 V6.5以前控制单个sql占用的内存。 | |
| memory-usage-alarm-ratio | GLOBAL | 0.7 | 这个变量用于设置触发 tidb-server 内存告警的内存使用比率。默认情况下，当 TiDB 内存使用量超过总内存的 70% 且满足报警条件时，TiDB 会打印报警日志。 | ||
| tidb_mem_oom_action | GLOBAL | CANCEL | CANCEL，LOG。 该变量控制当单个查询使用的内存超过限制 (tidb_mem_quota_query) 且不能再利用临时磁盘时，TiDB 所采取的操作。如果变量值为 LOG，那么当一条 SQL 的内存使用超过一定阈值后，这条 SQL 会继续执行，但 TiDB 会在 log 文件中打印一条 LOG。如果变量值为 CANCEL，那么当一条 SQL 的内存使用超过一定阈值后，TiDB 会立即中断这条 SQL 的执行，并给客户端返回一个错误信息中会详细写明在这条 SQL 执行过程中占用内存 | ||
| tidb_enable_rate_limit_action | OFF | SESSION | GLOBAL | OFF | 这个变量控制是否为读数据的算子tidb_distsql_scan_concurrency 所允许的最大线程数来读取数据，该变量在单条查询仅涉及读数据的情况下，对内存控制效果较好。若还存在额外的计算操作（如连接、聚合等），打开该变量可能会导致内存不受 tidb_mem_quota_query 控制，加剧 OOM 风险。 | |
| tidb_server_memory_limit | GLOBAL | 80% | 该变量指定 TiDB 实例的内存限制取值范围为 [1%, 99%]。TiDB 会在内存用量达到该限制时，对当前内存用量最高的 SQL 语句进行取消 (Cancel) 操作。在该 SQL 语句被成功 Cancel 掉后，TiDB 会尝试调用 Golang GC 立刻回收内存，以最快速度缓解内存压力 | ||
| tidb_enable_tmp_storage_on_oom | >=v6.3 | GLOBAL | ON | 设置是否在单条 SQL 语句的内存使用超出系统变量 tidb_mem_quota_query 限制时为某些算子启用临时磁盘,在 v6.3.0 之前这个开关可通过 TiDB 配置文件中的 oom-use-tmp-storage 项进行配置 | |
| tmp-storage-path | 默认值：<操作系统临时文件夹>/<操作系统用户ID>_tidb/xxx/tmp-storage。其中 xxxx 是对 <host>:<port>/<statusHost>:<statusPort> 进行 Base64 编码的输出结果。 | 单条 SQL 语句的内存使用超出系统变量 tidb_mem_quota_query 限制时，某些算子的临时磁盘存储位置。此配置仅在系统变量 tidb_enable_tmp_storage_on_oom 的值为 ON 时有效。 | |||
| tmp-storage-quota | -1 | tmp-storage-path 存储使用的限额,当单条 SQL 语句使用临时磁盘，导致 TiDB server 的总体临时磁盘总量超过 tmp-storage-quota 时，当前 SQL 操作会被取消，并返回 Out Of Global Storage Quota! 错误 |
4.3 tikv 内存结构
tikv 内存主要分为 3 部分，block-cache、write-buffer、coprocessor 三部分，block-cache 和 write-buffer 有参数可以控制，coprocessor 是慢sql出现积压的时候会占用大量内存不好预估。
4.4 tikv 实例内存参数
| 参数名称 | 默认值 | 推荐值 | 参数含义 | |
| storage.block-cache.capacity | 机器内存的40% | 机器内存的40% | storage.block-cache.capacity = (MEM_TOTAL * 0.5 / TiKV 实例数量) | |
| write-buffer-size | defaultcf 128MiB,writecf 128MiB, lockcf 32MiB | 默认值 | memtable默认参数固定大小，一般不用调整 |
4.5 tidb 和 tikv 内存参数设置
假如一个三节点集群采用3节点2tidb模式，如何分配 tidb 和 tikv 的内存参数。
ip |
单机节点部署情况 |
机器配置 |
磁盘规划 |
|---|---|---|---|
Host 1 |
中控/监控、1 * PD、1 * 1 * TiKV |
32G,16C |
1块500G (HDD) |
Host 2 |
1 * PD、1 * TiDB、1 * TiKV |
32G,16C |
1块500G(HDD) |
Host 3 |
1 * PD、1 * TiDB、1 * TiKV |
32G,16C |
1块500G(HDD) |
tidb 主要的内存参数 tidb_mem_quota_query ，tidb_server_memory_limit 这两个参数可以使用默认值
tikv 的主要内存参数是 storage.block-cache.capacity 这个参数取机器内存的 40%
| 组件 | 参数 | 参数值 |
| tidb | tidb_mem_quota_query | 默认 1G |
| tidb | tidb_server_memory_limit | 默认 80% |
| tikv | storage.block-cache.capacity | 12G |