为什么rpc耗时很长，需要怎么优化

🪐 TiDB 技术问题 性能调优
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：5.7.25-TiDB-v4.0.0
  • 【问题描述】：
    image
    image1352×143 4.92 KB

    sql执行信息IndexLookUp：
    time:28.087632813s, loops:2, rpc num: 16, rpc max:3.482227939s, min:1.004491ms, avg:234.040057ms, p80:35.467364ms, p95:3.482227939s, proc keys max:73805, p95:73805

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。

2
  1. 麻烦发送下执行的sql语句 ， 如果是查询语句吗？再执行一次 explain analyze sql ，反馈完整的执行计划，多谢。
  2. 表结构如果方便，麻烦也发送下，多谢。
3

SELECT count(0) FROM A a WHERE a.ISDELETE = 0 AND a.cid IN (‘11111’,‘22222’,‘33333’,‘44444’,‘55555’,);
闲时执行时间大概是432毫秒；多用户并发情况下，导致的耗时延长50多倍的时间。
查询条件isdelete字段类型tinyint(4)，cid字段类型int(11)，A表有50多个字段，没有大字段。ana.xlsx (15.2 KB)

4
  1. 麻烦发送下问题发生时的 over-view，tidb，detail-tikv 日志，可以使用如下方法，采取长图

(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

  1. 麻烦您再发送一个执行时间快时的 执行计划，多谢。

  2. 请问这个索引 table:a, index:INDEX_DESIGNMATERIAL_CID(categoryid) 具体是哪些列组成的？

5

【TiDB 版本】3.0.6
【问题描述】：
换了个环境，sql不变，压测20并发持续1分钟。
1、监控数据：

screencapture-10-1-25-168-3000-d-eDbRZpnWk-slave-cluster-overview-2020-06-10-10_38_20
screencapture-10-1-25-168-3000-d-eDbRZpnWk-slave-cluster-overview-2020-06-10-10_38_201920×7059 2.09 MB
/

2、执行快的执行计划：

image
image3202×116 6.21 KB

3、执行慢的执行计划：
image
image3197×110 6.35 KB
/

4、慢查询结果：查询越查越慢，单独查询只需要一百毫秒左右

image
image1275×348 20.3 KB

5、走的索引是：idx_designmaterial_organid_cid
由organid和categoryid的组合索引，catagoryid为int类型，organid为varchar

6
  1. 查看监控在这个时间段，duration 上升很明显，执行计划相同，如果慢是在这个时间段，就是系统负载高

image
image1642×473 100 KB

  1. 如果是这个时间段，麻烦上传 trouble shooting 监控的 read slow 和 write slow 监控，多谢。
7

今天一共压测了3次，每次duration都会上升，其中一个是我每秒并发10个用户持续30秒造成，一个是我每秒并发20持续30秒造成

image
image887×264 40.5 KB

8

后面换过环境的tidb的版本是3.0.6。
三次的压测查询都集中在同一台tikv

image
image922×401 50.6 KB

9
  1. 发一下上面需要的监控信息？
  2. 可以看下上游查询是否都是相似查询，比如select * from xx where xx=a ，所有条件都是一样的，或者访问的范围都很小在一个连续区间，导致读热点。
  3. 可以搜一下 热点 查看下分析的文章，多谢。
10
  1. trouble shooting 监控的 read slow 和 write slow 监控信息怎么查
  2. 部署的tidb集群只接入一个应用，它的查询只有个位数，只有同步数据；主要是做了压测，才导致的cpu飙高
  3. 有热点读的文章链接推荐不
11

  1. 在监控项选择一下

    image
    image638×700 33.5 KB

  2. 是因为有压测，所以如果并发都去读相同的数据，可能就会有热点

  3. 热点 你可以在搜索框搜一下关键字，看看结果文章，多谢。