Redis与EF Core的隐秘对话：当LOH异常增长时我们该如何抽丝剥茧

Redis与EF Core的隐秘对话：当LOH异常增长时我们该如何抽丝剥茧

1. 问题现象：一场悄无声息的内存风暴

深夜的告警短信打破了平静——某电商平台的订单服务内存占用突破16GB阈值。运维团队迅速登录服务器，发现一个诡异现象：虽然QPS稳定在200左右，但工作集内存每小时增长约300MB，且全部集中在LOH（Large Object Heap）区域。

使用dotnet-counters实时监控，我们捕捉到以下关键指标：

dotnet-counters monitor -p 14892 --counters System.Runtime

输出结果显示LOH异常：

Gen 0 Size (B)                               192
Gen 1 Size (B)                        36,742,336  
Gen 2 Size (B)                         8.8066e+09
LOH Size (B)                           3.3414e+09

更令人困惑的是，这些内存增长与订单量不成正比。通过dotnet-dump收集内存快照后，我们开始了真正的侦探工作。

2. 凶器定位：Redis序列化的隐藏代价

分析dump文件时，dumpheap -stat命令揭示了异常：

> dumpheap -stat
...
00007f8b1e3b8a10  2000000  320000000 StackExchange.Redis.RedisValue
00007f8b1e3b8f18  1000000  640000000 System.Byte[]

这些Redis相关对象占据了近1GB内存。进一