--- title: TSC 时钟回退导致 Liboblog 500 租户内存占用过高-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 TSC 时钟回退导致 Liboblog 500 租户内存占用过高相关的常见问题和使用技巧，帮助您快速解决 TSC 时钟回退导致 Liboblog 500 租户内存占用过高的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # TSC 时钟回退导致 Liboblog 500 租户内存占用过高 更新时间：2026-05-07 09:46 适用版本： V3.2.x、V4.0.x、V4.1.x 内容类型：Troubleshoot ## 问题现象 500 租户内存从 40G 升到 116G，用时 30 分钟，之后一直在 100G～120G 波动，一直未释放。 可以通过如下语句查询 500 租户内存占用情况。 ```shell select svr_ip,mod_name,sum(hold) system_memory_sum from __all_virtual_memory_info where tenant_id=500 and hold<>0 group by svr_ip,mod_name order by system_memory_sum desc; ``` ## 关键诊断信息 ### 事前巡检 #### 环境检查 1. 检查 CPU 型号。 ```shell # 命令是否存在结果 lscpu | grep tsc ``` 输出结果如下： ![image01](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/memory/20251016tsc-clock-rollback-causes-excessive-memory-usage-for-liboblog-500-tenants01.png) 如果有结果，再进行下文的检查。**但是经过实践发现，鲲鹏等 ARM 的 CPU 下，`lscpu` 的 `flag` 结果并没有，但问题依然是存在的**。所以需要本文档 **巡检方式** 这一节内容来进一步的判断。 2. 查询内部表，确认目前是否已经出现问题，或者还有多少天会出现问题。 ```shell select svr_ip, (time_to_usec(now()) - start_service_time)/1000000/3600/24 as alive_days from __all_server; ``` 输出结果如下： ![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/memory/20251016tsc-clock-rollback-causes-excessive-memory-usage-for-liboblog-500-tenants02.png) **对于 2.5GH 的 CPU，203 天就已经出现了问题**。 #### 巡检方式 ##### 巡检对于 OMS 同步链路的潜在影响 使用命令过滤 `liboblog/libobcdc` 报错日志。 ```shell grep open_stream_ liboblog.log* | grep 4015 ``` 输出结果如下： liboblog.log:[2023-10-17 17:58:17.009182] EDIAG [TLOG.FETCHER] open_stream_ (ob_log_fetch_stream.cpp:439) [1143718][0][Y71CB9E701D45-0000000001700001-0-0] [lt=11][errcode=0] open stream fail on server(svr_identity={principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}, request_svr:"xxx.xxx.xxx.xxx:xxx"}, svr_err=-4015, svr_debug_err=-4019, rcode={code:0, msg:"", warnings:[]}, req={rpc_ver:1, stream_lifetime:60000000, liboblog_pid:1143243, stale_stream:{self_:"0.0.0.0", seq_ts_:-1}, param_count:1, params:[{pkey_:{tid:1100611139403781, partition_id:0, part_cnt:0}, start_log_id_:1531408}], principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}}, resp={rpc_ver_:1, err_:-4015, debug_err_:-4019, seq_:{self_:"0.0.0.0", seq_ts_:-1}}) BACKTRACE:0x16017b90 0x15ff5577 0xa3f0edc 0xa47d7c2 0xa3c8950 0xa3c7644 0xa3c4db7 0xa3c4b2d 0xa8369dc 0xa8a3162 0xa95a3df 0x7f30eea8dea5 0x7f30ee0a78dd liboblog.log:[2023-10-17 17:58:17.009743] EDIAG [TLOG.FETCHER] open_stream_ (ob_log_fetch_stream.cpp:439) [1143717][0][Y71CB9E701D45-0000000001500001-0-0] [lt=22][errcode=0] open stream fail on server(svr_identity={principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}, request_svr:"xxx.xxx.xxx.xxx:xxx"}, svr_err=-4015, svr_debug_err=-4019, rcode={code:0, msg:"", warnings:[]}, req={rpc_ver:1, stream_lifetime:60000000, liboblog_pid:1143243, stale_stream:{self_:"0.0.0.0", seq_ts_:-1}, param_count:4, params:[{pkey_:{tid:1100611139453923, partition_id:0, part_cnt:0}, start_log_id_:181995}, {pkey_:{tid:1100611139456950, partition_id:0, part_cnt:0}, start_log_id_:6749}, {pkey_:{tid:1100611139454749, partition_id:0, part_cnt:0}, start_log_id_:201279}, {pkey_:{tid:1100611139791330, partition_id:0, part_cnt:0}, start_log_id_:130366}], principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}}, resp={rpc_ver_:1, err_:-4015, debug_err_:-4019, seq_:{self_:"0.0.0.0", seq_ts_:-1}}) BACKTRACE:0x16017b90 0x15ff5577 0xa3f0edc 0xa47d7c2 0xa3c8950 0xa3c7644 0xa3c4db7 0xa3c4b2d 0xa8369dc 0xa8a3162 0xa95a3df 0x7f30eea8dea5 0x7f30ee0a78dd liboblog.log.20231012160726018:[2023-10-12 11:04:06.718034] EDIAG [TLOG.FETCHER] open_stream_ (ob_log_fetch_stream.cpp:437) [1227713][0][YBA359E701D45-0000000000C00001-0-0] [lt=26][errcode=0] open stream fail on server(svr_identity={principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}, request_svr:"xxx.xxx.xxx.xxx:xxx"}, svr_err=-4015, svr_debug_err=-4019, rcode={code:0, msg:"", warnings:[]}, req={rpc_ver:1, stream_lifetime:60000000, liboblog_pid:1227317, stale_stream:{self_:"0.0.0.0", seq_ts_:-1}, param_count:2, params:[{pkey_:{tid:1100611139453923, partition_id:0, part_cnt:0}, start_log_id_:178514}, {pkey_:{tid:1100611139456950, partition_id:0, part_cnt:0}, start_log_id_:6627}], principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}}, resp={rpc_ver_:1, err_:-4015, debug_err_:-4019, seq_:{self_:"0.0.0.0", seq_ts_:-1}}) BACKTRACE:0x7fb09687b53b 0x7fb096863287 0x7fb08aea9c0c 0x7fb08af36212 0x7fb08ae7be26 0x7fb08ae7a9a4 0x7fb08ae78097 0x7fb08ae77e0d 0x7fb08b2f009c 0x7fb08b35b1fe 0x7fb08b405fdf 0x7fb0e7bb1ea5 0x7fb0e71cb8dd liboblog.log.20231012160726018:[2023-10-12 11:04:06.723251] EDIAG [TLOG.FETCHER] open_stream_ (ob_log_fetch_stream.cpp:437) [1227715][0][YBA359E701D45-0000000000E00001-0-0] [lt=15][errcode=0] open stream fail on server(svr_identity={principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}, request_svr:"xxx.xxx.xxx.xxx:xxx"}, svr_err=-4015, svr_debug_err=-4019, rcode={code:0, msg:"", warnings:[]}, req={rpc_ver:1, stream_lifetime:60000000, liboblog_pid:1227317, stale_stream:{self_:"0.0.0.0", seq_ts_:-1}, param_count:1, params:[{pkey_:{tid:1100611139403781, partition_id:0, part_cnt:0}, start_log_id_:1527938}], principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}}, resp={rpc_ver_:1, err_:-4015, debug_err_:-4019, seq_:{self_:"0.0.0.0", seq_ts_:-1}}) BACKTRACE:0x7fb09687b53b 0x7fb096863287 0x7fb08aea9c0c 0x7fb08af36212 0x7fb08ae7be26 0x7fb08ae7a9a4 0x7fb08ae78097 0x7fb08ae77e0d 0x7fb08b2f009c 0x7fb08b35b1fe 0x7fb08b405fdf 0x7fb0e7bb1ea5 0x7fb0e71cb8dd liboblog.log.20231012160726018:[2023-10-12 11:04:06.725130] EDIAG [TLOG.FETCHER] open_stream_ (ob_log_fetch_stream.cpp:437) [1227713][0][YBA359E701D45-0000000000C00002-0-0] [lt=9][errcode=0] open stream fail on server(svr_identity={principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}, request_svr:"xxx.xxx.xxx.xxx:xxx"}, svr_err=-4015, svr_debug_err=-4019, rcode={code:0, msg:"", warnings:[]}, req={rpc_ver:1, stream_lifetime:60000000, liboblog_pid:1227317, stale_stream:{self_:"0.0.0.0", seq_ts_:-1}, param_count:2, params:[{pkey_:{tid:1100611139454749, partition_id:0, part_cnt:0}, start_log_id_:201279}, {pkey_:{tid:1100611139791330, partition_id:0, part_cnt:0}, start_log_id_:119190}], principal_svr:{server_addr:"xxx.xxx.xxx.xxx:xxx", server_seq:0}}, resp={rpc_ver_:1, err_:-4015, debug_err_:-4019, seq_:{self_:"0.0.0.0", seq_ts_:-1}}) BACKTRACE:0x7fb09687b53b 0x7fb096863287 0x7fb08aea9c0c 0x7fb08af36212 0x7fb08ae7be26 0x7fb08ae7a9a4 0x7fb08ae78097 0x7fb08ae77e0d 0x7fb08ae782c2 0x7fb08ae77e0d 0x7fb08b2f009c 0x7fb08b35b1fe 0x7fb08b405fdf 0x7fb0e7bb1ea5 0x7fb0e71cb8dd ``` OBServer 对应节点的异常报错日志信息如下： ![image03](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/memory/20251016tsc-clock-rollback-causes-excessive-memory-usage-for-liboblog-500-tenants03.png) OBServer 节点日志不再打印如下（非日志限流场景，正常秒级打印）信息： ```shell [FETCH_LOG_STREAM] Wash Stream: wash expired stream succes weak read service task statistics ``` 检查下面的日志，如果持续没有打印，是不符合预期的，需要重点关注： ```shell grep 'weak read service task statistics' observer.log.2xxx // 尽量多一些文件 grep 'Wash Stream: wash expired stream succes' observer.log.2xxxx // 尽量多一些文件 ``` ##### 巡检冷分区是否长时间未写 checkpoint 日志 这个查询的结果为当前集群中日志位点最小的分区的位点和当前时间的差值(以小时为单位)，当这个结果大于 1，就说明是有问题的集群，语句如下： ```shell select timestampdiff(HOUR, usec_to_time(last_slide_out_log_ts), now()) from __all_virtual_partition_replay_status a join __all_virtual_clog_stat b on a.svr_ip=b.svr_ip and a.svr_port=b.svr_port and a.table_id=b.table_id and a.partition_idx = b.partition_idx and b.role='LEADER' order by last_slide_out_log_ts limit 1; ``` ## 问题原因 - 直接原因：500 租户的内存占用过高，`liboblog` 清理任务一直没有触发导致。 - 根本原因：`liboblog` 清理任务受 `REACH_TIME_INTERVAL` 这一个宏来控制，`REACH_TIME_INTERVAL`（宏含义是指定时间间隔定时调度）中使用 `current_tsc` 获取当前时间，但是这个值维护不准（环境发现获取当前时间都是偏小的）导致任务逻辑永远无法触发，进而 500 租户的同步链路相关内存无法触发回收。 ## 问题的风险及影响 ### OMS 数据同步链路 TSC 时钟回退，导致 OBServer 为 `liboblog` 提供日志的模块（ExtStream）记录的日志流信息无法清理（外部表现为 500 租户内存较高），`liboblog` 新建拉日志流失败，影响下游数据同步。 ### 主备库 主备库场景下，曾经出现单个 server 合并超时的问题。 ### 日志备份 `current_tsc` 获取当前时间不准导致冷分区每小时写一条 `checkpoint` 日志的机制失效，导致分区的日志位点无法推进，进而导致备份的 `clog` 回收位点无法推进，归档日志文件无法回收。 ## 影响租户 影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。 ## 影响版本 OceanBase 数据库 V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本。 ## 解决方法 ### 集群问题 集群重启（依次逐个重启 Zone，尽量减小对业务的影响）。如果不接受重启集群，可以只重启有问题的节点（通过本文档 **巡检方式** 这一节内容确认），需要注意部分重启的风险：**未重启的 OBServer 节点不久后会出现同样的问题**。 ### V3.x 版本中归档日志无法清理的场景恢复 #### 常规恢复 1. 集群重启。 2. sys 租户执行 `alter system minor freeze;`。 3. 一个小时后发起一次全量备份（之所以需要等一个小时是因为全量备份中的 `start_replay_log_ts` 取的是所有的分区的 `clog_info` 中的记录的 `last_submit_log_ts` 的最小值，这个值依赖于 `ilog` 刷盘，等一个小时是给转储和 `ilog` 刷盘预留的时间）。 4. 等待 `recovery window` 推过全量备份之后就能回收了。如果 `recovery window` 是 7 天，需要等 7 天以后才能自动清理。 如果要求缩短恢复的区间，可以适当调整 `recovery window` 的值。 #### 备份空间不足的恢复 1. 提供新的备份 NFS 或者对象存储。 2. sys 租户执行 `alter system minor freeze;` 并等待转储结束。 3. 停掉原来的备份。 4. 更换新的备份路径。 5. 重新发起日志归档。 6. 重新发起数据备份。 7. 当不再需要老的备份介质上的数据时，手动删除老的备份数据。 ## 规避方式 升级到问题已修复版本。目前已修复的版本包含 OceanBase 数据库 V3.2.3 BP8 Hotfix3（oceanbase-3.2.3.3-108030022023051915）版本、V3.2.3 BP8 Hotfix4（oceanbase-3.2.3.3-108040052023060909）版本、V3.2.3 BP8 Hotfix5（oceanbase-3.2.3.3-108050012023070409）版本、V3.2.3 BP8 Hotfix6（oceanbase-3.2.3.3-108060012023102510）版本、V3.2.3 BP9（oceanbase-3.2.3.3-109000182023071410）及之后版本、V3.2.4 BP4（oceanbase-3.2.4.4-104000052023062021）及之后版本、V4.1.0 BP2（oceanbase-4.1.0.1-102000042023061309）及之后的版本。 Previous [SQL 执行报 4013 且 500 租户内存突增场景之一](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000245406) Next [OceanBase 集群内存超限报错 easy exceed memory limit](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209937) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线