接手别人的项目，代码不熟悉，dotnet-trace 看了很久也没找出问题dotnet-dump 出来的数据不会看，翻文档学了很久操作 minidump 的命令，发现用 dumpheap -stat -min 850000 这条命令可以找出一个 StackExchange.Redis.RawResult[] 的 Count 和 TotalSize 很大，不知道是否有关系。由于内存 dump 里面有很多密钥之类敏感信息，脱敏几乎无法完成，不然就 gzip 压缩一下放出来求助了项目里有非常多 Subscribe 不同 Redis 频道（动态生成的名称）的操作，从不 Unsubscribe ，不知道是否有关。

我模糊印象中，StackExchange.Redis 早期版本有内存泄漏问题，升级一下试试？

如果在代码中定期调用 system.gc.collect 是否有内存下降，如果是的话，说明可能是高代的对象内存泄漏了。

dump 下来以后直接塞进 vs 看内存啊……

几分钟配置个定时重启，解决 99.99%疑难杂症😂

如果你会调试，使用 windbg 试一下

＃4 这个是昏招！

啊?

升级下 dotnet 版本 和 stack redis 版本

1. 需要优化 redis 大 key2. StackExchange.Redis bug 有点多，升级版本或换掉

运行 dotnet-gcdump 会强制进行一次完整的 gen 2 GC ，建议你考虑一下升级 .NET 和 StackExchange.Redis 的版本。.NET 5 已经终止支持了，建议直接升级到 .NET 8 观察，.NET 因为向后兼容做得很好升级就是改个版本号的事情。另外从不 Unsubscribe 也可能是原因之一。

如果不是重启会导致客户端全断开连接一分钟 还真的会用这种方案 公司快倒闭了裁了一堆人 业务能用就行

模糊印象中，之前博客园看过这个案例，和你说的 StackExchange.Redis.RawResult 多很像。并不是 StackExchange.Redis 的 bug ，而是不正确的方式接收消息导致的内存泄露问题。不过后续那个作者给 StackExchange.Redis 提了 issue ，新版本就做了兜底机制，所以我让你升级一下版本试试。

不敢升级最新版，早上升级到了 ASP.NET Core 6 ，StackExchange.Redis 2.2.88 ，还是存在这个问题。

偷个懒，加个定时线程自动回收

我就是这么做的，每 3 分钟 GC.Collect()一次，暂时是没出问题

为啥不敢升级最新？ aspnetcore 就算了，StackExchange.Redis 为啥不升

那看起来就是高代现象的问题了。

越来越像博客园那篇文章了，好像也是高代对象的问题，你可以搜一下文章试试。

之前遇到过升级 ClosedXML 还是别的什么包（想不起来）导致一个它依赖的包被升级了，然后这个包刚好砍了其它包依赖的几个对象，没有向前兼容，之后折腾降级又弄了很久。看 StackExchange.Redis 的 issue 有一些反馈升级后出现问题的，就不敢升级了

粗暴点，前面再加一层负责和客户端保持连接。读写 redis 放在一个定时重启的微服务里去做。