压测过程中疑似遇到锁饥饿问题？

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.3.1
【问题描述】
使用 sysbench oltp_write 压测，压测过程中扫表发现锁超时。死锁检测默认是开启的，说明没有检测到死锁。

【复现路径】问题出现前后相关操作

创建 sysbench 和 test 两个库。

./sysbench_x86 --threads=16 --table-size=5000 --tables=10 --auto_inc=on --report-interval=1 --mysql-host=${host} --mysql-port=2881 --mysql-user=root --mysql-db=sysbench --time=7200 --max-requests=0 --mysql-ignore-errors=‘8520’ ./src/lua/oltp_write_only.lua --rand-type=uniform --create_secondary=on --mysql-password=${passwd} run

压测时并发执行，发现会报错超时：replace into test.sbtest1 select * from sysbench.sbtest1 limit 1000 lock in share mode;

但是单独执行 select * from sysbench.sbtest1 limit 1000 lock in share mode; 或者 select * from sysbench.sbtest1 limit 1000 for update; 都可以成功

image2431×132 11.4 KB

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

根因分析场景: 事务等待超时报错
根因分析命令: obdiag rca run --scene=transaction_wait_timeout
日志采集场景: 锁冲突问题
日志采集命令: obdiag gather scene run --scene=observer.lock_conflict

推荐使用 obdiag 工具进行根因分析和日志采集，这将有助于我们确定锁超时的具体原因。请您执行上述命令，并将采集到的日志提供给我们以便确认问题所在。

为了更好地帮助您解决问题，请您提供以下信息：

1. 在压测过程中，是否只有 replace into 操作报错，其他类型的写操作（如 insert、update）是否有类似问题？
2. 报错4012时，具体涉及的表结构和索引情况是怎样的？是否存在较多唯一性约束或外键？
3. sysbench 测试配置中，并发度设置为多少？每次测试运行的时间有多长？
4. OceanBase 集群的规格配置如何（包括 OBServer 节点数量、CPU 核数、内存大小等）？
5. 是否可以提供发生错误前后一段时间内的 SQL 审计日志，以便我们查看具体的 SQL 执行情况？

附上敏捷诊断工具 obdiag 使用帮助链接

是不是压测模型有问题啊。都是insert select这种？可以看下gv$ob_sql_audit

可以按照小助手说的 排查一下
select
/+QUERY_TIMEOUT(3600000000) read_consistency(weak) /
b.TRANS_ID,
case
WHEN b.TYPE = ‘TM’ THEN ‘表锁’
WHEN b.TYPE = ‘TX’ THEN ‘事务锁’
WHEN b.TYPE = ‘TR’ THEN ‘行锁’
ELSE NULL
END
AS lock_type,
ID1,
LMODE,
CASE
WHEN BLOCK = 0 THEN ‘该事务持有锁’
WHEN BLOCK = 1 THEN ‘该事务被阻塞’
ELSE NULL
END
as BLOCK,
a.SVR_IP,
ID,
user,
command,
time,
total_time,
STATE,
info,
retry_cnt,
retry_info,
thread_id,
trace_id
from
gv$ob_processlist a,
GV$OB_LOCKS b,
CDB_ob_table_locations c
where
a.trans_id = b.trans_id
and c.table_name = ‘表名称’
and (
ID1 like concat(’%’ , c.table_id, ‘%’)
OR ID1 like concat(’%’ , c.tablet_id ,’%’)
); sys租户下执行 看看是否有锁的问题

给你提供两个思路：

1. 压测之前用诊断工具Obdiag先巡检一下；
   https://www.oceanbase.com/docs/common-obdiag-cn-1000000002023125

2. 压测的过程中你如果怀疑有锁，可以用obdiag的锁冲突根因分析诊断一下
   https://www.oceanbase.com/docs/common-obdiag-cn-1000000002023105