ASP .NET Core 5 内存占用线性增加, 1 小时内 100%把 128G 内存用完,如果运行 dotnet-gcdump 则能立即恢复正常水平,查了很多文档 gcdump 都是不会去触发 GC 的,但多次尝试都成功,求排查思路
接手别人的项目,代码不熟悉,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 版本
- 需要优化 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 放在一个定时重启的微服务里去做。
也不一定要镜像,反代加速也行,我需求也不大,拉的时候国内能加速就行 感觉反代加速好一点,镜像的话硬盘吃不消 用中科大的镜像源 那还不如注册个阿里云账号,开个阿里云镜像源 …
前言 一个朋友前段时间做种的时候,偶然发现一个很奇怪的中国 ip 的对等点,从他那里下载了数百倍于文件本身大小的量,但是仍在持续发起请求。 搜索之后发现不止他遇到了这个情况,不…
公司没有本地文件服务器, 如何用 AWS 等外部服务搭建公司内部网络来共享文件,像网络文件夹一样谢谢. zerotier ,然后 FTP 。 docs.aws.amazo…