公司向某宝推送数据的服务, 由于限频, 量大, 已经抗不住了.
队列拉取速度跟不上生产速度,本地堆积; 某宝每秒限频, 又造成推送堆积.
领导让我看的时候, 本来我是拒绝的, 我一向抗拒修改别人的代码, 特别是已经上了生产的代码. 保不准按了葫芦起了瓢, 把生产搞崩溃了.
但是这个服务已经严重拉低了我们服务质量. 做为草头架构师, 本着普渡众生于水火之中的高尚奉献情操, 我把这个服务给重构了.
速度跟不上, 很容易操作,同步改异步, 加大并发, 减少耗时而已.
限频也不是问题, 前段时间熬夜写那个 AsNum.Throttle 就是为了解决这个问题而生的, 虽然还在修修改改, 但是基本上是可以解决了.
昨天在解决了一堆问题之后, 下班前, 把我认为没毛病, 铁定666的重构版本发布上去, 结果没有抵抗住 次高峰, 运行了一个多小时,内存直接飘到了4G, 然后OOM了. 昨晚搞到1点多, 也没有找到个所以然, 该释放的, 都用 using 了, 实在找不到问题, 只好发了个 64位的, 让它慢慢吃内存吧,年纪大了, 熬不得夜,幸好服务器牛A的不得了.
为了减少数据库的操作, 我把结果放到MemoryCache里去了, 全部数据应该有大几十万吧. 但是即使把这几十万全都放到 MemoryCache 里, 也不至于占用这么多内存啊 ??
今天用 Memory Profiler 分析了一下, 发现第二代垃圾居然高达2G多(没拍照留念), 那个EF的代理类, EntityKey,还有什么RelationShipManager , 一大堆...
莫名其妙清理不掉的第二代垃圾
看了一下代码, 在查询那里, 发现了 Include, 但是Include 的数据根本没有使用到.
这种为了架构而架构的代码, 真蛋疼.
重写了查询 , 内存还是没有改观, 运行了不到十分钟, 第二代垃圾就达到了400M.
第二代垃圾
去掉了Include, 好像那个 ReleatonShipManager 少了许多, 但是代理类还是一大堆, 那好, 禁用代理类, 反正这里只是读取, 不涉及到修改:
...
using (var db = new DAL.DBContext())
{
db.Configuration.ProxyCreationEnabled = false;
...
改完之后, 效果立杆见影:
该死的代理类,终于滚蛋了
垃圾终于收走了
现在已经安全的走过了N个高峰, 内存固定在 1.2个G以内.
总结:
使用 EF , 如果不涉及到修改, 最好把ProxyCreationEnabled 关掉
网友评论