I've always run my site on 32-bit (w3wp*32), and it hovered around 400-500 megs tops. I just swapped it to 64, and now I'm around 750Megs without entering the backend yet.
Has anyone else seen this?
This is somewhat expected. In 32-bit more, the memory usage is limited by .NET. Switching to 64-bit makes the process not so conservative to memory use, since there are much more memory addresses to use :).All the best,
Yes thank you Dr. Obvious :)
Running in 32 yields no noticeable performance difference on any of the running sites (8 core VM)....certainly not 3 times better performance (64 eats 3 times the ram)
So running with a 32 bit process lets me run 4-5 sites on my VM as opposed to 2 (and having to limit sql)
There's no catch. The option is there in case the application is specifically compiled to run under 64-bit environment only. You guys are right - since Sitefinity can run under 32-bit mode, we should document that this mode takes less memory. I doubt that anyone using Sitefinity is specifically compiling his code to 64-bit, but we'll put a remark on this anyway. Since there are questions below, one of the biggest reasons to use 64bit is in case you need more than 4GB during runtime.
Since it seems I wasn't very specific in my last post :) - the framework allocates not only managed but also unmanaged memory. While the managed variables take the same memory in 32 and 64 bit environments, the unmanaged depend on the environment, so in 64-bit they are twice bigger. I've checked some past results on memory profiling of Sitefinity - around 35-40% of the consumed memory is unmanaged one, so we can expect at least 35-40% more memory used in 64bit. Some further research I did this morning (Monday, yeaah) - seems the GC in 64bit mode is running much less often (leaving more memory!) but this results in faster performance (GC is expensive). In conclusion, if you care about performance only - go for 64bit. If you want some balance between resources and performance - go for 32bit. Obvious again, right Steve? :)
We'll send the thread for documentation.
The performance different is not big. You could notice it on dynamic sites with a lot of concurrent users though. In that sense, it can be measured but won't be visible to the "naked eye" :).Regards,
A new issue have poping up here. We have a site which in 32-bit will eat over 1GB memory. App-pool have an limit in 1GB so we need to switch it to 64bit. Now the site eating 4GB. It's hell to much memory. Can we tweak the 32-bit part so the pool can handle over 1GB?
Primary memory limit: Maximum amount of private memory (in KB) a worker process can consume before causing the application pool to recycle.
Virtual memory Limit: Maximum amount of virtual memory (in KB) a worker process can consume before causing the application pool to recycle.
Both the above settings are set to 0 by default, which means there is no limit set.If you are using 32-bit IIS process, by navigating to the Advanced settings of the application pool you could increase the limit of the Virtual Memory (for example: 2GB). If you are using 64-bit IIS process you could decrease the limit to be smaller than 4GB for instance.