The unparalleled David Gutierrez from Microsoft stopped by and left a comment on my post about horrible PerformanceCounter slowness. His explanation in its entirety:
I can shed some light on these issues. PerformanceCounters use a machine wide memory mapped file to publish perf counter data. That file contains an object graph and various places we use as spinlocks.
The problem comes in when processes get killed unexpectedly. A process which dies while holding a spinlock won't release it, meaning the next process gets blocked. After spinning 10000 times, we assume some process died and continue on, so we won't block forever - 4 minutes on your machine. My guess is that IIS is terminating your app when it resets it.
In Whidbey we've fixed these problems. If you're interested, I can post a blog entry with more details.
The bug you mention actually isn't related. It has to do with reading perf counters, and that really is horribly slow. It was also specific to services.
Obviously, I still need to track down why this is happening, but I think his guess is likely a good one: ASP.NET worker process resets could be dropping the spinlock on the floor. Many thanks to Mr. Gutierrez!
No comments:
Post a Comment