识别 ASP.NET 应用程序中的内存问题
我正在运行一个 ASP.NET 应用程序，在生产环境中它使用了大约 450MB RAM，但是，它不应该使用那么多，而且它似乎会随着时间的推移而增加，因此似乎可能存在泄漏或至少有些东西没有被正确发布。
我用 PerfMon 看了一下，GC Gen2 有 416MB。
有人知道它在内存中保存了什么吗？ 我可以抓住 dotTrace/ANTS 并以某种方式将其附加到我的 IIS（6 - 在 Windows Server 2003 上） - 还是有更好的方法？ ：-）
谢谢。
I've got an ASP.NET application running and on the production box it's using about 450MB RAM, however, it shouldn't be using quite so much, and it seems to increase over time, so it seems there might be a leak or atleast something not being released properly.
I took a look with PerfMon and there was 416MB in GC Gen2.
Anyone have any idea for finding out what it's keeping in memory? Could I just grab dotTrace/ANTS and somehow attach it to my IIS (6 - on windows server 2003) - or is there a better way? :-)
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在循环中更新一堆字符串的经典问题可能会导致您看到的问题，因为大量内存被分配给新字符串而不释放它们。 您是否在适当的情况下使用 StringBuilder？
The classic problem of newing up a bunch of strings in a loop could cause the issue you're seeing due to large amounts of memory being allocated for new strings without releasing them. Are you using StringBuilder where appropriate?
观看 Tess 的这个 TecheEd 演示将是一个好的开始。
她演示了如何使用 adplus 获取消耗大量 RAM 的 ASP.NET 应用程序的转储，然后将该转储加载到 WinDbg 中进行分析。 在 WinDbg 中使用 !gcroot 命令查找意外的根并从那里开始。 她建议不要存储包含对缓存或会话中其他对象的引用的复杂类型。
Watching this TecheEd presentation by Tess would be a good start.
She demonstrates using adplus to take a dump of an ASP.NET application that is consuming a great deal of RAM, then loading that dump into WinDbg for analysis. Use the !gcroot command in WinDbg to find unexpected roots and go from there. She advises against storing complex types that contain references to other objects in cache or session.
虽然这是一个关于您可能没有使用的技术的特定博客，但它确实涵盖了如何诊断内存问题 - http://blogs.msdn.com/tess/archive/2008/09/12/asp-net- memory-issues-high-memory-usage-with-ajaxpro.aspx
深入研究 Tess 的工作，她有很多调试/诊断帖子，我相信您可以找到更多对您有用的内容。
Although this is a specific blog about a technology you're probably not using it does cover how to diagnose memory issues - http://blogs.msdn.com/tess/archive/2008/09/12/asp-net-memory-issues-high-memory-usage-with-ajaxpro.aspx
Dig through Tess's work, she's got a lot of debugging/ diagnosis posts and I'm sure you can find more which are of use to you.
您是否正确地在各处取消了事件处理程序？ 有人告诉我，如果你不让他们脱离活动，他们可能会无所事事。 他们可能会对较大对象的引用保留的时间超过必要的时间。
Are you properly unwiring event handlers everywhere? I'm told that they might be sitting around if you never detach them from the event. They might be keeping references to larger objects longer than necessary.
您是否正确处理实现 IDisposable 的类的对象？ 这将包括 SqlConnections、SqlCommand、SqlDataAdapter、DirectoryEntry 等。您是否有任何使用未实现 IDisposable（和/或未释放）的非托管内存的对象？
Are you properly disposing of objects of classes that implement IDisposable? This would include SqlConnections, SqlCommand, SqlDataAdapter, DirectoryEntry, etc. Do you have any objects that use unmanaged memory that don't implement IDisposable (and/or aren't getting disposed)?
我很确定您现在已经完成了所有操作，但我在我维护的网站上遇到了类似的问题。
该网站在服务器上使用了大约一千兆内存，并且进行了大量检查和清理，我们必须摆脱大量会话调用，因为它们没有被正确处理。
而且事实证明，在我网站的一个网站上，我拥有的并发用户数量，对演出的粗略估计正是它所需要的。
事实证明，在页面上加载大量用户控件会给服务器内存带来一些压力，不确定为什么，但它确实帮助我们通过删除用户控件并将它们分成更小的页面来查明一些问题。
最后但并非最不重要的一点是检查您正在使用什么类型的会话提供程序，如果 inproc 给您的服务器带来太大的压力，也许是时候更改为 asp.net 状态会话服务或使用 sql 服务器作为您的会话提供程序。
让我知道您的想法以及您是否发现和具体情况。
I am pretty sure that you have been through all the motions already by now, but i had a similar problem on a site i maintain.
The site was using roughly a gig of memory on the server , and much check and cleaning , we had to get rid of a lot of session calls as they were not being disposed of correctly.
Also it turns out that on a site of my site with the amount of concurrent users that i had , the rough estimation of a gig was just what it needed.
It also turns out that loading a lot of user controls on a page puts a bit of strain on server memory , not sure why but it did help us pinpoint some issues by removing the user controls and making them into smaller pages.
Last but not least check what type of session provider you are using , if inproc is putting too much strain on you server maybe its time to change to the the asp.net state session service or using a sql server as your session provider.
Let me know what you think and if you found and specifics.