IIS System.OutOfMemoryException问题Web服务 [英] IIS System.OutOfMemoryException issue Web service

问题描述

我们有一个具有

System.OutOfMemoryException:引发了类型为'System.OutOfMemoryException'的异常.在System.Threading.Thread.StartInternal(IPrincipal主体，StackCrawlMark& stackMark)处System.Threading.Thread.Start()

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.     at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)     at System.Threading.Thread.Start()

我们正在刷新应用程序池，以作为临时解决方案.问题似乎每4-5小时就会发生一次. Web Service基本上从SQL Server DB的存储过程中返回数据.这是一个遗留应用程序，多年来未进行任何代码更改.多年稳定的应用程序是否可能突然出现任何内存泄漏问题?

We are refreshing app pool as a temporary fix. Issues seem re-occurs every 4-5 hours. Web Service basically returns the data from Stored Procedure from SQL server DB. It is a legacy application haven't done any code change in years. Is it possible an application stable for years have any memory leak issue all of sudden?

推荐答案

您将需要分析IIS应用程序池的内存转储以解决此问题.过去我也做过同样的事情，一旦您对这些工具感到满意也就不难了.

You're going to need to analyze the IIS application pool's memory dump to trouble shoot this. I've done the same in the past and it isn't too difficult once you get comfortable with the tools.

1. WinDbg- https://go.microsoft.com/fwlink/p/?LinkId = 536682 -确保 您只需按以下方式安装Windows调试工具组件 链接到完整的SDK
2. Windows Symbol Server- srv c:\ symbols https://msdl.microsoft.com/download/symbols .内 在"WinDbg文件"菜单中，选择符号文件路径"并添加此路径(您可以 更改c:\ symbols的位置，但请确保目录存在并且 在进行调试工作的系统中是本地的.
3. SOS WinDbg扩展名-C:\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ SOS.dll.将此DLL复制到Windows目录调试工具中

1. WinDbg - https://go.microsoft.com/fwlink/p/?LinkId=536682 - Make sure you only install the Debugging Tools for Windows component as this links to the full SDK
2. Windows Symbol Server - srvc:\symbolshttps://msdl.microsoft.com/download/symbols. Within WinDbg File menu, select Symbol File Path and add this path (you can change location of c:\symbols but do ensure the directory exists and is local to the system doing the debug work).
3. SOS WinDbg extension - C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll. Copy this DLL to the Debugging Tools for Windows Directory

一旦安装了工具，就需要获取内存转储并对其进行分析.

Once you have the tools installed, you need to get a memory dump and analyze it.

• 通过任务管理器获取应用程序的内存转储.确保使用与应用程序相同的位任务管理器，即，如果您的IIS应用程序池以64位运行，则使用任务管理器的64位实例.
• 使用适当的32/64位版本的WinDbg，然后通过WinDbg中的文件菜单打开内存转储.
• 加载内存转储后，请使用以下命令加载sos: .loadby sos clr
• 有许多有用的sos命令可用于故障排除，但是我们对内存问题感兴趣的一个就是以下命令:！dumpheap -stat .这将为您提供所有当前已加载的类型以及它们正在使用的内存量.
• 您可能还想确认这不是线程争用问题.可以帮助解决此问题的命令是:！sos.syncblk 以查看是否有任何线程被阻塞，而！runaway 以查看是否有任何线程正在运行过多的线程.时间.这两种情况都可能导致应用程序无响应，并会通过 IISRESET 进行修复或回收.

• Get a memory dump of your application via the task manager. Make sure to use the same bit task manager as your application, i.e. use a 64-bit instance of task manager if your IIS application pool is running in 64-bit.
• Use the appropriate 32/64-bit version of WinDbg and then open the memory dump via the file menu in WinDbg.
• Once the memory dump is loaded, use this command to load sos: ​.loadby sos clr
• There are a bunch of useful sos commands available for troubleshooting, but the one we're interested in for memory issues would be this one: !dumpheap -stat. This will give you all the currently loaded types and how much memory they are using.
• You will also probably want to confirm it isn't a thread contention issues. Commands that can help with that are: !sos.syncblk to see if any threads are blocked and !runaway​ to see if any threads have been running for an excessive amount of time. Both of these scenarios can cause an application to become unresponsive and would be fixed via an IISRESET or recycle.

同样，WinDbg有一些学习曲线，但是一旦克服了这个难题，快速诊断此类问题非常容易.

Again, there is a bit of a learning curve with WinDbg but once you get over that hump, it is super easy to quickly diagnose issues like these.

这篇关于IIS System.OutOfMemoryException问题Web服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！