设置并行执行参数

OceanBase 提供了一组参数，用于控制并行执行的初始化和调优。

在 OceanBase 启动时，可以根据租户的 CPU 数量和租户配置项 px_workers_per_cpu_quota 计算出默认的并行执行控制参数。用户也可以选择不使用默认值，在启动时手动指定参数值，并在后期根据实际场景手动调整参数值。

并行执行功能默认是开启的。本文从以下几个方面说明并行执行参数控制技巧：

• 并行执行默认参数
• 并行执行相关参数调优

并行执行默认参数

并行执行的参数能够控制并行线程数、并行执行排队等行为。具体总结如下表：

为了降低用户使用并行执行的门槛，OceanBase 将并行执行参数个数降到了最低，使用默认参数即可实现开箱即用。在特殊场景下，用户可以通过改变默认参数来实现应用调优。

px_workers_per_cpu_quota

该参数表示在每个 CPU 上可以分配的并行执行线程数。当分配给租户的 MIN CPU 为 N 时，如果并行负载均匀，那么每个节点上可以分配的线程数为 N * px_workers_per_cpu_quota。如果并行负载访问的数据分布不均匀，某些节点上实际分配的线程数可能在短时间内超过 N * px_workers_per_cpu_quota，当负载结束后，这些多分配的线程会被自动回收。

px_workers_per_cpu_quota 对 parallel_servers_target 默认值的影响仅发生在创建租户时，租户创建完成后，修改 px_workers_per_cpu_quota 的值并不会改变 parallel_servers_target 的值。

一般情况下，不需要更改 px_workers_per_cpu_quota 的默认值。当未开启资源隔离特性时，如果发生并行执行占用了全部 CPU 资源的情况，可以尝试通过降低 px_workers_per_cpu_quota 参数的值来缓解该问题。

parallel_servers_target

该参数表示租户在每个节点上可申请的并行执行线程资源数量。当资源耗尽时，并行执行请求需要排队。关于排队的概念，请参考 并发控制与排队。

并行执行的 CPU 使用率非常低，可能是因为 parallel_servers_target 值太小，导致 SQL 的 DOP 被降级，实际分配的线程数小于期望的数量。

在 OceanBase 数据库 V3.2.3 版本之前，parallel_servers_target 的默认值非常小，可以通过调大 parallel_servers_target 的值来解决，建议设置为 MIN CPU * 10。

在 OceanBase 数据库 V3.2.3 版本起，parallel_servers_target 的默认值为 MIN CPU * 10，一般不会遇到这个问题。

设定好 parallel_servers_target 的值后，重新连接，执行如下命令查看最新值：

SHOW VARIABLES LIKE 'parallel_servers_target';

从运维的角度，为了避免频繁调整，可以给 parallel_servers_target 设置一个最大值。理论上，可以将 parallel_servers_target 设置得无穷大，这时会面临一个问题：低效。所有的查询都不排队，它们都开始执行，并争抢 CPU 时间片、争抢磁盘 IO、网络 IO。

从吞吐量的角度看，这个问题不算严重。从单个 SQL 延迟的角度看，这种争抢会严重影响延迟。综合考虑 CPU 和 IO 的利用率，可以以租户 UNIT 的 MIN CPU 为基准，一般把 parallel_servers_target 设置为 MIN CPU * 10 即可；少数 IO 密集型场景，CPU 可能用不满，可以将 parallel_servers_target 设置为 MIN CPU * 20。

parallel_degree_policy

该参数是自动 DOP 开启开关，当设置为 AUTO 时，会开启自动 DOP，优化器根据统计信息自动计算 Query 的并行度。当设置为 MANUAL 时，根据 HINT、TABLE PARALLEL 属性、SESSION 级 DOP 等控制并行度。

在 OceanBase 数据库 V4.2 起，如果用户不熟悉并行度的设置规则，可以设置 parallel_degree_policy 为 AUTO，让优化器帮忙自动选择并行度。关于自动并行度的计算规则，请参考 设置并行度及优先级。

在 OceanBase 数据库 V4.2 之前的版本，不支持 parallel_degree_policy 开关，不支持自动 DOP 功能，需要手动设置。

并行执行相关参数调优

ob_sql_work_area_percentage

租户级变量，用于限制 SQL 模块可以使用的最大内存。它是一个百分值，表示占租户总内存的比值，默认为 5，表示占租户内存的 5%。当 SQL 使用的内存超过限制时，会触发内存落盘。

SQL work area 内存的实际使用量，可以在 observer.log 日志中搜索 WORK_AREA。例如：

[MEMORY] tenant_id=1001 ctx_id=WORK_AREA hold=2,097,152 used=0 limit=157,286,400

在读多写少场景下，如果 SQL 模块内存受限导致数据落盘，可以适当增大 ob_sql_work_area_percentage 的值。

workarea_size_policy

OceanBase 实现了全局自适应的内存管理，当 workarea_size_policy 设置为 AUTO 时，执行框架会以最优的策略为各个算子（如 HashJoin、GroupBy、Sort 等）分配内存，开启自适应的数据落盘策略。

并行 DML 参数调优

• OceanBase 数据库 V4.1 起，如果没有事务要求，向表中导入数据时建议使用 INSERT INTO SELECT 加上旁路导入功能，一次性将数据插入到新表。这种方式既可以缩短导入时间，也可以避免写入太快导致内存不足的问题。

• OceanBase 数据库 V4.1 之前的版本，如果单条并行 DML 执行时间超过 30 分钟，则需要设置 undo_retention 值，详情请参考 并行执行分类 中的事务处理。