为什么IIS不清理池回收导致网站内存不足的旧工作进程(w3wp.exe)？

Question

我有一个asp.net-mvc网站,最近我的网络服务器上出现内存不足的异常.我只有一个应用程序池,我们最近将IIS设置为在达到某个限制后进行回收.前几天我去了,看到有4个w3wp.exe进程正在运行(每个进程都使用了~1.8GB的内存)

我假设在循环过程中,它不会杀死旧的工作进程,最终我的网站出现了内存异常,因为该框只有8GB内存.我可以在盒子中添加内存,但我担心为什么这些旧的进程没有被清理.

是否有任何建议可以找出为什么这个循环过程没有杀死旧的w3wp.exe进程并让它们运行？有任何建议可以了解根本原因甚至解决方法以避免这种风险吗？

Answer 1

应用程序池回收通常会关闭旧的工作进程,因此我认为您没有遇到IIS的错误.

请注意,如果进程成为孤立进程,则进程可以活得更长,并且基于配置IIS必须将它们留在那里供您进行故障排除,

如果您不熟悉调试此类过程,我建议您通过http://support.microsoft.com打开一个支持案例,并让Microsoft支持人员帮助您.

Answer 2

当我运行 FFMpeg.exe 或某些带有 WPF 图形的 PDF 转换之类的东西时，我遇到了类似的问题，IIS 进程不会关闭，并且会发出内存未找到错误。问题不在于 IIS，而是进程中的一些死锁，即使在崩溃后也会阻塞。

解决方法是，将您的网站分成两个独立的网站，一个应该只使用通常不会崩溃的数据库进行事务处理。视频/照片转换、PDF 转换或任何其他可能导致崩溃的逻辑应移至其他 Web 服务。并在内部使用来自您网站的 HTTP 调用通过 Web 服务处理它们。

现在，在这种情况下，仍然没有办法避免 Web 服务进程崩溃，所以我决定每 100 个请求回收一次应用程序池工作线程（我在看了几个请求后选择了这个数字，平均而言，只有在达到 200 个请求），我通过每个池创建 4 个进程，将应用程序池变成了 Web Garden。

这种设置的优点是，您将来可以轻松地将 Web 服务进程移动到其他计算机，您可以增加/减少每个池的进程数量。而您的主要网站（仅执行交易流程）变得高度响应，因为它不受 Web 服务流程回收的影响。