任务是处理车辆的实时上报数据，每秒峰值大概3万条，之前每隔两小时就莫名OOM。团队几个人轮着查，上来就盯着CPU使用率调，把并行度从8拉到16，CPU从20%升到了60%，该崩还是崩。
我当时就笑了。
你以为的瓶颈，可能根本不是瓶颈
很多人做实时计算任务的资源调优，第一步就踩坑——把CPU使用率当成唯一的衡量标准。说白了，CPU只是众多资源维度里的一个。流式任务的链路是串起来的，从源端读数据，到shuffle，到状态访问，到sink写出去，任何一个环节堵了，都会表现为任务变慢、反压、OOM，反压的根源往往不在CPU，而在网络带宽、堆外内存或者状态后端的IO，跟CPU高低半毛钱关系没有。
之前碰到过一个处理用户行为日志的任务，给了8个TaskManager，每个4核8G，CPU常年趴在20%以下。团队觉得资源给多了，直接砍到4个TM，结果当天就出问题——源端的Kafka消费延迟直接拉到3小时，数据堆得快溢出来。
后来翻监控才发现，根本不是CPU的事。状态后端用的RocksDB，挂的是普通云盘，随机写延迟飙到20ms以上，磁盘IO直接打满。CPU闲得发慌，数据根本写不进状态里，可不就堵了。
你看，之前一周的调参，全是无用功。
调优不是拍脑袋，是算清楚每一分资源的去向
很多人觉得调优就是对着网上的参数表抄，TM配多少核，堆内留多少，堆外留多少。大错特错。
实时任务的资源消耗，跟你的业务逻辑强绑定。你要是处理的每条数据只有几百字节的日志，跟处理几MB的图片特征，资源占用能差出十倍去。
首先要把每一层的资源占用拆解开，别把所有内存揉成一锅粥。
堆内内存是给JVM跑业务逻辑用的，要是你写的算子里有大量临时对象，堆内给少了就会频繁Full GC，任务卡得像PPT。堆外内存是给网络缓冲区、RocksDB缓存用的，跟JVM没关系，很多人配TM内存的时候全给了堆内，堆外只留默认的几百MB，状态访问慢、网络阻塞全来了。
还有网络缓冲区的大小，默认的1024个缓冲区，是给单条几KB的数据设计的。要是你的任务处理的是带大字段的日志，单条就有几十KB，那缓冲区根本不够用，数据攒半天发不出去，shuffle阶段直接堵死。
我见过最离谱的配置，是有人为了不让网络堵，把缓冲区调到了8192个，结果整个集群一半的内存都被缓冲区占了，业务逻辑的内存反而不够，每隔两小时就Full GC一次，卡顿了半个月才找到原因。
没有通用的调优公式，只有适合你业务的取舍
调优本质上是取舍。你要什么，就得牺牲什么。
要是你的任务是做实时风控，要求延迟必须在100ms以内，那你就得接受资源利用率低的事实。每个处理节点多留30%的冗余内存和CPU，哪怕平时只用到一半也没关系——总比流量峰值来了直接OOM，把风控挂掉，造成资损强。
要是你的任务是做实时数仓的T+0指标聚合，只要延迟在分钟级以内就行，那你就可以把并行度压到刚好不反压的程度，把CPU利用率拉到70%以上，省下来的资源分给别的任务用，没必要为了那点冗余浪费集群资源。
当然，这里有个度。你要是为了省资源，把内存卡得死死的，连10%的冗余都不留，那一旦上游流量突然涨个20%，直接OOM，任务恢复就要十几分钟，这损失比省那点资源贵多了。
别太迷信自动调优的功能。现在很多实时引擎自带的自动扩缩容，阈值都是基于CPU和内存的，根本感知不到磁盘IO、网络带宽的瓶颈。上次有个朋友用自动扩缩容，CPU一低就缩容，结果磁盘IO早就打满了，缩完容直接反压到源端，堆了一整天的日志，哭都来不及。
说实话，自动扩缩容最多当个辅助工具，真要靠它做实时计算任务的资源调优，迟早要踩坑。
上周那个撸串的朋友，后来把状态盘换成了SSD，堆外内存从1G调到了3G，并行度从16降到了12，现在CPU稳定在45%左右，延迟从之前的2s降到了300ms，再也没崩过。
他说之前熬的那三个大夜，全是盯着CPU瞎折腾。