IIS为什么不清理池回收中的旧工作进程(w3wp.exe)导致网站内存不足异常? [英] Why isn't IIS cleaning up the old worker processes (w3wp.exe) on pool recycle leading to website out of memory exception?

问题描述

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

I have an asp.net-mvc site and recently I am getting an out of memory exceptions on my web server. I only have 1 application pool and we recent set IIS to recycle after it hits a certain limit. I went in the other day and saw 4 w3wp.exe processes running (each with ~1.8GB memory being used)

我认为在回收过程中，这并没有杀死旧的工作进程，最终我的网站上出现了内存不足的异常，因为该盒子只有8GB的内存.我可以在存储盒中添加内存，但是我担心为什么这些旧进程没有被清理.

I assume that during the recycle process, it's not killing the old worker process and eventually I get out of memory exceptions on my website because the box only has 8GB memory. I can add memory to the box but I am concerned why these old processes are not being cleaned up.

是否有任何建议可以弄清楚为什么此循环过程不会杀死旧的w3wp.exe进程并使它们继续运行?周围是否有任何建议都可以理解根本原因甚至解决方法，以避免这种风险的继续发展?

Are there any recommendations to figure out why this recycle process is not killing the old w3wp.exe processes and leaving them running? Any suggestions around understand both root cause or even workarounds to avoid this risk going forward?

推荐答案

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

I had similar issue when I was running things like FFMpeg.exe or some PDF conversion with WPF graphics, IIS process won't shutdown and would issue memory not found errors. The problem is not with IIS, but some deadlocks in the process which blocks even after crashing.

解决方法是，将您的网站分为两个单独的网站，一个应该只对通常没有崩溃的数据库进行事务处理.诸如视频/照片转换，PDF转换之类的逻辑或任何其他可能导致崩溃的逻辑都应移至其他Web服务.并在内部使用您网站的HTTP调用来通过Web服务对其进行处理.

Workaround is, divide your website in to two separate websites, one should only do transaction processing with database which usually does not have crashes. The logic like video/photo conversion, PDF conversion, or any other logic that may cause crash should be moved to other web service. And use HTTP call from your website internally to process them over web services.

现在，在这种情况下，仍然无法解决Web服务进程崩溃的问题，因此我决定每100个请求回收一次应用程序池工作程序(我在观察了很少的请求后选择了这个数字，平均而言，它将超出仅在达到200个请求后才有1GB的存储空间)，然后我通过将每个池进行4个处理，将应用程序池变成Web Garden.

Now, in this case, there is still no way to get around web service process crashing, so I decided to recycle application pool worker every 100 requests (I chose this number after watching few requests, on an average it would go beyond 1GB only after hitting 200 requests) and I turned application pool into Web Garden by making 4 process per pool.

此设置的优点是，您将来可以轻松地将Web服务进程移动到其他计算机，可以增加/减少每个池的进程数.您的主要网站(仅在进行交易过程)不会因Web服务的流程回收而受到影响，因此响应速度很快.

Advantage of this setup is, you can move your web service process to other machines easily in future, you can increase/decrease number of processes per pool. And your main website, which is simply doing transaction process becomes highly responsive as it is not affected by process recycles of web services.

这篇关于IIS为什么不清理池回收中的旧工作进程(w3wp.exe)导致网站内存不足异常?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！