如何提升IO密集型S3文件迁移SpringBoot应用的CPU使用效率

结论先行 #

这类纯IO密集型应用确实天然存在CPU利用率偏低的特性，但并非只能在「性能达标」和「CPU利用率高」之间二选一，通过针对性优化完全可以在保证处理速度的前提下大幅降低CPU资源浪费。

可落地的优化配置方案 #

• 先定位当前瓶颈再调参
  首先排查当前限制并发的真实瓶颈：是Kafka消费线程数上限？是S3客户端连接池配额？是EC2节点的网卡带宽上限？还是Kubernetes Pod的网络QoS限制？大部分时候拉满线程数后CPU仍然闲置，是因为上游/下游的IO配额先触顶，线程都在阻塞等待IO响应，没有可执行的计算任务，CPU自然空转。
  可以通过Java的jstack命令dump线程栈，统计处于WAITING/TIMED_WAITING状态的IO线程占比，如果占比超过70%，说明当前线程数已经过量，再增加也不会提升性能，反而会额外占用CPU调度资源。
• 优化S3客户端的IO复用配置
  常用的S3 SDK默认多为阻塞IO模型，建议切换为异步非阻塞IO版本的S3客户端，用少量IO线程就能支撑更高的并发请求，减少线程上下文切换带来的CPU开销，同时可以合并小文件的校验、下载请求，批量调用S3接口，把原来零散的CPU计算操作聚合起来，提升CPU的有效利用率。
  另外可以开启S3客户端的连接池复用、TCP keepalive配置，减少频繁建连的CPU消耗。
• 附加轻量计算任务摊薄闲置成本
  如果调整IO配置后CPU仍然有大量闲置，可以在应用里叠加无状态的轻量计算任务，比如对迁移的文件做哈希校验、格式合规性检测、小文件合并打包、元数据预处理等，这些本来可以后续单独做的计算任务放到迁移流程里顺带执行，既不影响迁移性能，又能把闲置CPU用起来，相当于零额外成本完成附属任务。
• Kubernetes资源调度层面优化
  针对这类IO密集型 workload，可以在K8s里配置CPU Burst策略，允许Pod在短时间内突破CPU配额上限，平时给Pod分配最低的CPU配额满足基线调度需求，遇到批量建连、批量处理元数据等突发CPU消耗场景时自动借用节点空闲CPU资源，既不会浪费节点的CPU配额，又能保证应用处理速度不会因为CPU配额低而下降。

关于「性能与资源利用率不可兼得」的误区 #

只有当你的应用已经把IO资源用满，业务上只需要保持当前处理速度不需要进一步提升的前提下，CPU闲置才是正常的预期情况，不存在浪费一说——因为你没有需要CPU执行的任务，强行给CPU找活干反而会影响IO性能。
如果你的业务还可以接受更高的迁移速度，完全可以继续提升并发数，直到把EC2的网卡带宽、S3的QPS配额打满，这时候CPU利用率会随着并发数提升同步上涨，不会出现闲置。如果业务不需要更高的速度，那给应用分配刚好满足性能要求的最低CPU配额即可，剩余的CPU资源可以调度给其他计算密集型负载使用，集群层面整体的资源利用率是可以做到最优的。

内容的提问来源于stack exchange，提问作者Joe