Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 偶发加锁时间长
|
username: 今天不想写代码
[TiDB Usage Environment] Production Environment
[TiDB Version] 6.5
[Reproduction Path] Occasional
[Encountered Problem: Problem Phenomenon and Impact]
Occasional long duration for update by id, upon checking the execution process, it was found that the locking time is long.
[Attachments: Screenshots/Logs/Monitoring]
Check the monitoring, go to tikv → scheduler → prewrite and see if the latch wait duration is long?
Is the cluster status normal? Are pessimistic memory locks and pipelined locking enabled?
Normally, how can I check if these two mentioned locks are enabled? I started using them with the default configuration.
Have you configured basic auth for Prometheus? Or did you forget the Grafana password?
By default, it is enabled. If the business logic does not require pessimistic locking extensively, you can set the global mode to optimistic locking and manually enable it in transactions that require pessimistic locking. You can refer to the documentation:
You can refer to this and give it a try: Prometheus|云原生|grafana的admin用户密码重置备忘记录_grafana密码忘记了-CSDN博客
Navigate to the /usr/share/grafana/bin directory
grafana-cli admin reset-admin-password xxxx
If Prometheus has basic auth enabled, modify the file specified by the Prometheus startup parameter --web.config.file, refer to this article, and then restart Prometheus.
If you forgot the Grafana password, refer to the reply from the expert above.
Grafana CLI admin: ‘reset-admin-password’ is not a Grafana CLI admin command. See ‘./grafana-cli --help’.
Is it possible to perform lock troubleshooting to see what the issue is?
Add more monitoring. This is ops, representing the amount for this scheduler. Also, check the wait duration to see how much it is.
Additionally, post the total CPU and thread CPU for review.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: