【TiDB 4.0 PCTA 学习笔记】- 3.7.9 Peformance Tuning - troubleshooting examples @1班+李墨白

☄️ 学习与认证 经验&心得&笔记
1

课程名称：课程版本（101/201/301）+ 3.7.9 Peformance Tuning - troubleshooting examples

学习时长：

60min

课程收获：

了解常见的瓶颈类型，如何对常见问题进行排查

课程内容：

一、Common Bottlenecks

  1. CPU band
  • CPU使用率高
    • 应用端：使用率超过80%，瓶颈在应用端，需要添加更多的应用服务器来解决
    • TiDB Server端：使用率超过80%，瓶颈在TiDB Server端，需要拓展TiDB Server来解决
    • TiKV端：整体CPU不能超过80%，尽量在75%以下因为是存储加计算节点，有时会因为IO等待导致CPU使用率并没有那么高
    • TiKV components：线程池CPU使用率是否过高成为瓶颈，gRPC、unified theread pool、raftstore pool、apply pool
  • CPU load高
    • 应用端：进程或线程过多，导致上下文切换高导致load高，建议优化应用端的进程或线程数
    • TiKV端：如果IO比较慢，整体等待IO，也可能出现load高，磁盘出现瓶颈，建议关注磁盘或是否存在高写入问题
  1. IO band
  • IOPS限制
    • 磁盘本身的IOPS上限
    • TiDB系统（特指主要操作的TiKV），读请求会消耗大量IOPS，建议关注block-cache size，如果内存有容量建议优化此参数提高命中率
  • IO带宽限制
    • 磁盘本身带宽上限
    • TiKV Compaction flow会出现读写放大，建议优化[rocksdb] rate-bytes-per-sec参数
    • Range scan requests也会占用较大带宽，例如：SELECT * WHERE range BETWEEN X AND Y
  1. Network band
  • 应用端到TiDB端
  • TiKV端与TiDB端直间

二、Examples

  1. TiDB NUMA issue
  • Phenomenon：
    TiDB CPU使用率不高，但“PD TSO Wait duration”和“SQL Compile duration”较高，超过100ms
    image
  • Analysis：
    • 这两个没有直接相关的参数高，问题很可能出现在TiDB内部
    • 使用“go trace”查看
      curl：http://127.0.0.1:10080/debug/pprof/trace?seconds=20 > trace.out
      go tool trace trace.out
      image
    • 我们可以看到GC间隔达到50ms至60ms，存在内存访问慢的可能性
  • Root Cause
    • TiDB建立在16c的VM上，跨了两个NUMA node，存在交叉访问，导致访问开销
    • 通过将16c都建立在1个NUMA node上，从而防止交叉访问导致的开销解决
  1. TiDB CPU Limitation
  • Phenomenon
    • 查询延迟随着QPS增长而增长的
    • TiKV的CPU和IO使用比较低
    • PD显示延迟低，但TiDB显示“PD TSOwait duration”较高
    • 网络延迟较低
  • Analysis（TiDB显示的“PD TSOwait duration”包括的几个阶段）：
    • TiDB发起请求但可能卡在自己内部
    • TiDB发起请求通过网络到PD
    • PD收到请求处理完成通过网络返回TiDB
    • TiDB接收到请求进行处理（存在延迟处理）
    • 通过以上几个阶段分析问题出现在TiDB，但TiDB的CPU使用率并不高，也不是NUMA问题
  • Root cause
    • 查看TiDB的CPU使用限制参数（[performance] max-procs = 8）
    • 因为CPU限制使用导致TiDB的CPU使用率偏低，无法通过增加并发、QPS连接数等方法解决
    • 通过设置此参数为0解决，为0代表没有限制
  1. TiKV CPU Limitation
  • Phenomenon
    • TiKV的CPU到达瓶颈，其中一条蓝线始终处于600%状态
      image
  • Analysis
    image
    • 大部分CPU消耗在Coprocessor，示例中8c机器默认配置6c已经到Coprocessor瓶颈
    • 进一步查看TiDB端是否有slow log
    • 分析slow log

image.png
image.png821×136 98.1 KB

  • 发现一条SQL未选索引，而使用全表扫描
  • Root cause
    • 发现此表在相关字段上未添加索引，通过添加索引解决问题
  1. TiKV Disk Band
  • Phenomenon
    • 写入延迟高
    • TiDB/TiKV/PD的CPU消耗低
  • Analysis
    • 查看gRPC latency高，确认问题主要出现在TiKV
    • 查看TiKV的CPU并不高，不是CPU瓶颈
    • 查看write duration和read(seek/get) duration非常高，正常应该在毫秒级别
      image
    • 查看发现“write stall”events问题，此问题出现一般是由于数据整理慢于业务写入
      image
  • Root cause
    • 查看IO整体情况，发现IO到达非常高水位线、CPU整体相对较好
      image
    • 通过增加TiKV节点解决

学习过程中遇到的问题或延伸思考：

  • 问题 1：
  • 问题 2：
  • 延伸思考 1：
  • 延伸思考 2：

学习过程中参考的其他资料

2

同学你好，感谢参与 TiDB 4.0 课程的学习！

本篇笔记逻辑清晰、内容丰富，被评选为优质笔记，将额外获得 20 积分，并在 「TiDB 培训」分类下获得“置顶”权益，积分兑换规则将于近期开放，敬请关注！

期待您继续产出优质内容！

4

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。