接手别人的项目,代码不熟悉,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 放在一个定时重启的微服务里去做。