On IIS, we can set a private memory limit to trigger a recycle if the worker process serving the application pool consumes too much memory. However, it seems that this computation is off when there is an orphaned worker process.
The step to reproduce the problem (tried on IIS 8 and IIS 10):
- Set up an application pool with a private memory limit (say 500 MB) and enable orphaning
- Set up a request hanging (in an infinite loop for example)
- Consume more than 500 MB of memory, so it will trigger a recycle
At this point, a new worker process is spawn to handle incoming request, while the old worker process is trying to finish all its requests before shutting down. However, due to the hanging request it doesn't manage to finish before the shutdown time limit, and the orphaning is triggered.
From this point onward, as long as the first working process is still alive, IIS will trigger recycle on this application pool, even if the "active" worker process (not the orphaned one) is way below the memory limit.
On our application, the orphaning script is used to take a dump of the worker process before killing it. This dump operation can take some time, and we can have several recycles before the first process is finally killed (sometimes enough to trigger the rapid-fail protection).
Is there a way for IIS to monitor the new worker process' private memory, and not the orphaned one?