课程名称：性能调优 - 故障排查实战
学习时长：30
课程收获：
课程内容：
-
CPU瓶颈
-
CPU使用率是否很高
A) 应用端的CPU是否很高
B) TiDB端的CPU是否很高
C) TiKV端的相关模块是否导致CPU使用率很高 -
CPU的负载是否很高
A) 应用端的进程或者线程是否很多导致，占用了CPU资源
B) TiKV的iowait是否很高 -
IO瓶颈
-
IOPS限制
A) 1TB ebs gp 2的容量有3000 IOPS的限制
B) 读请求会消耗较多的IOPS，可以适当地调大block-cache size -
IO的带宽限制
A) 一个ebs gp 2有250MB/S的限制
B) TikV压缩流将读取SST文件和写SST文件, 这将消耗大量的lO带宽，我们可以为压缩设置一个速率限制: [rocksdb] rate-bytes-per-sec =“100MB”
C) 范围查询也会消耗较多的IO带宽 -
网络瓶颈
-
应用服务器和TiDB服务器之间的网络
-
TiKv服务器和TiDB服务器之间的网络
-
关于瓶颈的实际例子
-
TiDB的NUMA问题:
现象：TiDB的CPU使用率不高，但是PD TSO Wait Duration和SQL Compile duration的值很高，接近100ms
分析：
根本原因:用户告诉我们，TiDB部署在16 核VM上，这些16核跨2 NUMA节点，所以条件NUMA分布就解决了问题。 -
TiDB的CPU限制
现象：
分析:
延迟随着qps的增加而增加，这意味着某些组件可能会遇到瓶颈 ，TiKV CPU使用率和LO使用率远离瓶颈，TiKV表示其RPC速度快，因此瓶颈不在TikV方面， PD表示其延迟较低，但TiDB表示pd tso等待时间较高，瓶颈可能位于tidb侧，或者网络延迟较高。但是网络延迟较低，瓶颈可能在TiDB端。TiDB所在实例的CPU使用率约为20%以上，远离瓶颈。
根本原因：TiDB因为设置max-proc参数为8，导致了限制了CPU的使用，最终将此值设置为0，解决了问题 -
TiKV的CPU到达瓶颈
现象: CPU的usage很高
分析：大部分CPU都是消耗在Coprocessor这个模块里面
根本原因：看执行计划发生了全表扫描，没有建立对应的索引，所以添加索引后问题解决
4. TiKV的磁盘瓶颈
现象：写延迟比较高，TiDB/TiKV/PD的cpu使用率较低
分析：
我们还可以看到“写失速”事件，这是一个重要的信号，表明磁盘可能不堪重负。 根本原因：磁盘写入速度无法满足业务，扩容可以解决此问题
学习过程中遇到的问题或延伸思考：
- 问题 1：
- 问题 2：
- 延伸思考 1：
- 延伸思考 2：