F#应用计算密集型独立任务并行性能不佳问题求助

应用基础执行逻辑 #

单组计算任务的执行流程如下：

1. 基于给定初始条件，独立完成约25万个主体的单周期向前推演
2. 聚合所有主体的计算结果，生成下一轮迭代的初始条件
3. 重复前两个步骤共约1200次
4. 执行最终全局聚合
   单组任务顺序执行的实际耗时约为9分钟。

已落地并行方案的测试表现 #

主体维度并行 #

最初采用Array.Parallel实现主体维度的并行：步骤1全量并行执行，步骤2基于map-reduce方案实现。在16核机器上，单组任务耗时约1分15秒。考虑到单次完整计算需要承担2400次并行调度开销（每次迭代的步骤1、步骤2各产生一次开销），该性能表现符合预期。

任务维度并行 #

由于应用日常需要批量运行多组独立计算任务，后续尝试通过PSeq（同步测试过Array.Parallel实现）做任务维度的并行：该方案理论并行效率更高，不同计算任务之间几乎完全独立，仅共享部分只读数据，不存在对同一对象/内存地址的写冲突，整批任务仅需承担一次并行调度开销。
但实际测试结果远低于预期：16核机器上批量运行16组计算任务耗时约35分钟，和理想状态下的9 + ε分钟（仅增加极少量调度开销）差距极大。

GC相关调优尝试 #

初步判断性能异常与GC（垃圾回收）相关，先后调整了多组GC配置：

• 绝大多数配置的优化效果可以忽略
• 效果最优的配置组合为：将GCSettings.LatencyMode设置为GCLatencyMode.Batch，同时配置环境变量COMPlus_GCRetainVM=1，但也仅将总耗时缩短了1-2分钟
• 调优全程已开启Server GC

程序运行不存在内存瓶颈：部署机器总内存为96GB，随GC配置变化，程序运行内存峰值在17GB-40GB区间浮动。

现有观测与剖析结论 #

受环境限制，无法直接在16核生产服务器上做性能剖析，仅能通过Windows性能监视器采集运行数据：

• 内存占用水平和GC配置强相关：默认配置下内存占用约30GB，Batch模式下内存占用低于20GB
• CPU整体利用率处于较高水平，维持在80%-90%区间，但Batch模式下约每30秒会出现一次CPU利用率骤降的运行中断
  在核数更少、数据集规模更小的测试机上，通过JetBrains dotTrace Timeline做剖析发现：并行配置下原生代码执行耗时是顺序执行时的10倍，其中跨线程GC等待耗时占比并不高，初步怀疑是单核并发GC触发了该现象。

目前暂无其他排查方向，欢迎提供相关优化建议。

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