这一年在 V 站关于这个问题已经发了好几个贴了，一直没解决 /t/1037900已经从 ASP.NET Core 5 升级到 6 了，之前升过 8 内存泄露更严重了，又退回 6最早加每 5 分钟强制 GC 一次，缓解了几个月，又开始两天一崩然后搞了双实例负载均衡，两台机器 4 小时重启一次，重启时间错开，缓解了几个月最近请求量翻了两倍，然后变成了一小时一崩，这么频繁重启再接下去肯定会出现重启也解决不了问题的情况，只好再来求助目前请求量是每天 6~9 千万（客户端大量轮询请求，随硬件分发无法更新，导致请求量比较大）按照 learn.microsoft.com/zh-cn/dotnet/core/diagnostics/debug-memory-leak 的教程，运行 10 分钟后抓取 dump 的 heap statistics 如下 pastebin.com/BnxB8S0R另外 analyze 的时候所有命令都提示 ERROR: The GC heap is not in a valid state for traversal. (Use -ignoreGCState to override.) 加上 -ignoreGCState 又不返回内容，不知道为什么，stackoverflow 上的几个方法都无效

www.cnblogs.com/huangxincheng请出一线码农啊

给个建议，不知道适不适合 op ，如果你能在本机调试复现的话，用 JB 的 dotMemory (其它的当然也行) 跑一下，每隔 10 分钟拍一个快照，对比快照能知道是哪里的内存没被释放。如果是在服务器上的话，那我就没试过了。

大于 0.5MB 的对象加起来才 900M ，总共占用 7G 多，应该是大量小对象占用的

我也想到了这个人，但没想起名字，github 和博客园都私信找他看看吧，他的博文都是处理这种的

这个统计总和才 900 多 MB ，得把小于 0.5M 的，也就是所有的对象的统计输出都发出来才行

试过 dumpobject 吗，堆上小对象是什么内容？有 full dump 会好查点。

最好是可以在本地调试状态复现，使用 vs 的快照分析，可以具体查看对象大小以及依赖关系，可以很快速找到根源

查是肯定能查出来的，用 debugdiag 连续抓几个 dump 对着看，才能找出是哪些对象在增加内存，如果还不好定位问题还有 Time Travel Debugging

你只给了一个站 10 分钟后抓取的 dump ，Total 12,315,255 objects, 7,342,657,549 bytes 你是不是等 10 分钟后再抓一个 dump ，看看总量变化是多少，占用内容变化是多少，这个 dump 应该是堆的内容，只能知道内存中的变量有没有变化，空间占了多少。你还需要 dump 一个栈的内容，看看当前执行的方法情况，才能定位到具体代码可能在哪里发生泄漏

如果可以的话建议把 dotnet-dump collect 生成的 dump 文件发给会分析的人去看（里面可能包含你们业务的数据因此要谨慎）。

奔溃日记和调用栈信息都没有，错误描述都没有，也没有帮你猜错误吧。。。。

我们有个产品从 7 升到 8 内存泄漏严重.…我们研究了俩月 无果 ，最后在 azure 上把内存拉高了……

没对比，没法看。盲猜问题出在 Core.Models.Order 涉及 UserPricePolicy 逻辑相关。有可能是外包水平的码农写逻辑时无脑查几乎所有数据

很简单，用 Rust 重写

贴的 Text 里好像有很多 EntityQueryable 查询和 ChangeTracker 追踪检测更改的，不知道是不是因为在查询时一直追踪导致的问题……菜鸡默默围观…… blog.csdn.net/ousetuhou/article/details/135218175 blog.csdn.net/dongnihao/article/details/126475145 learn.microsoft.com/zh-cn/ef/core/change-tracking/change-detection

我看了下原帖> 查了很多文档 gcdump 都是不会去触发 GC 的我不知道你查的什么文档但是官方文档是明确有说> To walk the GC heap, this command triggers a generation 2 (full) garbage collection然后> 如果运行 dotnet-gcdump 则能立即恢复正常水平gc 能回收，说明不是泄露有极大概率是你分配的大对象太多了，大对象在 LOH 里不会被优先回收解决方案：1. 好好优化下自己的代码，减少巨大对象，会频繁创建的大对象不要 new ，用 ObjectPool2. 调整 GCLOHThreshold ，让大对象别进 LOH

＃14 什么语言都避免不了泄露吧。

PHP 这种可以吧

这哥们看着确实不错，有点水平

• 一些配置信息用 redis 做一下缓存，比如 Models.Setting ，Models.WxReplyRule 等，不要每次都从数据库查- 我怀疑程序大量使用了 static 变量缓存数据，还是某些表的全量数据- Models.Order 存在 select all 到内存中情况 ，WxReplyRule 疑似也存在这个情况- 随机数生成算法再优化一下

建议检查 引用的第三方包；再检查类似 闭包 的方法使用导致 内存逃逸