【 使用环境 】生产环境
【 使用版本 】V4.3.5.3
【问题描述】ob sql 耗时过大
租户是 3c20g 的，memstore 分配了 35% 有 6G+，周期性 tps 有几十，update 是根据主键id，但耗时能有 10s 了
监控中这一时期等待事件 concurrency_wait 能达到 27k，memstore 很快就触发转储了，租户线程使用率也高。
麻烦大佬们帮忙看看是啥原因呢
OceanBase 社区已接收您的帖子，正在跟进中。
1 个赞
是不是操作表有大的未提交事务或者热点表
1 个赞
1、ob4353环境
1）排查出存在向量索引反复rebuild失败 是个已知bug造成的问题
升级操作流程：
1. 用obclient直连observer的sys租户（不能用proxy，不能用平台）
2. alter system change tenant xxx，xxx是用户租户名
3. select * from oceanbase.__all_ddl_task_status where task_id = xxx; xxx是残留的task_id，务必备份下这个记录
4. delete from oceanbase.__all_ddl_task_status where task_id = xxx; 删除ddl记录
5. 升级版本 （如果需要）
6. 升级后重新插入步骤3中备份的记录：insert into oceanbase.__all_ddl_task_status values(…)
2、ob4352环境长事务问题
- 经排查引起长事务的sql是向量索引refresh任务在查询3号表数据时发起的select count 语句，inner sql报错-6231（major不存在）导致无法退出，卡住refresh流程，事务无法提交。出现6231的原因是4352的已知bug造成的问题。
2.合并卡也是因为索引表的major不存在，导致合并报错。
总结：都是触发了已知的bug 建议升级到435bp4及以上版本
2 个赞
疑问1：排查出存在向量索引反复rebuild失败 是个已知bug造成的问题，请问具体是哪个Bug呢？ 是下图的描述的bug吗
疑问2：经排查引起长事务的sql是向量索引refresh任务在查询3号表数据时发起的select count 语句，inner sql报错-6231（major不存在）导致无法退出，卡住refresh流程，事务无法提交。
请问事务是提交时间变长了，还是此事务无法提交？
2 个赞
哦吼
收到，原来是 V4.3.5_CE_BP3_HF2。感谢解答