最近社区和问答区里聊人大金仓KingbaseMPP部署的人明显多起来但每次提到MPP总有人跳出来问这是不是LS-DYNA那个MPP并行版本还有人问MPXJ导不出.mpp格式文件是不是出bug了——那确实只是Microsoft Project的二进制工程文件跟数据库没半点关系。我近几年一直在生产环境维护好几套人大金仓集群从单机到MPP都折腾过今天不聊架构宣传页上的话术只聊一个最实际的问题在MPP场景下线程到底怎么设才能让查询又快又稳、又不把节点资源耗干。这篇文章适合三类人正在给金仓MPP集群做初始化配置的DBA遇到过“并行一开查询反而变慢”的业务开发以及准备做性能压测但不知道从哪下手的技术负责人。我会把参数关系、配置思路、实测案例和踩坑记录一次讲清楚你照着调就行。1. 先搞懂MPP在Kingbase里到底是什么形态1.1 别再把“MPP集群”和“并行查询”混为一谈很多人一上来就改并行参数结果发现集群没提速原因就是没分清楚两个层次。MPP全称Massively Parallel Processing大规模并行处理指的是由多个独立节点组成一个集群每个节点有自己的CPU、内存、存储数据分散在各节点上查询时所有节点同时开工由协调节点汇总结果。这是Shared Nothing架构跟“把一块磁盘共享给多台机器”的Shared Disk是两条路。而在单个节点内部Kingbase还有一个并行查询机制也就是把一个节点的数据扫描或计算任务拆给多个并行worker进程利用多核CPU同时执行。这个机制你把它理解成“单机内并行”就好。关键点来了在MPP集群里这两层是叠加的。数据节点的查询计划先把任务分发到各个节点各节点在本地还要再决定是否启动并行worker。所以在MPP里调线程不只是调“一个查询用几个worker”还要同时考虑“节点间并行度”和“节点内并行度”的乘积会不会把资源打爆。很多刚接触的人只盯着max_parallel_workers_per_gather改到16甚至32结果一个查询就把节点CPU全部占满其他查询全部排队这就是把两层混为一谈的典型表现。先把这个概念理顺后面调参才不会跑偏。1.2 金仓MPP集群里的两类角色线程设置重点完全不同在Kingbase的MPP部署里节点大致分两类角色协调节点有的文档叫Coordinator和数据节点Segment。协调节点不存业务数据或者说业务数据主要落在数据节点上它的职责是接收应用发来的SQL生成分布式执行计划把子任务分发给各数据节点最后汇总结果返回给应用。数据节点则真正存储数据负责执行下发的子任务。这两类角色的线程设置思路完全不同。协调节点因为要接收大量并发会话、做计划、汇总结果对连接处理上限和worker调度能力要求高但不需要给它配很高的本地并行度否则它自己先把CPU打满反而成为瓶颈。数据节点才是真正干重活的地方并行worker要优先保证数据节点有充足的配额。我见过不少部署方案把协调节点和数据节点配置成完全一样这不算错但在高并发场景下协调节点往往先出现瓶颈。后面我会给出一套分开配置的建议核心思路就是协调节点重连接、轻并行数据节点轻连接、重并行。尤其当应用直连协调节点时协调节点的连接参数会直接决定你能接入多少并发请求这个坑比想象中隐蔽。1.3 线程设置的本质用空闲CPU换查询时间讲参数之前先把这个问题的本质想明白。数据库线程设置不是什么高端算法本质就是一句话在业务低峰或CPU有空余的时候让一次查询能动用更多CPU资源把原本串行的扫描、排序、聚合拆成多份同时做缩短单条查询的时间。代价也很明显更多的worker意味着更多的内存占用每个worker都有独立的work_mem、更频繁的上下文切换、更激烈的I/O争抢。所以线程设置并不是越大越好而是要在“单查询延时”和“系统整体吞吐”之间找平衡点。这也是为什么后面所有建议都强调“拿真实SQL做压测”因为不同业务的查询形态差别太大了。有些系统是低并发大查询可以把单查询并行度拉满有些系统是高并发小查询并行开得过大反而害了自己。有了这个认知下面看参数就清楚了每一个参数都是在控制“资源换时间”的杠杆向哪边倾斜。2. 线程相关参数全景从连接线程到并行worker2.1 第一条线连接线程每个会话都有开销先看连接层面的参数。Kingbase内核和PostgreSQL一脉相承一个客户端连接通常对应一个后端进程这个进程要占内存、要参与调度所以max_connections决定了系统最多能同时接入多少会话。在MPP集群里还有个容易忽略的点应用连的是协调节点但协调节点在执行分布式任务时还要向数据节点发起内部连接。也就是说协调节点上的一个用户会话可能在每个数据节点上都对应着内部会话。如果max_connections只按“应用并发数”来设没算上数据节点上由协调节点转发的内部连接就很容易在业务高峰触发too many connections错误。实际建议是数据节点的max_connections要给协调节点预留足够余量。比如协调节点允许200个并发应用会话有20个数据节点那每个数据节点至少要有200个内部连接额度再叠加本节点上其他管理维护连接就要把max_connections设到220到250左右。这不是线程参数但它是线程设置的前置条件连接数不够并行worker再充足也进不来。之前在压测时就吃过这个亏应用并发一上去集群直接报连接数超限查了半天才发现是数据节点内部连接额度没预留够。2.2 第二条线并行worker真正的“干活线程”Kingbase的并行执行模型里有几个核心GUC参数必须搞懂我按调度顺序讲max_worker_processes整个数据库实例允许启动的后台工作进程总数。它不只是给并行查询用的还有运维任务、日志、复制等都从这里面取名额。这个参数必须重启才能生效。max_parallel_workers实例级别的并行worker总配额。在max_worker_processes名额里再划出“用于并行查询”的部分超过这个数新来的并行查询就得排队。max_parallel_workers_per_gather单个查询里一个Gather节点最多能启动多少个并行worker。也就是说单条SQL在同一时刻能用的最大并行worker数实际是受它控制的。max_parallel_maintenance_workers维护类操作比如CREATE INDEX、VACUUM可用的并行worker数和查询并行相互独立但同样要从max_worker_processes总池子里面扣名额。min_parallel_table_scan_size / min_parallel_index_scan_size触发并行扫描的阈值。表太小优化器认为没启动并行的必要就不会走并行计划。parallel_setup_cost / parallel_tuple_cost优化器估算并行启动代价和tuple传递代价的参数。设得越大优化器越倾向保守不愿走并行。这里有个必须记牢的约束关系max_worker_processes max_parallel_workers max_parallel_workers_per_gather。如果max_parallel_workers设得比max_parallel_workers_per_gather小那单查询即使想申请更多worker也申请不到如果max_worker_processes都不够大那并行worker和后台任务会抢名额。这三层关系就像公司的编制max_worker_processes是公司总HCmax_parallel_workers是其中分给“并行计算团队”的名额max_parallel_workers_per_gather是单个项目最多能分配的人。团队总名额不够项目想多要人也不行。还有一个容易被忽略的参数是work_mem。每个并行worker在进行排序、哈希连接、聚合时都有自己的work_mem配额所以并行度翻倍这部分内存消耗也翻倍。很多“并行一开就OOM”的问题根源不在并行worker数量而在work_mem按并发数成倍放大。比如全局work_mem设64MB一条SQL启动8个worker光排序就可能吃512MB并发几条SQL内存很快就没了。2.3 参数的生效层级改了没效果先看你改在哪一层Kingbase的参数生效方式遵循PostgreSQL系的层级体系配置文件和ALTER SYSTEM是实例级ALTER DATABASE是库级ALTER USER是用户级SET是会话级还有表级的存储参数比如表的parallel_workers。实际调优中我的优先级经验是需要大多数人统一的设置比如总worker数放配置文件或ALTER SYSTEM只针对某个业务库或某个报表账号的设置放到数据库级或用户级临时排查问题用SET不落地热点大表用ALTER TABLE SET (parallel_workersN)单独指定这样其他小表不受影响。很多“参数改了没效果”的案例最后发现是改在了session级连接一断开设置就没了。或者ALTER SYSTEM改完之后没有reload或重启系统还跑着旧值。判断方法很简单执行SHOW命令查看当前生效值再对比你预期的值即可。注意形如max_worker_processes、max_parallel_workers这种POSTMASTER级别的参数ALTER SYSTEM改了也必须重启数据库实例才会生效SHOW一下看看就知道是不是没重启。这一章的问题要是没理清后面调的参数基本都是白调。3. MPP线程设置的实操方法与建议值3.1 第一步摸清底数别上来就改参数我调MPP线程前会先列一张“底数清单”每节点CPU核数要区分物理核和逻辑核Linux下lscpu看、内存总量、存储类型SSD还是机械盘、磁盘数量、业务并发峰值、典型SQL的量和复杂度。这些信息决定后面所有参数。比如机械盘环境下并行worker太多会让磁头在多个文件间来回颠簸I/O反而变慢这时候并行度要保守SSD或NVMe环境下I/O争抢小并行度可以激进一些。另外还要确认MPP集群里各节点配置是否一致。如果各节点CPU、内存不一样那么并行调度会受最慢节点拖累集群整体体验就是“总是有个节点掉队”。生产环境最好同构如果已经异构了参数要以最差节点为准来定否则慢节点一定会成为瓶颈。3.2 第二步先定单节点并行度从“核数减2”开始给数据节点定并行度我推荐一个逐步收敛的方法。初始值这样设max_worker_processes CPU核数 系统预留后台进程数通常再加4到8max_parallel_workers CPU核数的一半到三分之二max_parallel_workers_per_gather min(4, max_parallel_workers / 期望并发大查询数)举例16核数据节点如果期望高峰时期最多2个大查询同时跑先设max_worker_processes20max_parallel_workers8max_parallel_workers_per_gather4。这样单个查询最多4个worker并行2个大查询合计最多8个worker加上其他后台任务大概12到14个线程在忙留了2到4个核给系统、网络和操作系统调度比较稳妥。如果只是单查询性能优先且并发很少可以把per_gather调到CPU核数减2比如16核设14但这是很极端的场景。实际业务中一个小查询启动14个worker反而会大幅拉长调度时间得不偿失。普通分析型负载下per_gather在2到8之间更常见。我通常建议从一个偏保守的值起步观察CPU利用率和查询耗时后再逐步往上加一次只加一个档位。3.3 第三步协调节点和数据节点分开配MPP集群里同一套参数不建议直接复制到所有节点。下面是一套我常用的“分离配置”思路协调节点max_connections按应用并发数加管理预留设高一些max_parallel_workers_per_gather设小一点比如2因为它主要做计划、分发、汇总本地数据少并行度给高了也用不上反而抢占CPU。数据节点max_connections要算上协调节点转发的内部连接max_parallel_workers和per_gather按前面“核数减2”思路来设是真正的并发主力。在并发模型上还要想清楚一个问题协调节点是按连接并发做调度的数据节点是按查询任务做调度的。大量应用连接同时压到协调节点时如果协调节点CPU被打满即使数据节点有富余整个查询入口也进不来。所以协调节点的CPU预留比并行度更重要。实际部署时我还会给协调节点单独留一两个CPU给管理工具和监控agent避免它们和数据库抢资源。3.4 第四步用EXPLAIN验证设置有没有真生效改完参数第一时间看执行计划。在Kingbase里执行EXPLAIN如果是并行计划通常能看到Gather或Gather Merge节点下面会标注Workers Planned: N和Workers Launched: N。前者是优化器打算用的worker数后者是实际启动的worker数。Workers Launched小于Workers Planned说明运行时worker名额不足或资源受限。示例SQLEXPLAIN (ANALYZE, BUFFERS) SELECT c_custkey, count(*) FROM orders GROUP BY c_custkey;如果执行计划里看到类似下面的片段说明并行确实生效了Gather Workers Planned: 4 Workers Launched: 4 - Partial HashAggregate - Parallel Seq Scan on orders如果看不到Gather节点就要回溯检查前面那些阈值参数。调试时我有两个常用技巧临时把parallel_setup_cost和parallel_tuple_cost都调成0把min_parallel_table_scan_size也调成0强制优化器考虑并行计划用来确认“表能不能走并行、worker能到多少”。确认之后再把参数恢复。第二个技巧是对热点大表直接执行ALTER TABLE SET (parallel_workers4)如果表上的统计信息不够可靠ALTER就是最直接的干预手段。注意force_parallel_mode这类测试性参数不要在生产环境开它会把本不该并行的小查询也强制并行副作用很大只适合在测试库里做机制验证。4. 典型配置案例8节点MPP集群调优实录4.1 环境与初始配置某业务的分析型系统8个节点组成MPP集群1个协调节点加7个数据节点。每节点16核CPU64GB内存SSD存储。业务以定时跑批为主高峰期同时跑20个左右的报表SQL单SQL扫描的数据量普遍在几千万行到几亿行。初始配置是安装后的默认参数max_parallel_workers_per_gather2max_parallel_workers8max_worker_processes8work_mem4MB。结果跑批任务经常出现两条慢SQL把整个集群拖慢总耗时要四十多分钟部分SQL执行计划里根本看不到Gather都在单节点串行执行。团队成员一开始以为是MPP没生效后来排查发现就是并行worker配额太小优化器算来算去都觉得并行不划算。4.2 两轮调整过程与对比第一轮调整把参数水平整体提上去。max_worker_processes从8调到20max_parallel_workers保持8因为一开始不敢一下放开max_parallel_workers_per_gather从2调到4max_parallel_maintenance_workers从2调到4work_mem从4MB调到16MB只针对报表会话因为全局涨会把内存顶爆。重启后重跑跑批效果是有的原来几乎全串行的计划开始出现Gather节点多张大表查询能用到4个并行worker。整体耗时从四十多分钟降到三十分钟左右。但问题也来了高峰时CPU经常冲到100%出现几个查询相互抢worker执行计划里Workers Launched只有2或3说明总配额不够。这时就体现出max_parallel_workers8的限制per_gather设到4最多只能同时支撑2个查询各自用满4个worker第三个查询就只能饿肚子。第二轮调整把总盘子扩大并按表干预。max_parallel_workers从8调到16max_parallel_workers_per_gather保持4给几个高达几亿行的核心大表显式指定parallel_workers8避免优化器按默认估算给不够worker给报表专用账号设置会话级work_mem32MB避免全库内存爆炸。这次跑批耗时进一步降到十八分钟左右。CPU峰值还是在95%左右但worker排队现象明显减少。原因是max_parallel_workers扩到16后4个大查询同时启动时每个都能稳定拿到4个worker核心大表强制8个worker后单表扫描和聚合阶段明显缩短。整体结果是我们在这个系统上最后定的组合一直稳定运行到现在。4.3 为什么这组配置能起效果事后复盘这组配置起作用的关键点有三个。一是把max_worker_processes和max_parallel_workers一起拉大让并行worker在整个实例层面有足够的“编制”否则per_gather设得再大总配额不够也没用。二是对核心大表用表级parallel_workers做强制指定绕开了优化器基于采样统计做估算的不确定性。三是work_mem分账号设置没有无脑调全局所以并行度提高后内存没有被引爆。这个案例也再次说明MPP调线程不能只调某一个参数。per_gather是单个查询的“手臂”max_parallel_workers是实例的“总预算”max_worker_processes是整台机器的“编制”三个得一起调还要配合work_mem等内存参数才能让并行真正跑起来又不出故障。配置改完后一定要留好变更记录我习惯把每次调整的参数和压测结果写在一个文档里后面复盘效率高很多。5. 常见问题与排查技巧实录5.1 改了参数执行计划还是串行这是问得最多的问题。可能原因有表太小没超过min_parallel_table_scan_size阈值parallel_setup_cost和parallel_tuple_cost偏高优化器认为启动并行不划算表上的统计信息太旧优化器不知道表已经变大或者并行相关总配额已经被其他查询占满。排查思路先看表大小和统计信息执行ANALYZE更新统计再用EXPLAIN看计划临时把触发阈值调低测试。前面说过把min_parallel_table_scan_size和parallel_setup_cost临时调0是很有效的诊断手段。如果调0之后还是串行那多半不是阈值问题而是SQL结构本身不适合并行比如存在强依赖的前后关联子查询优化器无法安全拆分。这种情况别硬调参数先把SQL改写思路放上去。5.2 并行一开CPU满但查询更慢症状是执行计划里明明有GatherCPU也飙到100%但查询耗时反而比串行还长。这种我见过不少常见原因有这么几类work_mem太小导致每个worker都写临时文件I/O能力跟不上并行worker都在抢磁盘查询本身太短启动worker的调度开销比并行收益还大或者MPP下数据分布不均某个节点数据多其他节点做完干等。排查技巧是分阶段测量。先用一个单表count或全表聚合的简单查询压并行看纯粹扫描能力是否提升再换成真实复杂SQL对比是否多个worker都在做重活最后看数据分布比如按where条件分组的字段如果某些值占比过高并行任务必然倾斜。遇到短查询并行反而变慢的情况可以直接把它的表级parallel_workers设为0让这个查询老实走串行比纠结全局参数更划算。5.3 MPP集群中某个节点总是掉队集群所有节点配置一样但每次跑批某个数据节点用时长一大截整体被它拖慢。这种“掉队”问题通常不是线程设置导致的但会被错误的线程设置放大。先查数据分布是否均匀比如检查一张大表在各节点上的行数如果某节点数据多出一倍就要考虑重新分布或调整分布键。再看该节点是否还有别的业务比如备份、统计任务都在同一个时间段跑CPU本身就有压力。线程层面的缓解办法是掉队节点的并行度适当调低避免它同时承担过重的并行任务协调节点的任务调度尽量保持均匀避免总是把最重的任务发给同一个数据节点。根本上还是要把数据分布和统计信息维护好每次大批量数据变更后及时ANALYZE。数据倾斜不解决线程参数调得再精细集群也快不起来。5.4 踩坑速查表症状可能原因优先处理建议执行计划没有Gather表太小、阈值太高、统计过旧ANALYZE后临时调低阈值测试Workers Launched小于Plannedmax_parallel_workers总配额不足扩大总配额降低per_gather并行后反而变慢work_mem不足、I/O瓶颈、查询太短调大会话级work_mem确认存储能力CPU打满但吞吐上不去并行度过于激进减小per_gather错峰执行大查询某节点耗时突出数据倾斜、节点负载不均检查分布键均衡数据错开维护任务修改参数不生效层级不对、未重启SHOW查看当前值区分动态和重启参数这个表基本覆盖了我这些年遇到的大部分线程设置问题。真遇到没把握的情况经验是少动参数先看数据和计划再决定要不要调。参数都是手段不是目的最终要为业务查询服务。最后分享一个我比较坚持的做法每次调完线程参数不要只看一两条SQL就下结论。MPP的并行效果是一个系统行为至少要拿一套覆盖你业务典型查询的脚本在同样数据量和同样并发下跑前跑后对比才算数。我在生产环境就是这么干的把每个版本的参数组合都留记录哪天出问题也能快速回退。线程设置这件事没有一成不变的银弹只有对自己的数据和SQL摸得越透参数才能调得越准。
人大金仓MPP线程设置实战：从参数原理到调优案例
最近社区和问答区里聊人大金仓KingbaseMPP部署的人明显多起来但每次提到MPP总有人跳出来问这是不是LS-DYNA那个MPP并行版本还有人问MPXJ导不出.mpp格式文件是不是出bug了——那确实只是Microsoft Project的二进制工程文件跟数据库没半点关系。我近几年一直在生产环境维护好几套人大金仓集群从单机到MPP都折腾过今天不聊架构宣传页上的话术只聊一个最实际的问题在MPP场景下线程到底怎么设才能让查询又快又稳、又不把节点资源耗干。这篇文章适合三类人正在给金仓MPP集群做初始化配置的DBA遇到过“并行一开查询反而变慢”的业务开发以及准备做性能压测但不知道从哪下手的技术负责人。我会把参数关系、配置思路、实测案例和踩坑记录一次讲清楚你照着调就行。1. 先搞懂MPP在Kingbase里到底是什么形态1.1 别再把“MPP集群”和“并行查询”混为一谈很多人一上来就改并行参数结果发现集群没提速原因就是没分清楚两个层次。MPP全称Massively Parallel Processing大规模并行处理指的是由多个独立节点组成一个集群每个节点有自己的CPU、内存、存储数据分散在各节点上查询时所有节点同时开工由协调节点汇总结果。这是Shared Nothing架构跟“把一块磁盘共享给多台机器”的Shared Disk是两条路。而在单个节点内部Kingbase还有一个并行查询机制也就是把一个节点的数据扫描或计算任务拆给多个并行worker进程利用多核CPU同时执行。这个机制你把它理解成“单机内并行”就好。关键点来了在MPP集群里这两层是叠加的。数据节点的查询计划先把任务分发到各个节点各节点在本地还要再决定是否启动并行worker。所以在MPP里调线程不只是调“一个查询用几个worker”还要同时考虑“节点间并行度”和“节点内并行度”的乘积会不会把资源打爆。很多刚接触的人只盯着max_parallel_workers_per_gather改到16甚至32结果一个查询就把节点CPU全部占满其他查询全部排队这就是把两层混为一谈的典型表现。先把这个概念理顺后面调参才不会跑偏。1.2 金仓MPP集群里的两类角色线程设置重点完全不同在Kingbase的MPP部署里节点大致分两类角色协调节点有的文档叫Coordinator和数据节点Segment。协调节点不存业务数据或者说业务数据主要落在数据节点上它的职责是接收应用发来的SQL生成分布式执行计划把子任务分发给各数据节点最后汇总结果返回给应用。数据节点则真正存储数据负责执行下发的子任务。这两类角色的线程设置思路完全不同。协调节点因为要接收大量并发会话、做计划、汇总结果对连接处理上限和worker调度能力要求高但不需要给它配很高的本地并行度否则它自己先把CPU打满反而成为瓶颈。数据节点才是真正干重活的地方并行worker要优先保证数据节点有充足的配额。我见过不少部署方案把协调节点和数据节点配置成完全一样这不算错但在高并发场景下协调节点往往先出现瓶颈。后面我会给出一套分开配置的建议核心思路就是协调节点重连接、轻并行数据节点轻连接、重并行。尤其当应用直连协调节点时协调节点的连接参数会直接决定你能接入多少并发请求这个坑比想象中隐蔽。1.3 线程设置的本质用空闲CPU换查询时间讲参数之前先把这个问题的本质想明白。数据库线程设置不是什么高端算法本质就是一句话在业务低峰或CPU有空余的时候让一次查询能动用更多CPU资源把原本串行的扫描、排序、聚合拆成多份同时做缩短单条查询的时间。代价也很明显更多的worker意味着更多的内存占用每个worker都有独立的work_mem、更频繁的上下文切换、更激烈的I/O争抢。所以线程设置并不是越大越好而是要在“单查询延时”和“系统整体吞吐”之间找平衡点。这也是为什么后面所有建议都强调“拿真实SQL做压测”因为不同业务的查询形态差别太大了。有些系统是低并发大查询可以把单查询并行度拉满有些系统是高并发小查询并行开得过大反而害了自己。有了这个认知下面看参数就清楚了每一个参数都是在控制“资源换时间”的杠杆向哪边倾斜。2. 线程相关参数全景从连接线程到并行worker2.1 第一条线连接线程每个会话都有开销先看连接层面的参数。Kingbase内核和PostgreSQL一脉相承一个客户端连接通常对应一个后端进程这个进程要占内存、要参与调度所以max_connections决定了系统最多能同时接入多少会话。在MPP集群里还有个容易忽略的点应用连的是协调节点但协调节点在执行分布式任务时还要向数据节点发起内部连接。也就是说协调节点上的一个用户会话可能在每个数据节点上都对应着内部会话。如果max_connections只按“应用并发数”来设没算上数据节点上由协调节点转发的内部连接就很容易在业务高峰触发too many connections错误。实际建议是数据节点的max_connections要给协调节点预留足够余量。比如协调节点允许200个并发应用会话有20个数据节点那每个数据节点至少要有200个内部连接额度再叠加本节点上其他管理维护连接就要把max_connections设到220到250左右。这不是线程参数但它是线程设置的前置条件连接数不够并行worker再充足也进不来。之前在压测时就吃过这个亏应用并发一上去集群直接报连接数超限查了半天才发现是数据节点内部连接额度没预留够。2.2 第二条线并行worker真正的“干活线程”Kingbase的并行执行模型里有几个核心GUC参数必须搞懂我按调度顺序讲max_worker_processes整个数据库实例允许启动的后台工作进程总数。它不只是给并行查询用的还有运维任务、日志、复制等都从这里面取名额。这个参数必须重启才能生效。max_parallel_workers实例级别的并行worker总配额。在max_worker_processes名额里再划出“用于并行查询”的部分超过这个数新来的并行查询就得排队。max_parallel_workers_per_gather单个查询里一个Gather节点最多能启动多少个并行worker。也就是说单条SQL在同一时刻能用的最大并行worker数实际是受它控制的。max_parallel_maintenance_workers维护类操作比如CREATE INDEX、VACUUM可用的并行worker数和查询并行相互独立但同样要从max_worker_processes总池子里面扣名额。min_parallel_table_scan_size / min_parallel_index_scan_size触发并行扫描的阈值。表太小优化器认为没启动并行的必要就不会走并行计划。parallel_setup_cost / parallel_tuple_cost优化器估算并行启动代价和tuple传递代价的参数。设得越大优化器越倾向保守不愿走并行。这里有个必须记牢的约束关系max_worker_processes max_parallel_workers max_parallel_workers_per_gather。如果max_parallel_workers设得比max_parallel_workers_per_gather小那单查询即使想申请更多worker也申请不到如果max_worker_processes都不够大那并行worker和后台任务会抢名额。这三层关系就像公司的编制max_worker_processes是公司总HCmax_parallel_workers是其中分给“并行计算团队”的名额max_parallel_workers_per_gather是单个项目最多能分配的人。团队总名额不够项目想多要人也不行。还有一个容易被忽略的参数是work_mem。每个并行worker在进行排序、哈希连接、聚合时都有自己的work_mem配额所以并行度翻倍这部分内存消耗也翻倍。很多“并行一开就OOM”的问题根源不在并行worker数量而在work_mem按并发数成倍放大。比如全局work_mem设64MB一条SQL启动8个worker光排序就可能吃512MB并发几条SQL内存很快就没了。2.3 参数的生效层级改了没效果先看你改在哪一层Kingbase的参数生效方式遵循PostgreSQL系的层级体系配置文件和ALTER SYSTEM是实例级ALTER DATABASE是库级ALTER USER是用户级SET是会话级还有表级的存储参数比如表的parallel_workers。实际调优中我的优先级经验是需要大多数人统一的设置比如总worker数放配置文件或ALTER SYSTEM只针对某个业务库或某个报表账号的设置放到数据库级或用户级临时排查问题用SET不落地热点大表用ALTER TABLE SET (parallel_workersN)单独指定这样其他小表不受影响。很多“参数改了没效果”的案例最后发现是改在了session级连接一断开设置就没了。或者ALTER SYSTEM改完之后没有reload或重启系统还跑着旧值。判断方法很简单执行SHOW命令查看当前生效值再对比你预期的值即可。注意形如max_worker_processes、max_parallel_workers这种POSTMASTER级别的参数ALTER SYSTEM改了也必须重启数据库实例才会生效SHOW一下看看就知道是不是没重启。这一章的问题要是没理清后面调的参数基本都是白调。3. MPP线程设置的实操方法与建议值3.1 第一步摸清底数别上来就改参数我调MPP线程前会先列一张“底数清单”每节点CPU核数要区分物理核和逻辑核Linux下lscpu看、内存总量、存储类型SSD还是机械盘、磁盘数量、业务并发峰值、典型SQL的量和复杂度。这些信息决定后面所有参数。比如机械盘环境下并行worker太多会让磁头在多个文件间来回颠簸I/O反而变慢这时候并行度要保守SSD或NVMe环境下I/O争抢小并行度可以激进一些。另外还要确认MPP集群里各节点配置是否一致。如果各节点CPU、内存不一样那么并行调度会受最慢节点拖累集群整体体验就是“总是有个节点掉队”。生产环境最好同构如果已经异构了参数要以最差节点为准来定否则慢节点一定会成为瓶颈。3.2 第二步先定单节点并行度从“核数减2”开始给数据节点定并行度我推荐一个逐步收敛的方法。初始值这样设max_worker_processes CPU核数 系统预留后台进程数通常再加4到8max_parallel_workers CPU核数的一半到三分之二max_parallel_workers_per_gather min(4, max_parallel_workers / 期望并发大查询数)举例16核数据节点如果期望高峰时期最多2个大查询同时跑先设max_worker_processes20max_parallel_workers8max_parallel_workers_per_gather4。这样单个查询最多4个worker并行2个大查询合计最多8个worker加上其他后台任务大概12到14个线程在忙留了2到4个核给系统、网络和操作系统调度比较稳妥。如果只是单查询性能优先且并发很少可以把per_gather调到CPU核数减2比如16核设14但这是很极端的场景。实际业务中一个小查询启动14个worker反而会大幅拉长调度时间得不偿失。普通分析型负载下per_gather在2到8之间更常见。我通常建议从一个偏保守的值起步观察CPU利用率和查询耗时后再逐步往上加一次只加一个档位。3.3 第三步协调节点和数据节点分开配MPP集群里同一套参数不建议直接复制到所有节点。下面是一套我常用的“分离配置”思路协调节点max_connections按应用并发数加管理预留设高一些max_parallel_workers_per_gather设小一点比如2因为它主要做计划、分发、汇总本地数据少并行度给高了也用不上反而抢占CPU。数据节点max_connections要算上协调节点转发的内部连接max_parallel_workers和per_gather按前面“核数减2”思路来设是真正的并发主力。在并发模型上还要想清楚一个问题协调节点是按连接并发做调度的数据节点是按查询任务做调度的。大量应用连接同时压到协调节点时如果协调节点CPU被打满即使数据节点有富余整个查询入口也进不来。所以协调节点的CPU预留比并行度更重要。实际部署时我还会给协调节点单独留一两个CPU给管理工具和监控agent避免它们和数据库抢资源。3.4 第四步用EXPLAIN验证设置有没有真生效改完参数第一时间看执行计划。在Kingbase里执行EXPLAIN如果是并行计划通常能看到Gather或Gather Merge节点下面会标注Workers Planned: N和Workers Launched: N。前者是优化器打算用的worker数后者是实际启动的worker数。Workers Launched小于Workers Planned说明运行时worker名额不足或资源受限。示例SQLEXPLAIN (ANALYZE, BUFFERS) SELECT c_custkey, count(*) FROM orders GROUP BY c_custkey;如果执行计划里看到类似下面的片段说明并行确实生效了Gather Workers Planned: 4 Workers Launched: 4 - Partial HashAggregate - Parallel Seq Scan on orders如果看不到Gather节点就要回溯检查前面那些阈值参数。调试时我有两个常用技巧临时把parallel_setup_cost和parallel_tuple_cost都调成0把min_parallel_table_scan_size也调成0强制优化器考虑并行计划用来确认“表能不能走并行、worker能到多少”。确认之后再把参数恢复。第二个技巧是对热点大表直接执行ALTER TABLE SET (parallel_workers4)如果表上的统计信息不够可靠ALTER就是最直接的干预手段。注意force_parallel_mode这类测试性参数不要在生产环境开它会把本不该并行的小查询也强制并行副作用很大只适合在测试库里做机制验证。4. 典型配置案例8节点MPP集群调优实录4.1 环境与初始配置某业务的分析型系统8个节点组成MPP集群1个协调节点加7个数据节点。每节点16核CPU64GB内存SSD存储。业务以定时跑批为主高峰期同时跑20个左右的报表SQL单SQL扫描的数据量普遍在几千万行到几亿行。初始配置是安装后的默认参数max_parallel_workers_per_gather2max_parallel_workers8max_worker_processes8work_mem4MB。结果跑批任务经常出现两条慢SQL把整个集群拖慢总耗时要四十多分钟部分SQL执行计划里根本看不到Gather都在单节点串行执行。团队成员一开始以为是MPP没生效后来排查发现就是并行worker配额太小优化器算来算去都觉得并行不划算。4.2 两轮调整过程与对比第一轮调整把参数水平整体提上去。max_worker_processes从8调到20max_parallel_workers保持8因为一开始不敢一下放开max_parallel_workers_per_gather从2调到4max_parallel_maintenance_workers从2调到4work_mem从4MB调到16MB只针对报表会话因为全局涨会把内存顶爆。重启后重跑跑批效果是有的原来几乎全串行的计划开始出现Gather节点多张大表查询能用到4个并行worker。整体耗时从四十多分钟降到三十分钟左右。但问题也来了高峰时CPU经常冲到100%出现几个查询相互抢worker执行计划里Workers Launched只有2或3说明总配额不够。这时就体现出max_parallel_workers8的限制per_gather设到4最多只能同时支撑2个查询各自用满4个worker第三个查询就只能饿肚子。第二轮调整把总盘子扩大并按表干预。max_parallel_workers从8调到16max_parallel_workers_per_gather保持4给几个高达几亿行的核心大表显式指定parallel_workers8避免优化器按默认估算给不够worker给报表专用账号设置会话级work_mem32MB避免全库内存爆炸。这次跑批耗时进一步降到十八分钟左右。CPU峰值还是在95%左右但worker排队现象明显减少。原因是max_parallel_workers扩到16后4个大查询同时启动时每个都能稳定拿到4个worker核心大表强制8个worker后单表扫描和聚合阶段明显缩短。整体结果是我们在这个系统上最后定的组合一直稳定运行到现在。4.3 为什么这组配置能起效果事后复盘这组配置起作用的关键点有三个。一是把max_worker_processes和max_parallel_workers一起拉大让并行worker在整个实例层面有足够的“编制”否则per_gather设得再大总配额不够也没用。二是对核心大表用表级parallel_workers做强制指定绕开了优化器基于采样统计做估算的不确定性。三是work_mem分账号设置没有无脑调全局所以并行度提高后内存没有被引爆。这个案例也再次说明MPP调线程不能只调某一个参数。per_gather是单个查询的“手臂”max_parallel_workers是实例的“总预算”max_worker_processes是整台机器的“编制”三个得一起调还要配合work_mem等内存参数才能让并行真正跑起来又不出故障。配置改完后一定要留好变更记录我习惯把每次调整的参数和压测结果写在一个文档里后面复盘效率高很多。5. 常见问题与排查技巧实录5.1 改了参数执行计划还是串行这是问得最多的问题。可能原因有表太小没超过min_parallel_table_scan_size阈值parallel_setup_cost和parallel_tuple_cost偏高优化器认为启动并行不划算表上的统计信息太旧优化器不知道表已经变大或者并行相关总配额已经被其他查询占满。排查思路先看表大小和统计信息执行ANALYZE更新统计再用EXPLAIN看计划临时把触发阈值调低测试。前面说过把min_parallel_table_scan_size和parallel_setup_cost临时调0是很有效的诊断手段。如果调0之后还是串行那多半不是阈值问题而是SQL结构本身不适合并行比如存在强依赖的前后关联子查询优化器无法安全拆分。这种情况别硬调参数先把SQL改写思路放上去。5.2 并行一开CPU满但查询更慢症状是执行计划里明明有GatherCPU也飙到100%但查询耗时反而比串行还长。这种我见过不少常见原因有这么几类work_mem太小导致每个worker都写临时文件I/O能力跟不上并行worker都在抢磁盘查询本身太短启动worker的调度开销比并行收益还大或者MPP下数据分布不均某个节点数据多其他节点做完干等。排查技巧是分阶段测量。先用一个单表count或全表聚合的简单查询压并行看纯粹扫描能力是否提升再换成真实复杂SQL对比是否多个worker都在做重活最后看数据分布比如按where条件分组的字段如果某些值占比过高并行任务必然倾斜。遇到短查询并行反而变慢的情况可以直接把它的表级parallel_workers设为0让这个查询老实走串行比纠结全局参数更划算。5.3 MPP集群中某个节点总是掉队集群所有节点配置一样但每次跑批某个数据节点用时长一大截整体被它拖慢。这种“掉队”问题通常不是线程设置导致的但会被错误的线程设置放大。先查数据分布是否均匀比如检查一张大表在各节点上的行数如果某节点数据多出一倍就要考虑重新分布或调整分布键。再看该节点是否还有别的业务比如备份、统计任务都在同一个时间段跑CPU本身就有压力。线程层面的缓解办法是掉队节点的并行度适当调低避免它同时承担过重的并行任务协调节点的任务调度尽量保持均匀避免总是把最重的任务发给同一个数据节点。根本上还是要把数据分布和统计信息维护好每次大批量数据变更后及时ANALYZE。数据倾斜不解决线程参数调得再精细集群也快不起来。5.4 踩坑速查表症状可能原因优先处理建议执行计划没有Gather表太小、阈值太高、统计过旧ANALYZE后临时调低阈值测试Workers Launched小于Plannedmax_parallel_workers总配额不足扩大总配额降低per_gather并行后反而变慢work_mem不足、I/O瓶颈、查询太短调大会话级work_mem确认存储能力CPU打满但吞吐上不去并行度过于激进减小per_gather错峰执行大查询某节点耗时突出数据倾斜、节点负载不均检查分布键均衡数据错开维护任务修改参数不生效层级不对、未重启SHOW查看当前值区分动态和重启参数这个表基本覆盖了我这些年遇到的大部分线程设置问题。真遇到没把握的情况经验是少动参数先看数据和计划再决定要不要调。参数都是手段不是目的最终要为业务查询服务。最后分享一个我比较坚持的做法每次调完线程参数不要只看一两条SQL就下结论。MPP的并行效果是一个系统行为至少要拿一套覆盖你业务典型查询的脚本在同样数据量和同样并发下跑前跑后对比才算数。我在生产环境就是这么干的把每个版本的参数组合都留记录哪天出问题也能快速回退。线程设置这件事没有一成不变的银弹只有对自己的数据和SQL摸得越透参数才能调得越准。
