After deployment of a new pair of F5 load balancers, some of our more heavily loaded IIS6 load balanced pairs started experiencing application pool crashes. Certain pools would go down and stay down due to rapid fail protection being enabled. CPU usage was high and RAM usage was through the roof. This was caused by an overly aggressive polling period by the load balancer – it was checking the sites too frequently causing an abnormal number of unused sessions to hang open until they timed out.
Reducing the polling period helped the load a bit, but we were running afoul of KB831135, lack of memory in the shared Windows Desktop heap. There is a limit to the number of application pools you can have each using their own identities. You don’t run into the issue if you use the IUSR or Network Service, the issue only occurs if you’re using individual accounts for each resource pool. Various searches on the web indicate about 60 individual pools as the limit, but we had double that with no problem prior to this issue. The fix is to create a DWORD registry entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\UseSharedWPDesktop with a value of 1. The article said that an iisreset would take care of loading the new setting, but we found that a reboot was necessary.
We decided to utilize the UseSharedWPDesktop configuration option to immediately fix the problem. The machines in question are not externally facing so the potential security issues related to enabling UseSharedWPDesktop were not of much concern to us. David Wang’s explanation goes deeper into the ramifications of the configuration