8

I see that in iis 7.5 I can set a CPU % utilization limit for a specified amount of time for an application pool. I can have also have it kill the worker process if this limit is violated. If tell it to do this, will the worker process automatically restart after it is killed, or is manual intervention required?

Over at Stack Overflow there is the mention that it can restarted at the completion of the interval...

Community
  • 1
Kyle Brandt
  • 83,619
  • 74
  • 305
  • 448

2 Answers2

4

This looks like one of those cases where simulation (or source code access...>sigh<) is probably going to be the only way to see what the behaviour is with any degree of confidence.

The documentation for the event log entry for CPU quota recycling talks about recycling as follows:

By default, application pool recycling is overlapped, which means that the worker process that is to be shut down is kept running until after a new worker process is started. After a new worker process starts, new requests are passed to it. The old worker process shuts down after it finishes processing its existing requests, or after a configured time-out, whichever comes first. This way of recycling ensures uninterrupted service to clients. However, if an application in the application pool cannot run more than one instance of itself at a time, overlapping rotation can be disabled.

It would seem to me that, by definition, terminating a worker process because of excessive CPU consumption would mean that pending requests wouldn't be allowed to be completed (since they're exhausting the CPU quota).

To speak to your major concern: I'm not seeing anything that leads me to believe that a new worker process wouldn't be spun up automatically. The statement in your Stack Overflow link does make me question if the algorithm used by IIS may, in fact, tie recycling to the resolution of the timer used to measure CPU quota exhaustion. The best way I know to determine that would be to write a CPU-wasteful server-side component, deploy it into a test environment, and see how its recycling behavior acts. A simple component that sits in a tight loop for a few seconds and then returns a known string, combined with a client running a test harness with something like a pool of parallel "wget" processes might be enough. Hammer on it with a bunch of parallel requests from a client and report on how may requests receive the proper response versus error messages, etc. (It makes me feel so silly to have to resort to things like this as opposed to just going to look at the source code...)

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • Ya looks like I might just have to test it. I already wrote a one off load testing script in python to test this sort of thing which has come in handy ... had to use hacked version of socket and http library so I could bind to different source IPs :-) – Kyle Brandt Jul 30 '10 at 16:04
  • One request might be enough though ... web app that calculates pi... – Kyle Brandt Jul 30 '10 at 16:07
  • @Kyle: I won't do an infinite request, though. I'd do something that, once you get a few requests "in flight", saturates the server's CPU but does eventually return a result. That way your test rig can report on success / failure of all the requests it makes. Otherwise you have no idea if the recycling behaviour actually results in a service-outage for clients or not. – Evan Anderson Jul 30 '10 at 17:06
  • Oh I see what you are saying ... wasn't really the primary goal of this test... but good info to have. I just want to see when it is killed, does it come back or not. The CPU limit will be something like 90% for 5 minutes on something that would be maybe 5-10% usage. Basically, it is broke :-) – Kyle Brandt Jul 30 '10 at 17:36
  • My own testing shows that running a app pool on 1 minute refresh with a CPU limit of 1 (very small), when the limit is hit, a System Event 5025 is logged, and the **application pool is stopped**, killing the w3wp process. After the time limit ends, the application pool is restarted. – glasnt Apr 03 '12 at 02:37
4

Given the comments in the other response, I've done my own testing, which I'll replicate here.

In my testing, limiting an application pool (v4.0 Integrated) to a small CPU limit (0.01%) and a small interval (1 minute) with the KillW3WP action enabled, going over this limit kills the w3wp by stopping the application pool.

After the interval limit is reached, the application pool is automatically restarted.

Changing the action to No Action does not alter the w3wp process.

In both cases, a System Event 5025 is logged.

glasnt
  • 637
  • 2
  • 6
  • 21