Alert: Large Number of tidb_tikvclient_backoff_seconds_count

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

Original topic: 告警大量的tidb_tikvclient_backoff_seconds_count

| username: jeff

[TiDB Usage Environment] Production Environment
[TiDB Version] 4.0.13
[Encountered Problem: Phenomenon and Impact]
A large number of tidb_tikvclient_backoff_seconds_count alerts, and a lot of Write conflict in the tidb logs. Does anyone have a solution? Additionally, how can I find the table name corresponding to tableid 299 in the logs?
[Attachments: Screenshots/Logs/Monitoring]



| username: undefined | Original post link

Optimistic mode?

| username: jeff | Original post link

Got it! Please provide the Chinese text you need translated.

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

This is caused by slow SQL.

| username: jeff | Original post link

How to find the table name based on the table ID?

| username: h5n1 | Original post link

TiDB Lock Conflict Troubleshooting

| username: 啦啦啦啦啦 | Original post link

It has nothing to do with slow SQL.

| username: 裤衩儿飞上天 | Original post link

select `TIDB_TABLE_ID`, TABLE_SCHEMA, TABLE_NAME from INFORMATION_SCHEMA.`TABLES` where TIDB_TABLE_ID=XXXXX;
| username: 啦啦啦啦啦 | Original post link

The number of retries when an error occurs while accessing TiKV. If this error is not particularly frequent, it can be ignored, or the threshold can be increased.
There is a table id in INFORMATION_SCHEMA.TABLES.

| username: jeff | Original post link

It always reports around 200 each time.

| username: 啦啦啦啦啦 | Original post link

Is it possible that batch operations are causing frequent region changes? We are ignoring warnings and only sending error alerts. Generally speaking, this warning does not affect the business.

| username: 像风一样的男子 | Original post link

For a while, I also frequently encountered this warning, but it disappeared after upgrading the KV configuration.

| username: jeff | Original post link

Looking at the documentation, this is normal. It’s just that the concurrency is too high.

| username: redgame | Original post link

Try changing the value of the tikv-client.commit-timeout parameter, for example, adjusting it from the default value to a larger value, such as 120s. This can increase the transaction commit timeout.

| username: undefined | Original post link

In general, in such cases, you will definitely see this table on the heatmap. The read and write volumes should be quite large, so consider splitting the business.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.