网站建设如何找客户抖音宣传推广方案
操作系统参数
CPU
对于数据库系统，选择时刻CPU以高性能(performance)的方式工作。
Dynamic Frequency Scaling
CPU动态节能技术用于降低服务器功耗，通过选择系统空闲状态不同的电源管理策略，可以实现不同程度的降低服务器功耗。更低的功耗策略意味着CPU唤醒更慢、对性能影响更大。数据库服务器一定要设置为performance模式。
- DFS有以下五种模式：performance|userspace|powersave|ondemand|conservative。
- 配置命令为：
$ cpupower frequency-set --governor performance
NUMA Binding
内存直接绑定在CPU上，CPU只有访问自身管理的内存物理地址时，才会有较短的响应时间。NUMA架构的服务器，通过绑定NUMA节点，尽可能地避免跨NUMA访问内存，提升tidb server性能。
可使用numactl命令绑定。
以独占的方式享用CPU-Numa Binding
内存
Transparent Huge Page
对于数据库，不建议使用透明大页（THP）。因为数据库往往具有稀疏而不是连续的内存访问模式，且当高阶内存碎片化比较严重时，分配THP会出现比较大的延迟。若开启针对THP的直接内存规整功能，也会出现系统CPU使用率激增的现象，因此建议关闭THP。
Virtual Memory Parameters
内存参数dirty_ratio和dirty_background_ratio通常无需调整。对于高性能SSD，比如NVMe设备来说，降低其值有利于提高内存回收时的效率。
磁盘IO
I/O Scheduler
I/O调度程序确定IO操作何时在存储设备上运行以及运行多长时间。常用的IO Scheduler包括NOOP、CFQ、DEALINE。
TiDB中使用的是NOOP，其IO调度方式类似一个FIFO队列。
- SSD 建议使用NOOP 机械盘建议使用DEADLINE
Mount Parameters
默认方式下，Linux中文件系统在文件被创建、访问、修改时都会记录一些时间戳，比如最近一次被修改的时间mtime、最近一次被访问的时间atime、最近一次文件状态发生改变的时间ctime，这在绝大部分场合都是没有必要的。
- 可以使用noatime和nodiratime禁止记录最近一次访问的时间戳。
TiDB配置参数
Performance性能参数
-
max-proc
max-proc: 控制tidb使用的CPU核数，在单台机器部署多个tidb-sever设置这个变量可以限制tidb-server使用的资源，避免对其他进程造成影响。
-
token-limit
token-limit: 配置可以同时执行请求的session的数量，用于流量控制，避免并发请求数过多造成tidb-server资源耗尽，服务无法响应。这个类似其他类型数据库中max_connection参数
注意：超过的可以连上，但会阻塞在那，没有响应 -
force-priority
控制tidb server的优先级。设置后，所有请求都是使用该优先级来执行。如果tidb server主要处理响应时间要求比较高的请求，可以配置为NO_PRIORITY；反之，如果是主要处理响应时间要求比较低的请求（比如OLAP、导数操作），则可以配置为LOW_PRIORITY。
-
committer-concurrency
控制一个事务commit阶段的最大并发数量。对一个大事务来说，提交事务需要想TiKV发送大量写请求。设置更大的并发可能让大事务更快提交完成，但也可能造成TiKV瞬时压力过大，请求堆积，无法响应。
TiKV Client相关参数
- grpc-connection-count
grpc-connection-count: 设置TiDB和每个TiKV之间的grpc连接数量，当大量并发请求发送到一个grpc连接的时候，单个gRPC连接串行发送请求，可能会成为瓶颈，当gRPC连接成为瓶颈时，设置更大的gRPC连接数可提升性能，但代价是更多消耗系统资源。
Prepared Plan Cache
- enabled: 开启后减少执行计划造成的计算开销，让同类型的语句使用相同的执行计划，提升性能，代价是当数据或查询条件变化时，执行计划可能会不是最好的
- capacity: 用来限制cache 的大小(缓存条数)，避免占用过多内存，如果应用使用了大量不同类型的请求，超过了capacity上限，plan cache的效果会打折扣。
TiDB系统参数
Concurrency
系统资源空闲较多时，设置更高并发度让资源利用的更充分，可以提升整体性能，但是更高并发往往消耗更多系统资源，在资源紧张时候反而会降低整体性能
| 属性 | 含义 |
|---|---|
| tidb_distsql_scan_concurrency | 控制TableScan和IndexScan算子的并发度 |
| tidb_index_lookup_concurrency | 控制IndexLookUp算子的并发度 |
| tidb_build_stats_concurrency | 控制Analyze执行的并发度，可能会影响在线业务的延迟 |
| tidb_hash_join_concurency | 控制HashJoin算子的并发度 |
| tidb_index_lookup_join_concurrency | 控制IndexLookUpJoin算子的并发度 |
| tidb_ddl_reorg_worker_cn | t 控制DDL加索引的并发度 |
Batch Size
一个Chunk 包含多行数据，SQL语句执行时，执行器以Chunk为单位来执行获取数据、表达式求值和JOIN等操作，当结果集较大时，更大的Chunk size可提升性能，如果结果集很小，小于Chunk size，申请过大chunk的内存会造成性能的损失。
tidb_init_chunk_size/tidb_max_chunk_size: 默认提取的行数/最大的提取行数。TiDB当中有个自适应的过程。tidb_init_chun_size用于设置chunk中初始的数据行数，默认为32。TiDB在读取结果集时会自适应地调整chunk size，但最大也不会超过tidb_max_chunk_size，其值默认为1024。
tidb_index_join_batch_size: 每次不是一行一行的匹配，是一次性批量匹配。TiDB中表连接操作时，也是采用了多行数据的批处理，而不是一行一行地匹配。表连接批处理中使用的chunk大小由参数tidb_inidex_join_batch_size控制。
Limit
- tidb_store_limit
控制同时发往一个tikv节点的请求数量。避免单个tikv因为请求量过大，超过处理能力，导致大量请求超时或者返回错误。
- tidb_retry_limit
tidb_retry_limit: 控制乐观事务的重试次数(对悲观事务无效)，乐观事务在遇到事务冲突的时候会进行重试，但是重试次数过多会使冲突加剧，造成性能下降，重试次数太少会造成事务执行成功率下降。
Backoff
在请求遇到可重试的错误时，在重试前需要等待一段时间，这个时间设置的过大，会增大延迟，如果设置的过小，会造成很多无谓的重试，消耗过多的资源。
backoff种类还是比较多，例如因为网络问题，需要等待获得PD分配的TSO。或者leader 转移到其他节点，获取数据的时候发生缓存失效等情况。
backupoff 是tidb的一个正常行为，不是错误
-
tidb_backoff_weight:backoff最大时间的权重，通过这个变量来调整最大重试时间。如果重试时间设置为15s，
tidb_backoff_weight等于2，那么实际重试时间为30s。 -
tidb_backoff_lock_fast: 读请求遇到锁的backoff 时间。