OCP版本：Version: 4.3.0-20240711151555
observer版本： oceanbase-4.2.1.8-108010012024082314.el7.x86_64.rpm
使用的是企业版 OceanBase
问题起初
单副本测试环境集群中租户多并且每个租户的资源规格大多数是以2C与4C为主，因此关闭了默认开启的cgroup， enable_cgroup=off ，集群环境如下图：
OCP监控发现异常
某一天，监控发现某租户cpu资源使用很高，如图：该租户UNIT为 2C，所在服务器是32C
服务器上，通过top -Hp `pidof observer` -b -n 1 > T1658.txt 方式，保存了当时的信息，如下：
线程数理解
observer 进程是单进程的。observer 进程中会起很多种线程，大致可以把线程分成 工作线程 和 后台线程 。
工作线程： 处理 SQL 和事务请求的线程也称为工作线程，是分租户的，也即每个租户都有自己的一套 sql/transaction worker。
一.多租户线程池
线程池：多租户共享一个大线程池，租户从线程池中申请工作线程。线程池跟随多租户进行初始化和销毁，多租户初始化时，预先申请一定数目的线程，后续在租户运行过程中，还支持动态的扩展线程池。
初始线程池大小与 observer 节点的 CPU 数，系统租户预留线程数，虚拟租户预留线程数有关，部分可通过配置项配置。后续扩展线程池时的线程数上限受 OBServer 节点线程数上限和多租户线程数上限共同限制，可通过配置项配置。
线程池相关配置项:
- _ob_max_thread_num：决定 OBServer 节点的线程数上限。默认值为 9999，取值范围为 [0, 10000)，非动态生效。
- server_cpu_quota_min：决定系统租户的最小虚拟 CPU 个数，与机器物理 CPU 无直接关系，仅影响多租户线程池的初始大小。默认值为 0，取值范围为 [0, 16]，动态生效。
- server_cpu_quota_max：决定系统租户的最大虚拟 CPU 个数，与机器物理 CPU 无直接关系，仅影响多租户线程池的上限大小。默认值为 0，取值范围为 [0, 16]，动态生效。
- election_cpu_quota：决定 election 租户的虚拟 CPU 个数，与机器物理 CPU 无直接关系，仅影响多租户线程池的初始大小和上限大小。默认值为 3，取值范围为 [0, 16]，非动态生效。
- location_cache_cpu_quota：决定 location cache 租户的虚拟 CPU 个数，与机器物理 CPU 无直接关系，仅影响多租户线程池的初始大小和上限大小。默认值为 5，取值范围为 [0, 16]，非动态生效。
二.租户线程
活跃线程数概念：活跃线程表示能正常处理请求的线程，与挂起线程区分，活跃线程数用于限制单个租户的 CPU 使用。租户运行时会维持活跃线程数恒定，租户的活跃线程数受配置项和 Unit 规格共同决定。活跃线程数 = unit_min_cpu * cpu_quota_concurrency。
大查询的线程挂起逻辑：用户发给 OBServer 节点的 SQL，可以粗略分为两类：一类 SQL 访问和操作的数据量小，所以执行很快；另一类 SQL 要访问大量的数据或者要写入大量数据，所有执行耗时长。我们把第二类耗时长的 SQL 叫做大查询。
大查询的特殊处理基于一个直观的用户效用假设，从影响用户数和延迟的 QoS（Quality of Service）要求来合理猜想：1000 个小查询被延迟的影响要远大于 1 个大查询被延迟。换言之，与其花 1s 时间处理一个大查询，不如把同样的 CPU 时间用来处理 1000 个小查询。
请求被判定为大查询的条件是，处理时间超过大查询阈值，此阈值可通过配置项调整。
租户线程中持有被判定为大查询请求的线程，一部分可直接获得继续执行权，其余的需要挂起等待。可获得继续执行权的线程的比例由配置项决定。
最大线程数概念：为了维持租户活跃线程数恒定，同时考虑到大查询线程挂起的发生，租户就需要动态的从多租户线程池中申请线程。最大线程数用于限制单个租户的内存开销，每个租户总共可持有的最大线程数受配置项和 Unit 规格共同决定。最大线程数 = unit_max_cpu * workers_per_cpu_quota。
相关配置项：
- cpu_quota_concurrency：决定租户活跃线程数与租户 Unit 规格的倍数关系。默认值为 4，取值范围为 [1, 20] ，动态生效。
- workers_per_cpu_quota：决定租户最大线程数与租户 Unit 规格的倍数关系。默认值为 10，取值范围为 [2, 20]，动态生效。
- large_query_worker_percentage：决定租户线程中享有大查询继续执行权的线程的百分比。默认值为 30，取值范围为 [0, 100]，动态生效。
- large_query_threshold：请求判定为大查询的处理时间阈值。默认值为 5s，取值范围为 [1ms, +∞]，动态生效。
三.并行工作线程
并行执行是一项优化 SQL 查询任务的策略，通过将一个查询任务分解成多个子任务，允许它们在多个处理器上同时运行，从而提升整个查询任务的执行效率。
在当今的计算机系统中，广泛采用多核处理器、多线程以及高速网络连接，使得并行执行成为一种高效的查询技术。这项技术极大地降低了计算密集型大查询的响应时间，并在离线数据仓库、实时报表、在线大数据分析等业务场景得到广泛应用，同时也在批量导数、快速构建索引表等领域展现了其强大的应用能力。
并行执行显著提升了以下 SQL 查询场景的性能：
- 处理大表扫描、大表连接、大数据量排序和聚合。
- 执行大表的 DDL 操作，例如修改主键、改变列类型和创建索引等。
- 从已有的大数据中建表（使用
Create Table As Select）。 - 执行批量插入、删除和更新数据操作。
相关配置项：
- px_workers_per_cpu_quota： 用于设置并行执行工作线程数的比例。默认值为 10，取值范围为 [0, 20] ，动态生效。
后台线程基本固定数量，具体如下：
| 线程名 | 级别 | 归属模块 | 线程数量 | 功能描述 |
| FrzInfoDet | 租户 | 事务 | 2 | 周期性检查是否有新的 freeze_info |
| LockWaitMgr | 租户 | 事务 | 1 | 用于周期性检查超时时间，唤醒等锁的事务 |
| TenantWeakRe | 租户 | 事务 | 1 | 租户级别备机读时间戳生成线程 |
| TransService | 租户 | 事务 | 1 | 处理事务模块内部若干后台处理的异步任务，推 Ls 的 Checkpoint 等 |
| TransTimeWhe | 租户 | 事务 | max(cpu_num/24, 2) | 处理事务 2PC 流程的定时任务 |
| TsMgr | 进程 | 事务 | 1 | GTS 的后台任务处理线程：删除无用的租户，刷新各个租户的 GTS 等 |
| TSWorker | 进程 | 事务 | 1 | 处理远程 GTS 访问返回的结果，回调事务 |
| TxLoopWorker | 租户 | 事务 | 1 | 事务模块后台定时任务 |
| ArbSer | 进程 | 系统 | 1 | 仲裁 Server 定时从配置文件加载配置参数 |
| Blacklist | 进程 | 系统 | 2 | 负责探测与通信目的端 Server 之间的网络是否联通 |
| ConfigMgr | 进程 | 系统 | 1 | 用于配置项的刷新 |
| L0_G0 | 租户 | 系统 | 2+min_cpu * cpu_quota_concurrency | 处理大部分该租户请求 |
| L2_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 2 的请求 |
| L3_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 3 的请求 |
| L4_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 4 的请求 |
| L5_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 5 的请求 |
| L6_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 6 的请求 |
| L7_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 7 的请求 |
| L8_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 8 的请求 |
| L9_G0 | 租户 | 系统 | 1 | 专门处理嵌套层级为 9 的请求 |
| LuaHandler | 进程 | 系统 | 1 | 处理应急场景的 Lua 请求以读取 observer 进程内部状态 |
| MemDumpTimer | 进程 | 系统 | 1 | 定时打印 MEMORY 日志 |
| MemoryDump | 进程 | 系统 | 1 | 定时统计内存信息 |
| MultiTenant | 进程 | 系统 | 1 | 负责刷多租户 CPU 配比，用于资源调度 |
| OB_PLOG | 进程 | 系统 | 1 | 异步打印 observer 进程诊断日志 |
| pnio | 进程 | 系统 | 由 net_thread_count 配置的参数决定 | 新网络框架 pkt-nio 的网络 IO 线程 |
| pnlisten | 进程 | 系统 | 1 | 监听 RPC 端口以及转发 RPC 连接到网络 IO 线程 |
| SignalHandle | 进程 | 系统 | 1 | 信号处理线程 |
| SignalWorker | 进程 | 系统 | 1 | 异步处理信号线程 |
| L0_G2 | 租户 | 选举 | min_cpu，最少 8 个 | 专门处理选举请求的线程 |
ocp监控显示计算方式
租户UNIT为 2C，所在服务器是32C
- 关闭cgroup，租户CPU的限制是弹性的，属于软隔离，是限制线程数。
计算方式：
活跃线程数=2*4(cpu_quota_concurrency)=8
并行线程数=2*10( px_workers_per_cpu_quota)=20
因此，没启用并行，租户工作线程可以占用8C(OCP监控看到租户CPU消耗400%)；启用并行，租户工作线程可以占用最多8+20=28C(OCP监控看到租户CPU消耗1400%)，与上述异常监控图一致。
- 开启cgroup，租户CPU的限制不再是弹性的，属于硬隔离，是限制使用率。
线程的数量不变，但服务器最多只会消耗2个CPU用来租户的工作，OCP监控看到租户CPU消耗100%。