大量并发编译 PL 可能造成 CPU 飙高

问题现象

当大量 session 并发执行 PL package 中过程/函数时，如果没有命中 PL Cache，可能造成这些工作线程同时编译 PL package，导致 CPU 飙高。该问题影响 OceanBase 数据库 V4.2.1 及之前所有版本，在 OceanBase 数据库 V4.2.2 及之后版本实现了 PL 编译结果落盘功能后不再出现。

关键诊断信息

触发条件

大量含有 package 的请求同时执行且没有命中缓存时可能触发此问题。

事前巡检

通过以下 SQL 检查业务高频使用的 package 是否在缓存中。

• 查询 gv$ob_plan_cache_plan_stat 视图。

  ## OceanBase 数据库 V4.x 版本
  select * from gv$ob_plan_cache_plan_stat where pl_schema_id = <pkg_id>;
  

• 查询 gv$plan_cache_plan_stat 视图。

  ## OceanBase 数据库 V3.x 版本
  select * from gv$plan_cache_plan_stat where pl_schema_id = <pkg_id>;
  

  注意

  如果查询没有结果，则说明不在缓存，需要通过调用 package 进行预热。

事后诊断

当 OBServer CPU 飙高时，及时抓取 obstack，并在结果中搜索 compile_package，如果发现大量线程都在编译 package，则有可能命中此问题。

问题原因

如果一个工作线程在执行 PL package 时，无法从 PL Cache 中获取编译结果，则会触发编译流程。当有大量请求触发这个流程时，可能占用多个工作线程进行并发编译，导致 CPU 飙高。尤其当 package 很大（数万行）时，可能需要几百秒进行编译，现象会更加明显。

问题的风险及影响

可能造成 OBServer CPU 飙高，请求响应缓慢，影响业务稳定性。

影响租户

影响 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.2 G（Aoceanbase-3.2.2-20211130225726）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本。

解决方法及规避方式

• 解决方法：

  1. 通过 show processlist 找到正在编译的 package 。

  2. 先尝试 kill session 是否可以停止编译，如果无效再继续执行下面的操作。

  3. 在 OCP 上寻找每个节点 CPU 使用率都较低的 Zone，并直连这些节点预热此 package，即调用一次该 package 触发编译并加入缓存。

  4. 切主到已经预热好的 Zone。

  5. 重启 CPU 飙高的 OBServer 节点。

• 规避方式：

  1. 线上系统禁止在业务高峰时期做 DDL，防止 schema version 变更导致 PL Cache失效。

  2. 提前预热系统，在业务开始之前调用一次 PL，触发编译并加入缓存。

  3. 将大 package 拆分为多个 standalone procedure/function，这样可以减少每次编译需要的时间，同时 standalone procedure/function 编译有锁，不会出现编译导致的 CPU 飙高。