OceanBase 并行执行学习笔记 3 —— 并发控制与排队

在一定场景下，并行查询会因为等待线程资源而排队，本篇博客就来简单介绍一下并行执行线程资源的管理方式。

并行执行系列的内容分为以下七篇博客，本篇是其中的第三篇。

3.1 并行执行并发控制

我们通过租户级变量 PARALLEL_SERVERS_TARGET 指定租户在每个节点上最多可提供的并行执行工作线程数。在并行查询开始之前，从所有相关 observer 预约工作线程资源，只要其中任何一个 observer 不能为并行查询提供足够资源，就不会投入执行。该并行查询会被丢回查询队列排队，等待下次执行时重新尝试获取线程资源，直到能获取到足够工作线程资源才能获准执行。整个查询执行完成后，立即释放预约的工作线程资源。

这种“尝试预约工作线程资源-资源不足丢回查询队列-再次获得执行机会-再次尝试预约工作线程资源”的过程我们称之为并行查询排队。管理全部 observer 工作线程资源预约的模块称为并行执行资源管理器。

并行执行资源管理器为了计算每个并行查询需要的工作线程数，会将查询计划做 DFO 划分，模拟调度 DFO 过程，根据 parallel hint、table parallel 等参数计算出该查询在每个 observer 上需要的最大线程数。这组线程数我们称之为“资源向量”。

资源向量是逻辑概念，用于控制并发与排队。使用资源向量从并行执行资源管理器中预约到足够工作线程资源后，并行查询会投入执行。在执行过程中，尽管随着不同 DFO 的调度执行，会不断有物理线程的获取和释放，但是逻辑上的线程资源并不会归还给并行执行资源管理器。只有在并行查询完全执行完成后，这组资源向量才会归还给并行执行资源管理器。

当大量并发查询从并行执行资源管理器预约线程资源时，采取先来先服务的策略，直至资源分配殆尽，无法满足任何一个查询的资源需求为止。之后的查询都会丢回查询队列排队，再次调度时重试获取资源。

3.2 并行执行工作线程分配

在租户的每个 observer 上都有一个并行执行线程池，用于执行并行查询任务。执行任务时，如果线程池里线程数量不足，会动态扩容线程池。如果线程池里的线程空闲时间超过 10 分钟，会触发自动缩容到 10 个线程；如果线程池里的线程空闲时间超过 60 分钟，会触发进一步缩容，可能缩容到 0 个线程。

并行查询一旦获得调度执行后，每个 DFO 总是可以在它涉及到的 observer 的并行执行线程池里获得需要的并行线程资源。需要注意的是，默认情况下，每个 DFO 在一个 observer 上分配的线程数，不得大于租户 MIN CPU * 10，如果它提出的资源需求大于这个值，会被自动降低为 MIN CPU * 10。

3.3 两级资源控制模型

对于任意并行查询，它会经历两级资源控制：

• 全局控制：在执行资源管理器的控制下，预约包含足够执行线程的资源向量
• 局部控制：在并行执行线程池的控制下，分配期望的物理线程数

全局控制会考虑分布式场景下的资源获取，局部控制仅考虑单机线程池的资源分配，二者各司其职。前者确保Query 通过检查后一定能够执行下去，不会在运行时遇到拿不到资源的问题，后者确保极端情况下单个 Query 的 DFO 不会申请远大于能有效利用的物理线程数，造成线程资源浪费。一个并行查询，只要通过了全局控制阶段，就可以顺利执行，无论并发多大，都不会遇到物理线程数不足的问题。

3.4 并行执行资源管理器相关视图

并行执行资源管理器拥有全局视角，通过视图 GV$OB_PX_TARGET_MONITOR能看到租户内每个 observer 的线程预约状态。关于视图字段详细含义，可以参考 ob 官网上的视图手册。

OceanBase(admin@oceanbase)>select  * from GV$OB_PX_TARGET_MONITOR;
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
| SVR_IP       | SVR_PORT | TENANT_ID | IS_LEADER | VERSION         | PEER_IP      | PEER_PORT | PEER_TARGET | PEER_TARGET_USED | LOCAL_TARGET_USED | LOCAL_PARALLEL_SESSION_COUNT |
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
| 192.168.11.2 |    19512 |      1004 | N         | 555393108309134 | 192.168.11.1 |     19510 |          10 |                6 |                 0 |                            0 |
| 192.168.11.2 |    19512 |      1004 | N         | 555393108309134 | 192.168.11.2 |     19512 |          10 |                0 |                 0 |                            0 |
| 192.168.11.1 |    19510 |      1004 | Y         | 555393108309134 | 192.168.11.1 |     19510 |          10 |                6 |                 6 |                            1 |
| 192.168.11.1 |    19510 |      1004 | Y         | 555393108309134 | 192.168.11.2 |     19512 |          10 |                0 |                 0 |                            1 |
+--------------+----------+-----------+-----------+-----------------+--------------+-----------+-------------+------------------+-------------------+------------------------------+
4 rows in set (0.002 sec)

在一个瞬态里，不同 observer 看到的全局状态可能不一致，但后台每 500 毫秒就会同步一次全局状态，总体上各个 observer 看到的状态会基本一致，不会有太大偏差。