Day17
Tidb Server 优化
操作系统参数
- CPU
Frequency Scaling，避免动态调整，让CPU处在一个较高性能的环境，命令：cpupower frequency-set –governor performance
Numa Banding，避免numa架构下出现跨numa节点访问内存，需要将进程和CPU进行绑定，用numactl进行绑定 - Memory
Transparent Huge Page(THP)，建议关闭此选择，避免出现内存访问延迟或者碎片规整带来的CPU占用率徒增的情况
Virtual Memory Parameters
dirty_ratio: 默认值是20%，在高性能SSD硬盘如NVMe设备，可以适当调低此值来改善内存回收的效率
dirty_background_ratio: 默认值是10%，在高性能SSD硬盘如NVMe设备，可以适当调低此值来改善内存回收的效率 - Disk
I/O Scheduler，对于SSD硬盘，建议设置为noop，操作命令echo noop > /sys/block/$SSD_DEV_NAME/queen/scheduler
Mount parameter, noatime选项可以防止读取文件的时候更新元数据，nodirtime选项可以防止读取目录的时候更新元数据
Tidb系统变量
- Concurrency
tidb_distsql_scan_concurrency: 影响很多SQL语句，在系统比较空闲时，调整此参数可以增加TiKV访问region的并发数，提升访问速度，默认值是15，如果是OLTP系统可以调小一些，如果是OLAP系统可以调大一些，也可以通过观察执行计划table scan/index scan耗时较高的时候进行调整
tidb_index_lookup_concurrency：影响很多SQL语句，在系统比较空闲时，调整此参数可以增加TiKV访问region的并发数，提升访问速度，默认值是4，如果是OLTP系统可以调小一些，如果是OLAP系统可以调大一些，也可以通过观察执行计划indexLookUp耗时较高的时候进行调整
tidb_build_stats_concurrency: 是用来控制Analyze语句的并发度的 tidb_hash_join_concurrency: 是用来控制hash join算子的并发度tidb_index_lookup_join_concurrency: 是用来控制index lookup join算子的并发度
tidb_ddl_reorg_worker_cnt: 是用来控制在线添加index时worker的数量，来提升添加index的速度 - Batch Size
tidb_init_chunk_size: 初始的chunk_size，默认值是32，就是一个批次查询最小单位返回32行，如果返回的行低于这个值，会浪费很多内存资源
tidb_max_chunk_size: 最大的chunk_size，默认值是1024，如果第一次查询后发现后面还有数据行，则会通过此参数来返回剩下的行数
tidb_index_join_batch_size: 控制index join的批次size，如果size大，消耗的资源也会多 - Limit
tidb_store_limit: 控制发送给一个TiKV节点上请求的数量，该参数设置太小，可能资源浪费，设置过高，负载过高
tidb_retry_limit: 乐观事务控制的最大重试数量，重试太多会导致性能下降，重试太少乐观事务成功率下降
目前事务模式默认为悲观。
- Backoff
tidb_backoff_weight: 这个参数会影响不同类型的backoff
tidb_backoff_lock_fast: 一次读请求等待锁的backoff时间，如果设置时间过长，会导致此次读请求耗时过高
Tidb配置文件参数
- Performance
max-proc: TiDB可以使用的最大CPU核数
token-limit: 控制同时可以执行请求的数量
force-priority: 设置所有语句的优先级，针对特殊用途的tidb实例可以配置低优先级的语句执行
commiter- concurrency: 控制一个事务二阶段提交的时候最大并发数量，主要是针对100MB以上的大事务 - TiKV Client
grpc-connection-count: 控制每个TiKV和TiDB的最大连接数 - Prepared Plan Cache
Enabled：启用的话，可以重复利用执行计划，避免每次生成执行计划增加开销，可以用prepare语句检查是否开启
Capacity：缓存语句的数量
TiKV Server 优化
1TiKV的架构
2TiKV的请求流程
写请求流程
涉及的线程池参数配置
[storage]
Scheduler-worker-pool-size=4
[raftstore]
Store-pool-size=2
Apply-pool-size=2
分析写请求的瓶颈，通过以下指标
Scheduler worker CPU，如果持续使用超过80%的时候，建议扩容(4就是400)
如果上面指标没有问题，那就判断是否慢在了raftstore，可以查看写延迟指标Storage async write duration
如果上面指标依然没有问题，接下来分析瓶颈是否出现在consensus层，可以通过raft store cpu和async apply CPU两个指标来看，如果比较高，可以通过调整store-pool-size和apply-pool-size两个指标进行调整
如果上面指标也没有问题，那就查看储存层，看看IO是否达到瓶颈，可以通过Write duration和Write stall duration两个指标来看，以及查看Disk Load和Disk IO untilration两个指标
检查负载是否比较高，CPU Usage, Load Average
IO是瓶颈 cpu还有剩余，可以考虑cpu资源换取IO资源
主要方式为调整压缩级别,提高压缩级别可以减少IO的消耗 增加cpu小号
如果rocksdb出现了问题，并且IO和CPU都不是瓶颈
太多的level0文件—level0层文件不排序
太多的memtables—他会刷倒level0层 过多说明数据大多在内存
太多的等待字节
[rocksdb]
Max-background-jobs= 8 #How many threads for background jobs
Max-sub-compactions=3 #Threads for compaction of level0
[rocksdb.defaultcf]/[rocksdb.writecf]
Compression-per-level=[“no”,”no”,”lz4”,”lz4”,”lz4”,”zstd”,”zstd”]
Level0-file-num-compaction-trigger=4
Level0-shutdown-writes-trigger=20
Level0-stop-writes-trigger=36
如果上述都没有瓶颈，那就需要观察一下网络是否存在瓶颈，查看commit log duration和99% commit log duration per server，raftstore.raft-max-inflight-msgs和raftstore.raft-max-size-per-msg两个参数进行调节
读请求流程
分析读请求的瓶颈，Thread CPU的Unified read pool CPU，可以适当提高readpool.unified.max-thread-count参数值
等待时间很高造成瓶颈，可以看是否有大范围scan，负载是否均衡，线程池是否太小，错误的执行计划
看block cache hit，如果命中率太低，可以调大storage.block-cache.capacity的大小