ASP.NET：w3wp 正在使用大量内存并且进程没有响应
有人可以给我分步说明或以正确的顺序指出正确的参考文献，
以便我可以确定此问题的根本原因吗？
Can someone give me step by step instructions or point to the correct references in the correct order
so that I can determine the root cause of this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于多种原因，w3wp.exe 可能会消耗大量内存。
如果您怀疑前两个是问题所在，则需要扩展系统（添加额外的服务器等）。
内存泄漏将导致内存使用量随着时间的推移逐渐增加。
如果您怀疑内存泄漏，可以考虑以下操作。
w3wp.exe can consume a large amount of memory for a variety of reasons.
If you suspect the first two being the problem, you will need to scale the system up (adding extra servers etc.)
A memory leak will cause a gradual increase of memory usage over time.
If you suspect a memory leak, following actions can be considered.
w3wp.exe 是与 ISS 中的应用程序池相关的进程。 如果您有多个应用程序池，则将运行多个 w3wp.exe 实例。
有关详细信息，请阅读 这个
w3wp.exe is a process associated with application pool in ISS. If you have more than one application pool, you will have more than one instance of w3wp.exe running.
For more info please read this
您可以获取该进程的内存转储并在 WinDbg 中进行查看。 它至少会给您一个异常列表和线程的当前状态。 这样做会回收该过程。 还可以从 Visual Studio 以远程调试模式连接到 QA 风格的机器。 但是我没有这样做，并且在调试时它会挂起所有其他请求。
如果w3wp在本地运行，您可以在任务管理器中右键单击该进程，然后选择“调试”以在WinDbg中查看。
否则，您需要在生产/测试计算机上使用诸如“调试诊断”之类的工具来创建完整的用户转储。 请参阅：http://msdnrss.thecoderblogs.com/2008/05/21/debugdiag-11-or-windbg-which-one-should-i-use-and-how -do-i-gather-memory-dumps/
我在二月份就完成了这一切，从那以后就不再需要了。 由于获取 WinDbg 的符号并配置它们的存储位置等环境变量，完整的一步一步实际上有点痛苦。
有关为 ASP.NET 检查设置 WinDbg 的信息，请参阅这篇文章：
http://support.microsoft.com/kb/892277
You can get a memory dump of the process and look into it WinDbg. It will at least give you a list of exceptions and the threads' current state(s). Doing so will recycle the process though. It is also possible to attach to a QA style machine in a remote debug mode from visual studio. However I've not done this, and it would hang every other request while you debug.
If w3wp is running locally, you can right click on the process in the task manager and select debug to get a look at in in WinDbg.
Otherwise you want something like Debug Diag on your production/test machine to create a full user dump. See: http://msdnrss.thecoderblogs.com/2008/05/21/debugdiag-11-or-windbg-which-one-should-i-use-and-how-do-i-gather-memory-dumps/
I did all this back in February, and haven't needed to since. the full step by step is actually somewhat painful due to getting symbols for WinDbg and configuring environment variables for where they should be stored etc.
For information on setting up WinDbg for ASP.NET inspection look at this article:
http://support.microsoft.com/kb/892277