【 使用环境 】生产环境
【 OB 】
【 使用版本 】 4.2.2-20240315150922
【问题描述】
告警事件详情
告警概述：alarm_template_id=0:ob_cluster=obrs-1711351485:host=X.X.X.X:server_type=observer:error_code=4388:keyword= OBServer 程序日志
告警详情：[OBServer 程序日志] 集群：obrs，日志类型：observer，日志文件：/home/admin/oceanbase/log/observer.log，日志级别：ERROR，关键字=，错误码=4388，日志详情=[2024-08-22 02:00:07.167104] ERROR issue_dba_error (ob_log.cpp:1875) [7830][T1039_ReplaySrv][T1039][Y0-0000000000000000-0-0] [lt=6][errcode=-4388] Unexpected internal error happen, please checkout the internal errcode(errcode=-4389, file=“ob_ls_adapter.cpp”, line_no=106, info=“single replay task cost too much time. replay may be delayed”) 。
1 个赞
旭辉
#4
麻烦发下完整的 observer.log
同时参考如下命令，分析下报错时间前后30分钟到日志
obdiag analyze log --from “2023-10-08 10:25:00” --to “2023-10-08 11:30:00”
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001214443
1 个赞
靖顺
#5
1 个赞
因为日志保留时间较短,报错时间前后半小时的日志被清了，这里是昨天down的一份报错时间点的日志，麻烦先分析一下，若无法处理，则待下次出现时上传完整日志
observerlog.7z (8.5 MB)
淇铭
#9
在ocp上 你看一下 这两个信息
如果高了 查一下模块的内存
select * from gv$ob_memory where tenant_id=500 order by used desc limit 20;
旭辉
#11
分析了下，您提供的日志是 2024-08-22 01:59:43～2024-08-22 02:00:20的日志，日志内容和ocp的这个告警是对得上的，需要向您再了解几个问题：
1.“这里是昨天down的一份报错时间点的日志” 这你的down是什么时间down的？是运行了多久down的？
2.4389告警是clog回放有延迟，一般不会导致挂掉，您发的日志是挂掉时的日志吗？
“
[2024-08-22 02:00:07.167623] INFO [STORAGE.TRANS] check_all_readonly_tx_clean_up (ob_ls_tx_service.cpp:264) [18497][T1011_TxLoopWor][T1011][Y0-0000000000000000-0-0] [lt=5] wait_all_readonly_tx_cleaned_up cleaned up success(ls_id={id:1})
[2024-08-22 02:00:07.167104] ERROR issue_dba_error (ob_log.cpp:1875) [7830][T1039_ReplaySrv][T1039][Y0-0000000000000000-0-0] [lt=6][errcode=-4388] Unexpected internal error happen, please checkout the internal errcode(errcode=-4389, file=“ob_ls_adapter.cpp”, line_no=106, info=“single replay task cost too much time. replay may be delayed”)
[2024-08-22 02:00:07.167070] ERROR issue_dba_error (ob_log.cpp:1875) [7785][T1039_ReplaySrv][T1039][Y0-0000000000000000-0-0] [lt=43][errcode=-4388] Unexpected internal error happen, please checkout the internal errcode(errcode=-4389, file=“ob_ls_adapter.cpp”, line_no=106, info=“single replay task cost too much time. replay may be delayed”)
”：
旭辉
#12
明白了，上面“down”是下载的意思，
再确认下 这个告警频率是怎样的？
我下载的时候是22号16:36分下载的，告警是22号2:00。
我发的日志是告警这段时（8月22号2:01-2:06分）的日志，应该是没有挂掉的
告警频率不确定，会隔天出现也会好几天出现一次，同一个集群出现的节点也不同
旭辉
#14
1.告警频率不确定，会隔天出现也会好几天出现一次，同一个集群出现的节点也不同
–说明告警是多次出现的，确定是有问题的，可能涉及bug，麻烦至少提供2次出现这个情况时的日志（需要上升到开发排查，日志需要全面一些）
2.您提供的日志是 2024-08-22 01:59:43～2024-08-22 02:00:20的2分钟的日志，时间间隔比较短，如果再出现麻烦至少提供下前后10分钟的日志
这是最近两次出现的，我提取了前后半小时的，因为日志比较大，我上传到了百度网盘，麻烦提取下，谢谢
通过网盘分享的文件：OB日志
链接: 百度网盘 请输入提取码 提取码: 57h7
–来自百度网盘超级会员v3的分享
旭辉
#17
原因分析:
转储时persist_and_transform_tablet有大量io操作，处于ls tablet service bucket lock中，当io抖动时，它持锁时间较长，进而影响create memtable耗时。
该机器clog/slog/datafile读写盘耗时均异常，该段时间均在几十ms，有时甚至几百ms，推测与机器有关。
解决方案:
1.如果再次遇到抖动，建议更换机器
2.内核层面也会再进行代码优化
方锟
#18
请问一下这个在日志中是怎样体现的，遇到了怎么通过日志来判断呢，是不是如楼主照片中同样的报错都是这个原因引起的。
