Be conservative with creating new application pools
I am currently working on a website that runs 52 instances of the application load balanced on 4 servers. We started with 1 instance and we kept adding additional instances. For each instance we added we created a new application pool. Fast forward and we were suffering some severe memory pressure on the webservers. We were running 12GB per server, we added an additional 4GB but still it didn’t appear enough. That was until we went from one application pool per instance to about 6 instances per application pool (since the application pools themselves run as 32 bit processes they cannot address more then 2GB a piece) and memory usage dropped from 16GB @ 99% to 8GB. That’s what I call a quick win.
Taking a long running memory dump of a w3wp.exe process
I recently tried creating a dump of a asp.net process but it constantly failed the application pool would recycle. The process I was taking the dump of was using a couple gigabytes of memory so it took quite a while. It turns out IIS was pinging the application pool as part of the health monitoring and recycling it after 90 seconds of unresponsiveness (caused by the dump halting all execution).
So if you want to dump a large asp.net process make sure you set ping enabled to false in the application pool settings.
