8.1 资源调优：把资源花在瓶颈上

8.1 资源调优：把资源花在瓶颈上

本节摘要：资源调优的头号误区是"慢了就整体加机器"。本节建立正确的打法：按算子重量分别设计并行度、用反压读数定位资源短板、按内存分区的口径算账。读完你应能对一个作业做出"哪类资源缺、缺在哪个算子"的诊断，并给出有依据的配置方案。

别急着加机器

作业慢了，最常听到的方案是"再上两台机器"。加机器有时有效，更多时候是把钱花在错误的抽屉里：CPU 满负荷的作业加内存没用，内存吃紧的作业加核数没用，被外部存储拖住的作业加什么都没用——瓶颈在墙外。资源调优的正确姿势是先诊断、后开方：诊断靠第 6 章的指标体系（反压读数、繁忙度、内存水位），开方才轮到参数。本节按"算并行度、算内存、验效果"三步展开。

第一步：并行度按算子分别设计

全局并行度是懒人的陷阱：一个作业里轻算子与重算子共用一个并行度，结果是轻算子的实例大量闲置、重算子的实例却挤在槽位里排队。正确的做法是按算子重量分别指定：

• Source：对齐上游分区数（Kafka 每个分区一个并行实例最理想，多了空转，少了单实例读多分区）；
• 轻转换（过滤、字段加工）：贴着链合并的需要（与上下游同并行度才能链成一个线程）；
• 重聚合与窗口：按"总吞吐 ÷ 单实例实测处理能力"算，再上浮余量；
• Sink：对齐下游写入能力（外部存储的分区数、批量上限）。

实测单实例处理能力的土办法：小并行度压测一轮，看单实例吞吐与反压临界点。数字有了，算术就开始说话——峰值每秒二十万笔、窗口聚合单实例实测每秒两万笔，聚合并行度至少十，留三成余量取十四，再对齐槽位数取十六。每个并行度都能说出出处，这是资源评审会上的基本礼仪。

# 内存分区的默认配比：先读懂再动刀
taskmanager.memory.process.size: 8g          # 进程总账
taskmanager.memory.managed.fraction: 0.4     # 托管池：RocksDB 与批排序的共享钱包
taskmanager.memory.network.fraction: 0.15    # 网络缓冲：高并行度大重分区的作业适当上调
taskmanager.memory.jvm-overhead.fraction: 0.1
​

第二步：内存按分区口径算账

TaskManager 的内存不是一锅粥，是五个贴着标签的抽屉，调优前先分清钱在哪：

执行堆（Task Heap）装用户代码的对象与序列化缓冲——堆状态后端的作业，状态也在这一格，"内存溢出"十有八九是这格被打穿。托管池（Managed）是引擎的记账本：RocksDB 的写缓冲与块缓存、批排序的溢写缓冲都从这格走（第 4 章讲过记账规则）。网络缓冲（Network）承载跨链数据交换（第 2 章的缓冲区）——高并行度、大重分区的作业这格要上调，否则反压的锅可能只是缓冲不够。元空间与框架开销基本固定，知道即可。

账的算法：单槽内存 = 进程总账扣除固定项后 ÷ 槽位数。配比调整的判断依据依然是诊断：堆内存水位常年贴顶加执行堆；RocksDB 频繁刷盘、写放大抬头（4.4 节的病根之一）加托管池；网络缓冲耗尽日志频现加网络格。

图 8-1 诊断开方对照：症状与资源处方

第三步：验证闭环

资源调整不是发完配置就结束，验证闭环三看：看反压——瓶颈算子繁忙度是否回落、闲忙分布是否收敛（收敛不了，说明短板不在资源，回头查倾斜与热点代码）；看内存——对应分区水位回到七成以下才算健康；看心跳——检查点耗时与完成率的改善是最硬的验收指标。三看有一处不过，说明诊断错了层，回到第 6 章的指标体系重新定位。这套"诊断、开方、验证"的循环跑熟了，资源调优就从玄学变成了可以复核的工程。

💡 关键直觉：资源的边际效益递减得很快——瓶颈在哪，资源只有花在那才有回报。加机器之前，先让监控告诉你瓶颈的名字；说不出瓶颈名字的扩容，都是赌博。

一份资源评审表的填法示范

把三步循环落成一张评审表，用大屏作业的实例示范填法。算子并行度栏：源取十二（对齐 Kafka 分区数）、轻转换十二（保链合并）、窗口聚合十六（峰值每秒二十万笔除以单实例实测两万笔上浮三成）、Sink 十二（对齐 OLAP 写入能力）——每个数字后面括号里写出处，这是评审表的灵魂。内存栏：进程总账 8G，托管池零点四（RocksDB 状态约两 GB 的心算依据）、网络池零点一五（两个 keyBy 重分区、下游并行度高的依据）、执行堆剩余约两 G（堆内对象与序列化缓冲）。压测验证栏：峰值两倍流量压二十分钟，反压子任务数为零、检查点耗时八秒、堆水位六成——三项实测数字入表，评审通过。余量声明栏：大促预案为副本翻倍，扩容后的资源账已重新核算并冻结版本。

这张表的填法示范了本节的完整方法论：每个数字要么有计算式、要么有实测值，两者都没有的格子不许填。资源评审从"拍数字大会"变成"对证据大会"，效率与质量同步上升——而且这张表本身就是 8.4 节门禁清单里资源部分的现成附件。

本节收尾回答一个常见疑问：什么时候可以整体调并行度"偷懒"？答案是测试环境与原型期——探索阶段用统一并行度快速跑通逻辑没问题，但转生产的评审必须回到按算子设计。偷懒可以，但要偷在看不见的地方，资源账最终一笔都少不了。

最后一问收尾：资源调优的尽头是什么？是"不再调优"。作业稳定跑满一个业务周期、大促演练全过、资源水位常年七成上下——这时最优策略是不动它，把精力投给下一个瓶颈。知道何时收手，是调优功夫里最容易被忽略的部分。

本节要点

• 调优三步循环：诊断（反压与内存水位）→ 开方（并行度与内存配比）→ 验证（三看闭环），拒绝"慢了加机器"。
• 并行度按算子分别设计：Source 对齐分区、轻算子保链合并、重算子按实测吞吐加余量、Sink 对齐下游能力。
• 内存五抽屉：执行堆、托管池、网络缓冲各有账本；配比调整必须有对应症状，不做无差别加法。
• 验收硬指标：瓶颈繁忙度回落、内存水位回到七成、检查点指标改善，三者齐备才算调优完成。

资源有了着落，状态这笔账还要细算——下一节进入状态调优：TTL、配比与增量快照的组合拳。