OB4.2.1.7执行truncate过于缓慢甚至超时的情况如何处理

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OceanBase
【 使用版本 】4.2.1.7
【问题描述】
1.集群为三节点，288C830G
2.租户规格50C130G1000000iops，tps和qps峰值均能达到3200，租户primary_zone和rootservice位置一致
3.通过gv$session_wait观察到等待事件为network占比为总数的30%
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

#4

语句提供一下 表结构也提供一下

#5

好的，不过大部分truncate都很慢，我找个贴下，这个表700+字段
image
表结构
表结构.txt (32.5 KB)

#6

先用敏捷诊断工具obdiag 巡检一下，看看集群本身有没有啥隐藏的点，发出巡检的结果文件

obdiag check run

文档：https://www.oceanbase.com/docs/common-obdiag-cn-1000000002200479

#7

好的

#8

1、根据截图 先这样分析一下 看看时间消耗在什么地方

image
image1245×875 31.4 KB

show trace 使用方法参考官网文档： OceanBase Show Trace
2、用trace id捞一下rs所在机器的rs日志，租户leader所在机器的observer日志以及sql发往的机器的observer日志
执行语句 抓取日志的步骤
SET ob_enable_show_trace=‘ON’;

注意：需要在同一个会话中执行

obclient [test]> select count() from test2;
±---------+
| count() |
±---------+
| 0 |
±---------+
1 row in set (0.003 sec)

obclient [test]> select last_trace_id();
±----------------------------------+
| last_trace_id() |
±----------------------------------+
| YB420BA1CC68-000615A0A8EA6511-0-0 |
±----------------------------------+
1 row in set (0.002 sec)

obclient [test]> select * from oceanbase.gv$ob_sql_audit where trace_id=‘YB420BA1CC68-000615A0A8EA6511-0-0’;
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” rootservice.log
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A0A8EA6511-0-0” observer.log

1 个赞
#9

老师，这是巡检结果
obdiag.txt (11.6 KB)

1 个赞
#10

巡检结果会存到文件中，你把那个文件发出来。
./check_report/obdiag_check_report_obproxy_2025-02-11-14-19-35.table

./check_report/obdiag_check_report_observer_2025-02-11-14-19-36.table ’

#11

从你上面发出来的巡检报告中有如下风险点：

  1. obproxy 版本是4.2.1.0 ，建议升级，[Enhancement]: obdiag 巡检对 observer 以及obproxy 风险版本提示升级 · Issue #589 · oceanbase/obdiag · GitHub
  2. 集群存在内存模块占用超过10GB的情况，需要关注内存使用情况，内部视图可查__all_virtual_memory_info；
  3. 集群的磁盘性能不好，建议换性能更好的盘；

所以，综合巡检结果来看，你这个集群可能是因为内存吃紧+磁盘性能差，truncate 表比较慢。

3 个赞
#12

好的，谢谢老师

#13

grep_observer.log (943.9 KB)
grep_rootservice.log (113.5 KB)
老师，这是tracelog

#14

从日志上看 没有看出什么问题 你查一下这个表的数据 __all_table_history

#15

应该是同一个环境，最早数据是24-7-30，我看老师您答复的是升级到4.2.1.bp10

#16

好的 这个是已知的问题

1 个赞
#17

那至少升级到4.2.1bp10才能解决对吧

#18

是的

#19

好的，谢谢老师解答