ASP.NET Core 6 Web API部署OpenShift后内存未释放求助

• .NET 垃圾回收（GC）的默认行为
  .NET 的 GC 不会在请求停止后立刻把所有闲置内存还给操作系统，尤其是容器环境下，默认配置会倾向保留已分配内存，避免后续请求的重复分配开销。可以通过调整 GC 参数优化：

  • 在容器环境变量中设置 DOTNET_GC_SERVER=false：你的 CPU 限制是 300m（接近单核心），服务器 GC 更适配多核心场景，切换到工作站 GC 会让内存回收更积极
  • 在 .csproj 中添加 <ServerGarbageCollection>false</ServerGarbageCollection>，强制禁用服务器 GC
  • 设置 DOTNET_GC_HEAPCOUNT=1，减少单核心场景下的堆碎片问题

• 容器内存限制的影响
  OpenShift 的内存限制会影响 .NET GC 的触发逻辑，如果 512Mi 的限制刚好卡在临界值，GC 可能因为没有足够的内存压力而不主动释放内存：

  • 临时调高内存限制到 768Mi，观察负载测试后内存是否回落，以此判断是否是 GC 触发条件的问题
  • 确认容器中已设置 DOTNET_RUNNING_IN_CONTAINER=true（OpenShift 默认会自动设置，但可以手动验证），确保 .NET 运行时正确识别容器资源限制

• 排查潜在内存泄漏
  即使是类似 WeatherForeCast 的基础 API，也可能存在微小泄漏点：

  • 使用 dotnet-dump 工具捕获负载前后的内存转储，分析对象引用链：

    dotnet-dump collect -p <进程ID>
    dotnet-dump analyze <dump文件路径>
    

  • 检查是否有静态对象持有请求相关实例，比如未正确释放的静态缓存、意外留存的请求上下文引用
  • 确认没有未处理的异常堆积，异常对象也可能占用内存未被回收

• 区分 Pod 与 .NET 内存统计差异
  OpenShift 统计的是 Pod 的 RSS（常驻内存集），而 .NET GC 释放的内存可能暂时留在进程虚拟内存中，未被操作系统回收。可以在 Pod 内执行以下命令对比：

  # 查看 .NET 运行时实际堆内存大小
  dotnet-counters monitor --process-id <进程ID> --counters System.Runtime
  # 查看 Pod 内进程的 RSS 占用
  ps aux | grep <进程名>
  

如果 .NET 侧的 GC Heap Size 已经下降，但 Pod 的 RSS 未降低，这属于操作系统正常的内存管理行为，后续有内存需求时会自动回收。

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