Occasionally, when executing delete or update, the Coprocessor execution takes a long time until it times out

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

Original topic: 偶尔出现执行 delete或者 update 的时候,Coprocessor 执行耗时很长,直到超时

| username: TiDBer_pcHqOtU9

[TiDB Usage Environment] Production Environment
[TiDB Version] v5.3.0
[Reproduction Path] Occurs occasionally, relatively frequently over a period of time
[Encountered Problem: Phenomenon and Impact]
When executing delete or update, the Coprocessor execution takes a long time until it times out. Indexes have been added. This issue does not always reproduce, it appears occasionally. This problem greatly affects business operations. From which aspects should this issue be investigated?
[Resource Configuration]

[Attachments: Screenshots/Logs/Monitoring]

| username: caiyfc | Original post link

Check if there is a lock conflict, it seems like a read-write conflict.

| username: tidb菜鸟一只 | Original post link

It seems that there is a problem with the SQL wait details displayed on the 5.3 dashboard. According to your screenshot, the wait time for the lock is 0, but in reality, it is probably still a lock issue.

| username: TiDBer_pcHqOtU9 | Original post link

When the issue occurred, I specifically checked information_schema.data_lock_waits and did not find any records.

| username: xfworld | Original post link

Is there any special information in the last two tabs?

| username: weixiaobing | Original post link

The default timeout for the database is 50 seconds. It might have timed out based on the execution time. Check the database logs.

| username: 胡杨树旁 | Original post link

It should be that the transaction was not committed, causing a lock conflict. This SQL has been waiting and will roll back by itself after the default 50 seconds.

| username: Hacker_ufuLjDKs | Original post link

Top, I’m just here to watch the fun.

| username: TiDBer_pkQ5q1l0 | Original post link

It should be lock waiting.