I want to ask why an insertion takes 300ms, what is causing the delay?

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 想问一下一个插入要300ms 是什么卡住了

| username: tidb狂热爱好者

I want to ask why an insert takes 300ms, what is causing the delay?

Insert_1 root 0 N/A 0 time:326.1ms, loops:1, prepare: {total: 325.7ms, auto_id_allocator: {rebase_cnt: 19, Get:{num_rpc:76, total_time:35.3ms}, total_process_time: 5ms, total_wait_time: 3ms, scan_detail: {total_process_keys: 76, total_process_keys_size: 212363, total_keys: 76, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 724, read_count: 0, read_byte: 0 Bytes}}}, commit_txn: {count: 19, prewrite:110.1ms, get_commit_ts:33.4ms, commit:110.4ms, region_num:19, write_keys:19, write_byte:1045}}}, insert:417μs, lock_keys: {time:821.3μs, region:1, keys:30, lock_rpc:767.996μs, rpc_count:1} 61.6 KB N/A

[TiDB Usage Environment] Production, Testing, Research
[TiDB Version]
[Encountered Problem]
[Reproduction Path] What operations were performed to encounter the problem
[Problem Phenomenon and Impact]

[Attachments]

Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.

2
| username: xfworld | Original post link

Why are there both insert and query actions?

Get: {num_rpc: 76, total_time: 35.3ms}
scan_detail: {total_process_keys: 76, total_process_keys_size: 212363, total_keys: 76, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 724, read_count: 0, read_byte: 0 Bytes}}}

3
| username: tidb狂热爱好者 | Original post link

There is a WHERE clause.

4
| username: h5n1 | Original post link

It’s still the time spent during the commit phase. Check the network and disk I/O.

5
| username: tidb狂热爱好者 | Original post link

This feels like a code issue.

6
| username: jansu-dev | Original post link
  1. What does the SQL statement look like?
  2. total_process_keys_size: 212363, is this expected behavior? How many numbers are expected to be fetched from TiKV? Is GC normal?
  3. prewrite: 110.1ms and commit: 110.4ms are the main time-consuming parts. We need to look at the overall write flow of TiDB in conjunction with monitoring to see where problems might occur.
7
| username: 特雷西-迈克-格雷迪 | Original post link

It also depends on whether the code business logic has been submitted in a timely manner.