A guest post by Rick Barber – a senior technical lead over at managed Windows host OrcsWeb:
At OrcsWeb we recently came across an issue where a user was having performance issues with a bare-bones Orchard installation on a shared server. We tried to reproduce the issue and sure enough, any time the site was browsed to it took about 20 seconds to load.
Initial troubleshooting identified the cause for the 20 second load times: the application pool was constantly recycling because it was hitting the virtual memory limit. Great! Now we knew what was going on and could begin our quest to get to the root cause of the recycle.
The next obvious place to look was the memory settings on the application pool. Since this is a shared server there are memory limits in place. Orchard takes a large chunk of memory for the initial compile which was causing the application pool to hit the virtual memory limit. We increased the virtual memory limit to 2 GB and the application pool was still recycling, just not as often. We set the virtual memory limit to unlimited and the application stabilized and we continued to monitor it. Setting Virtual Memory Limit (KB) to 0 effectively allows it to use unlimited memory as shown above.
A short time later we noticed that the application was using over 5 GB of virtual memory. We tried some other memory settings but they all caused the application pool to recycle frequently.
After more investigation we noticed that the application pool was running in 64-bit mode. Since that setting allows more memory use for an application, we changed it to 32-bit mode. Setting ‘Enable 32-Bit Applications’ to True sets the application pool to 32-bit. Almost immediately the application started running properly.
We were then able to go back and set a reasonable amount of virtual memory to the application pool. The Orchard site continues to run properly utilizing less than 800 MB of virtual memory.
You should really monitor the recycles of all other managed apps, that is not Orchard specific, .net in 64bit machines will reserve a percentage of physical memory for virtual use. You should recycle in my opinion inky by private memory and not memory (virtual). I’ve seen that mistake done several times just to find the apoool recycle every 30 seconds (interval that WAS monitors processes), you might be only noticing with Orchard apps because of the slow startup it has.
We host many thousands of sites and this is not a wide-spread issue. I agree that it isn’t Orchard-specific and is related to 64bit, but it seems that something that Orchard is doing (perhaps in the warm-up module since that is where we saw the longest delay and memory climb) isn’t laying nicely with the 64bit setting.
It sounds like the culprit was 64 verses 32. Was there something in the 64 that was causing the issue that could be fixed? (or did I miss something)
Correct. Switching to enable 32bit resolved the issue. Nothing else changed code-wise and changing that setting on/off quickly caused the issue to start/stop so it is definitely related.
I too was facing this same issue on my Window Hosting.
I told them to change the App Pool version to 32Bit and now my 2 Orchard sites are working awesomely.