表插入数据经常延迟很高, lock_rpc很大


执行计划如下:
id task estRows operator info actRows execution info memory disk
Insert_1 root 0 N/A 0 time:1.02ms, loops:1, prepare:252.2µs, check_insert: {total_time: 771.5µs, mem_insert_time: 135.9µs, prefetch: 635.6µs, rpc:{BatchGet:{num_rpc:1, total_time:601µs}, scan_detail: {total_process_keys: 0, total_keys: 1, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 5, read_count: 0, read_byte: 0 Bytes}}}}}, lock_keys: {time:8.98s, region:2, keys:2, lock_rpc:8.976444878s, rpc_count:2} 965 Bytes N/A

索引信息:PRIMARY KEY (lid,create_time) /*T![clustered_index] NONCLUSTERED */
会是哪方面的问题呢?

1赞

可以给出个详细的执行计划么,手动执行也这么慢么,explain analyze看下,感觉有可能是mem 转sst的时候忙不过来了,写热点,或者其他问题

1赞

另外说明下explain analyze是真实执行的,建议找张备份表来做这个操作

1赞

不是全部都这么慢,但出现的频率也很高,explain analyze执行结果如下:
±---------±--------±--------±-----±--------------±----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±--------------±----------±-----+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±---------±--------±--------±-----±--------------±----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±--------------±----------±-----+
| Insert_1 | N/A | 0 | root | | time:3.19ms, loops:1, prepare:71.1µs, check_insert: {total_time: 3.12ms, mem_insert_time: 69.1µs, prefetch: 3.05ms, rpc:{BatchGet:{num_rpc:2, total_time:2.96ms}, scan_detail: {total_process_keys: 2, total_keys: 7, rocksdb: {delete_skipped_count: 0, key_skipped_count: 5, block: {cache_hit_count: 8, read_count: 0, read_byte: 0 Bytes}}}}} | N/A | 816 Bytes | N/A |
±---------±--------±--------±-----±--------------±----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±--------------±----------±-----+

集群信息如下:


目前接入的数据还很少,QPS还只有100多,写热点可能性应该比较小,但是内存占用好高,mem 转sst是啥?

1赞

我简写的,写入的时候,会又内存转存到磁盘,如果这个工作过多,忙不过来就会造成WriteStall,限制流量了,所以就慢了,具体分析还要看下插入慢的时间段的具体监控,tikv details里面的thread cpu相关的监控项,磁盘io的监控可以发出来看看

1赞

image
不过写入的并发比较集中,每隔十几分钟运行一次,每次在1-3分钟之内,该表要写入3k多条记录

1赞

%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_7b52c355-c81e-4c21-afa4-6d9dda8abc98 %E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_e4c7e415-7527-4062-8b9b-35c5b5f89376

如果对于性能上有要求的话,表设计的模式就应该直接上 聚簇索引了

如果有量级insert,应考虑 batch 的方式,这样效率会更高
可以参考:
https://docs.pingcap.com/zh/tidb/stable/java-app-best-practices#使用-batch-批量插入更新

https://www.tutorialspoint.com/jdbc/jdbc-batch-processing

1赞

我先试试把主键改成AUTO_RANDOM

AUTO_RANDOM 就必须 聚簇索引了

https://docs.pingcap.com/zh/tidb/stable/auto-random/
https://pingcap.com/zh/best-practice-detail/high-concurrency-best-practices

1赞

看监控像是单台机器写入热点问题,目前看压力在commiy log 这块,可以看下之前提到的thread cpu使用情况和总的cpu使用情况,如果总的cpu小,而thread cpu跑满了,可以调优下相关参数

改成用聚簇索引和batch insert了,改善效果很明显:heart:,现在batch insert偶尔还会出现1-2s耗时

改成聚簇索引和批量插入后观察了2天,还是有20%的概率出现比较高延迟,具体情况如下:
id task estRows operator info actRows execution info memory disk
Insert_1 root 0 N/A 0 time:11.8ms, loops:1, prepare:1.26ms, check_insert: {total_time: 10.6ms, mem_insert_time: 3.76ms, prefetch: 6.83ms, rpc:{BatchGet:{num_rpc:5, total_time:10.9ms}, scan_detail: {total_process_keys: 300, total_keys: 810, rocksdb: {delete_skipped_count: 0, key_skipped_count: 300, block: {cache_hit_count: 2560, read_count: 0, read_byte: 0 Bytes}}}}}, lock_keys: {time:8.55s, region:4, keys:210, lock_rpc:25.634092514s, rpc_count:4} 164.1 KB N/A

id task estRows operator info actRows execution info memory disk
Insert_1 root 0 N/A 0 time:6.61s, loops:1, prepare:499.9µs, check_insert: {total_time: 6.61s, mem_insert_time: 1.41ms, prefetch: 6.61s, rpc:{BatchGet:{num_rpc:5, total_time:13.2s}, scan_detail: {total_process_keys: 100, total_keys: 210, rocksdb: {delete_skipped_count: 0, key_skipped_count: 40, block: {cache_hit_count: 469, read_count: 0, read_byte: 0 Bytes}}}}}, lock_keys: {time:23.6ms, region:4, keys:70, lock_rpc:38.845329ms, rpc_count:4} 54.7 KB N/A

表信息:


求帮忙看看还可以往哪些方面优化:heart:

仅仅是insert ,然后每次batch 都是随机条数,性能差距很大,还是很接近?

基本上要从多个点考虑:

  1. 硬件性能是否有瓶颈
  2. 网络是否有瓶颈
  3. 目前的资源配置是否合理,不合理可能需要调整

这个要查阅granfa 一些指标信息,要做一些调整了

  1. tidb -> tikv rpc 网络延迟排查
  2. tikv -> raft propose 处理延迟排查
  3. tikv -> apply value 处理排查

最好你自己先排查一下,然后汇总一些问题点,看看怎么帮助你

另外可以参考,将问题比较突出部分的一些资源信息导出

建议你新开一个帖子 :grinning: