--- title: 关于线程 hang 住 obstack 多线程卡在 ObSliceAlloc::free 的场景-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 关于线程 hang 住 obstack 多线程卡在 ObSliceAlloc::free 的场景相关的常见问题和使用技巧，帮助您快速解决 关于线程 hang 住 obstack 多线程卡在 ObSliceAlloc::free 的场景的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # 关于线程 hang 住 obstack 多线程卡在 ObSliceAlloc::free 的场景 更新时间：2024-01-22 01:56 适用版本： V2.1.x、V2.2.x 内容类型：Troubleshoot ## 问题现象 `ObSliceAlloc` 相关的 `uint32_t` 类型整数溢出，会导致 `ObSliceAlloc::free` 线程 hang 住，进而导致 500 租户队列积压，从而顶层可能表现出悬挂事务、租户分区无主、OBServer 节点 2881 连接 hang、Clog 回放积压等现象不定的严重问题。 相应的问题现象场景信息。 - endless loop in ObSliceAlloc::free 日志信息如下。 ```shell #0 0x0000000005df2a12 in push (p=0x7fd5518284f0, this=0x7fd551820970) #1 free_item (first_free=, p=0x7fd5518284f0, this=0x7fd5518208b0) #2 oceanbase::common::ObSliceAlloc::free (this=0x7fd7daac1130, p=0x7fd551828500) #3 0x000000000871e2f6 in retire (ptr=0x7fd551828500, this=0xed06200 >::get_val_ref()::val_ref>) ``` - 大量分区无主, 且 OBServer cpu load 高, OBServer 日志中有大量如下日志。 ```shell WARN [CLOG] switch_state (ob_partition_log_service.cpp:2930) [xxxxx][xxxxx][xxxxx-xxxxx][lt=16][dc=0] switch_state wrlock failed(ref=-4023, partition_key=(tid:xxxxxx,....) WARN [CLOG] switch_state (ob_partition_log_service.cpp:2930) [xxxxx][xxxxx][xxxxx-xxxxx][lt=16][dc=0] switch_state wrlock failed(ref=-4023, partition_key=(tid:xxxxxx,....) WARN [CLOG] switch_state (ob_partition_log_service.cpp:2930) [xxxxx][xxxxx][xxxxx-xxxxx][lt=16][dc=0] switch_state wrlock failed(ref=-4023, partition_key=(tid:xxxxxx,....) ``` - 500 租户队列满影响业务交易, 日志信息如下。 ```shell INFO [SERVER.OMT] ob_multi_tenant.cpp:803 [xxxxx][xxxxx][xxxxx-xxxxx][lt=45][dc=0] dump tenant info(tenant={id:500, compat_mode:0, unit_min_cpu:"xxxxx+xxx", unit_max_cpu:"xxxxx+xxx", slice:"xxxxx+xxx", slice_remain:"xxxxx+xxx", token_cnt:40, ass_token_cnt:40, lq_tokens:12, used_lq_tokens:0, stopped:false, idle_us:3149615, recv_hp_rpc_cnt:80193853780, recv_np_rpc_cnt:239, recv_lp_rpc_cnt:0, recv_mysql_cnt:0, recv_task_cnt:0, recv_large_req_cnt:0, tt_large_quries:0, actives:40, workers:40, nesting workers:7, lq waiting workers:0, req_queue:total_size=65537 queue[0]=65537 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=0 queue[5]=0 , large queued:0, multi_level_queue:total_size=0 queue[0]=0 queue[1]=0 queue[2]=0 queue[3]=0 queue[4]=0 queue[5]=0 queue[6]=0 queue[7]=0 , recv_level_rpc_cnt:cnt[0]=0 cnt[1]=0 cnt[2]=0 cnt[3]=0 cnt[4]=0 cnt[5]=0 cnt[6]=0 cnt[7]=0 }) ``` ## 问题原因 - 因 `unit32_t` 溢出而导致 `ObSliceAlloc` 释放陷入死循环的已知 bug。`ObSliceAlloc` 将 64k 的 block 切成若干个 slice，当一个 block 中长时间有（不同）slice 没归还时，该 block 便不能及时回收，被反复使用，与该 `block free` 相关的 `unit32_t` 类型的 push 值不断递增至溢出，进而导致 `ObSliceAlloc` 的 free 线程进入异常状态 (`endless loop pause`) ，hang 住。 - `ObSliceAlloc` 把 64K 的 block 按要求的大小切成若干个定长的小块，在出问题的场景下小块内存是当 `log task` 用的。`64K block` 头部会预留一个 `EmbedFixedQueue` 充当小块内存的 `free list`。`EmbedFixedQueue` 用两个 `uint32_t` 的整数当作 `push/pop` 下标，并且这两个下标只递增不递减，长时间运行后会导致 `uint32_t` 溢出，`ObEmbedFixedQueue::push` 死循环，进而导致队列满。 ## 问题的风险及影响 可能会产生多种问题，严重时会导致集群不可用。 ## 影响的版本 OceanBase 数据库 V2.2.76 (oceanbase-2.2.76-20210716222653) 以下版本。 ## 解决方法及规避方式 - 解决方法 升级至问题已修复版本，目前已修复的版本为 OceanBase 数据库企业版 V2.2.76 (oceanbase-2.2.76-20210716222653) 及以上版本。 - 临时解决方法: 重启 OBServer。参见 [重启 OBServer 节点](https://www.oceanbase.com/docs/enterprise-oceanbase-ocp-cn-10000000002101077)。 上一篇 [日志报错 rs_monitor_check : thread hang](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207659) 下一篇 [V3.2.X 版本开启 “死锁检测” 后 schema 刷新可能导致租户 hang 死](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000439939) ![有帮助](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) 咨询热线