问题现象
删除租户后，理论上租户对应的 Unit 会被 GC 掉，但是 GC 的过程失败了，可能会影响租户内存回收，导致删掉的租户对应内存无法释放给 OBServer 给其他租户使用。
本质原因
租户删除的流程中 GC 失败，是因为有 session 未释放，session 未释放的原因是有请求持有 session 未执行结束。这是因为代码固有缺陷，在删除租户时未将一个用于请求重试的队列清空，导致一些请求残留在队列当中，这些重试请求可能持有一些资源，比如 session 等，这些资源也随之泄漏。
请求重试背景
租户请求处理过程中，对于行锁冲突，有 lock wait mgr 延迟重试机制，在遇到其他一些需要重试的场景下，过于频繁的重试不仅无效还会增加 CPU 开销，因此引入了延迟重试队列机制，需要重试的请求被放入定时器队列，间隔若干时间后再重新丢回正常请求队列。
触发概率和风险
触发概率不高，在有重试请求的场景 + 租户删除/迁移操作时，就有概率触发。 这个现象的风险可控，因为并不会卡住创建租户的线程，从而影响租户创建和调度。只是容易占用内存，导致新租户创建因内存不足而失败。
关键诊断信息
触发条件
租户删除/租户 unit 迁移的过程，老 unit 所在机器在租户删除的流程中，未能将重试队列中的请求清空，导致请求泄漏，请求持有的 session 也随之泄漏，导致租户 unit gc 不掉，影响租户内存回收，影响 OBServer 可用内存。
事前巡检
无。
事后诊断
查
__all_virtual_session_info表找到问题节点session_killed标记，count =1表示有一个 session 属于 killed 但未结束的状态。
据
kill session successfully日志找到当前时间段释放不掉的 session id 和对应的 sql。
根据 sql 和 session id 找到对应 trace id，在 trace id 上下文看有没有
tenant push retry request to wait queue日志。
问题原因
租户 unit 迁移的过程，老 unit 所在机器会走到对应租户的删除流程，由于已知代码缺陷，未能将重试请求队列中的请求清空，导致请求泄漏，请求持有的 session 也随之泄漏，导致租户 unit gc 不掉，影响租户内存回收。
问题的风险及影响
unit gc 失败，内存被持续占用，可能导致 OBServer 内存不足，影响新 unit 的迁入。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响的版本
OceanBase 数据库 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。
解决方法
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库 V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）、V3.2.4 BP8（oceanbase-3.2.4.8-108000142024041520）。
规避方式
事前无法规避。事后可通过重启 OBServer 恢复。如果 unit gc 不掉占用了过多内存导致内存不足，可通过扩充 OBServer 内存规格的方式，临时保证未回收干净的租户不影响新租户的创建。
