--- title: 日志告警 -4015，partition table update task cost too much time to execute 的原因和解决方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于日志告警 -4015，partition table update task cost too much time to execute 的原因和解决方法相关的常见问题和使用技巧，帮助您快速解决日志告警 -4015，partition table update task cost too much time to execute 的原因和解决方法的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # 日志告警 -4015，partition table update task cost too much time to execute 的原因和解决方法 更新时间：2026-06-04 01:56 适用版本： V3.1.x、V3.2.x 内容类型：Troubleshoot ## 问题现象 OCP 告警信息。 ```shell [OB 日志告警] 集群=xxxx, 机器=xxx.xxx.xxx.xxx，日志类型=observer 错误码=4015, 错误名称=OB_ERR_SYS, 错误详情=[2024-xx-xx xxx:xxx:xxx.xxx] ERROR [SERVER] check_task_status (ob_partition_table_updater.cpp:124) [4127306][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=8] [dc=0] partition table update task cost too much time to execute(*this={part_key:{tid:1099511627779, partition_id:2, part_cnt:0}, data_version:0, first_submit_time:xxxxxxxxxxxxxxxxxxxx, is_remove:false, with_role:true}, safe_interval=4000000, cost_time=4200302, interval=60000000) BACKTRACE:0xe88a1d7 0xe7221ab 0xa56a63f 0x4587f47 0xa5930b3 0x4587cbf 0xadaa107 0xad18913 0xad18817 0xad2127b 0xadf4e3b 0x457f68f 0xe6081b3 0xe607ff7 0xe89e69b 0xe89e69b ``` ## 问题排查过程 1. 通过 `__all_virtual_election_event_history` 获取与选举相关的 Leader 信息。 ```shell select * from oceanbase.__all_virtual_election_event_history where table_id = xxx order by gmt_create desc limit 50; ``` 目的是排查是否有无主，查看 `__all_virtual_election_event_history` 切主历史表没有记录。 2. 通过命令过滤选举日志信息。 ```shell grep '$table_id' election.log ``` `$table_id` 为步骤 1 **通过查询 `__all_virtual_election_event_history` 表展示选举相关事件** 中的 table_id，选举日志无记录。 3. 通过 SQL 确定告警时没有无主记录。 无主，当前告警未恢复，检查是否有无主，若有无主排查无主问题。 ```shell ##-- 统计当前 clog 层无主的分区列表。 (select table_id, partition_idx from __all_virtual_clog_stat group by table_id, partition_idx) except (select table_id, partition_idx from oceanbase.__all_virtual_clog_stat where role = 'LEADER'); ##-- 统计当前 RS 层无主的分区列表（有 Schema，Meta 表无主）。 select tenant_id, table_id, partition_id from oceanbase.__all_virtual_partition_table group by 1,2,3 having min(role) = 2; ``` 4. 检查是否有时钟问题。 - 当前问题正在发生时，观察时钟是否有问题，在问题节点执行执行如下命令。 ```shell ##-- clockdiff 其他节点 IP 地址。 clockdiff -o $IP ``` - 当前问题已经恢复，可以在日志中过滤关键词 SERVER_BLACKLIST，非百分百打印，作为参考手段，存在明显时钟问题的日志信息如下。 ```shell [2024-10-04 20:30:19.271330] WARN [SHARE] operator() (ob_server_blacklist.cpp:120) [8407][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=7] [dc=0] [SERVER_BLACKLIST] clock diff time is too large, attention !(clockdiff_time=1087389, member={server:"xx:2882", cluster_id:xx} [2024-10-04 20:30:19.273330] WARN [SHARE] operator() (ob_server_blacklist.cpp:120) [8407][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=6] [dc=0] [SERVER_BLACKLIST] clock diff time is too large, attention !(clockdiff_time=1088062, member={server:"xx:2882", cluster_id:xx}) ``` 5. 排查是否有写入限速。 在问题节点 OBServer 日志中过滤关键词 `report write throttle info`。 ```shell grep 'report write throttle info' observer.log.xxx ``` 如果日志中过滤出 `report write throttle info` 信息，说明当前 MemStore 写入较大，触发了限速，建议控制业务写入后，能够自动恢复观察即可。 6. 检查网络问题。 在问题节点观察是否有丢包，网络是否存在波动，如下 `pktdrp` 列显示有丢包，丢包出现在预期内，请排查网络问题。 ```shell tsar -d 20241004 -i 1 --traffic --tcp Time -------------------------------tcp------------------------------ ---------------------traffic-------------------- Time active pasive iseg outseg EstRes AtmpFa CurrEs retran bytin bytout pktin pktout pkterr pktdrp 05/10/24-23:28 1.67 2.37 33.9K 7.7K 0.40 0.00 1.5K 0.00 930.3M 1.9M 631.0K 7.6K 0.00 28.00 05/10/24-23:29 1.60 2.83 8.2K 4.0K 0.80 0.07 1.5K 0.00 164.9M 1.8M 113.4K 3.8K 0.00 0.00 05/10/24-23:30 1.63 2.68 28.6K 7.7K 0.52 0.00 1.5K 0.00 739.9M 2.1M 502.4K 7.5K 0.00 90.00 05/10/24-23:31 1.58 2.98 26.7K 7.7K 0.55 0.02 1.5K 0.00 686.6M 2.0M 466.3K 7.6K 0.00 54.00 05/10/24-23:32 1.62 2.20 2.4K 3.0K 0.60 0.00 1.5K 0.00 1.8M 1.5M 3.0K 2.8K 0.00 0.00 05/10/24-23:33 1.63 2.98 2.4K 2.9K 0.75 0.00 1.5K 0.00 1.7M 1.4M 2.9K 2.8K 0.00 0.00 05/10/24-23:34 1.65 2.27 28.2K 8.1K 0.55 0.00 1.5K 0.00 741.1M 2.0M 503.2K 7.9K 0.00 51.00 05/10/24-23:35 1.63 2.28 2.7K 3.0K 0.70 0.00 1.5K 0.00 10.3M 1.4M 8.7K 2.9K 0.00 0.00 05/10/24-23:36 1.67 2.13 18.2K 5.2K 0.57 0.00 1.5K 0.00 467.4M 1.4M 317.9K 5.0K 0.00 48.00 05/10/24-23:37 1.58 2.38 5.6K 3.3K 0.80 0.00 1.5K 0.00 107.3M 1.2M 74.2K 3.2K 0.00 0.00 05/10/24-23:38 1.62 1.85 19.4K 5.4K 0.43 0.00 1.5K 0.00 503.5M 1.5M 342.2K 5.3K 0.00 6.00 05/10/24-23:39 1.62 2.43 12.2K 4.3K 0.83 0.00 1.5K 0.00 299.9M 1.3M 204.5K 4.2K 0.00 21.00 05/10/24-23:40 1.63 2.28 3.3K 3.0K 0.62 0.00 1.5K 0.00 36.4M 1.1M 26.3K 2.9K 0.00 0.00 05/10/24-23:41 1.65 2.45 2.9K 2.9K 0.83 0.00 1.5K 0.00 24.6M 1.1M 18.3K 2.8K 0.00 0.00 05/10/24-23:42 1.63 2.50 2.5K 2.8K 0.72 0.00 1.5K 0.00 9.7M 1.1M 8.2K 2.7K 0.00 0.00 05/10/24-23:43 1.63 3.03 2.7K 2.8K 0.78 0.00 1.5K 0.00 18.0M 1.1M 13.8K 2.7K 0.00 0.00 05/10/24-23:44 1.60 2.78 3.2K 2.8K 0.60 0.00 1.5K 0.00 37.0M 1.1M 26.6K 2.7K 0.00 10.00 05/10/24-23:45 1.67 2.92 9.9K 4.0K 0.77 0.00 1.5K 0.00 230.8M 1.4M 157.9K 3.9K 0.00 10.00 05/10/24-23:46 1.70 2.52 4.6K 5.4K 0.63 0.00 1.5K 0.00 2.7M 2.7M 5.4K 5.2K 0.00 0.00 ``` 7. 检查参数 `partition_table_check_interval`（用于设置 OBServer 从分区表中删除不存在的副本的时间间隔），是否有修改过，默认是 30m，建议保持不变，如果因为其他问题临时调整，待问题解决及时修改为默认值 30m。 ## 问题原因 网络存在丢包和时钟不同步的问题，并且参数 `partition_table_check_interval`（用于设置 OBServer 从分区表中删除不存在的副本的时间间隔） 过小。 ## 问题的风险及影响 1. 当前无主会导致，事务进来执行不成功，需要及时处理。 2. 写入限速，控制业务写入，观察即可。 3. 时钟问题，需要处理时钟问题 4. 网络波动，偶发告警，可以及时恢复的话，观察即可 ## 影响租户 影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。 ## 适用版本 OceanBase 数据库 V3.x 版本。 上一篇 [OceanBase 数据库网络相关问题的排查方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000707800) 下一篇 [OCP 日志告警 easy_reqeust hold by upper-layer for too much time 的原因及解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002725523) ![有帮助](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) 咨询热线