App Pool memory drastically different from 32-64 bit

Posted by Community Admin on 04-Aug-2018 20:38

App Pool memory drastically different from 32-64 bit

All Replies

Posted by Community Admin on 28-Dec-2012 00:00

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?

Posted by Community Admin on 02-Jan-2013 00:00
So after a couple days of 700-900 megs, I changed back to 32 bit...and I'm now at 300-500 again.

??
Posted by Community Admin on 02-Jan-2013 00:00
There's something to this

I changed my OTHER sites app pool (running at a steady 900M) to Enable32Bit and editing the backend I'm at 245Megs, a FAR FAR cry from 900M.
Posted by Community Admin on 02-Jan-2013 00:00
Hello,

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,
Georgi
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Posted by Community Admin on 02-Jan-2013 00:00

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)

http://www.iis.net/learn/web-hosting/web-server-for-shared-hosting/32-bit-mode-worker-processes

Posted by Community Admin on 04-Jan-2013 00:00
I am having similar results.  700+MB down to about 300MB for all 4 instances of Sitefinity 5.0.  Will continue to monitor over time to ensure nothing's broken by running in 32bit mode.
Posted by Community Admin on 04-Jan-2013 00:00
Nothing will be broken, if anything it'll just be faster

What I was seeing (before when it was 700+) I'd watch a new site warm up and I'd have to wait for the ram to slowly climb to hit 500-600 before the site came to life.  Now it'll pop up arond 150-200 tops.

Moved all my sites to 32 (live and dev) and haven't had any issues...
Posted by Community Admin on 04-Jan-2013 00:00
So I have to wonder though - what's the catch?  I have a hard time believing it's this simple when all along we've been battling memory gobbling issues and nobody ever suggested configuring the app pools like this.  Or have they?  Have I overlooked some guidance from Telerik that this is even an option?  Curious...  

Anyways - we'll continue to monitor for issues.  Our configuration is load-balanced and multilingual, so we tend to run into the edge-case issues more often than not.
Posted by Community Admin on 04-Jan-2013 00:00
I can't find anything that tells me we should be using 64 over 32...actually the exact opposite

serverfault.com/.../multiple-32bit-processes-on-64bit-iis-memory-limit

...so I don't know why it's not documented anywhere, maybe nobody noticed?...because in 32 mode it's quite memory efficient.
Posted by Community Admin on 04-Jan-2013 00:00
On a 64bit version of Windows, by default, IIS wants to create 64bit app pools.  So if running under 32bit app pools is the way to go - I wouldn't mind seeing that documented somewhere.  For example, here: www.sitefinity.com/.../system-requirements 
Posted by Community Admin on 04-Jan-2013 00:00
Default can be changed too (for anyone else reading this)
www.iis.net/.../32-bit-mode-worker-processes
Posted by Community Admin on 07-Jan-2013 00:00
Hello,

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.

Regards,
Georgi
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Posted by Community Admin on 07-Jan-2013 00:00
Hey Georgi,

Since its now roughly 3pm and you've probably had a healthy dose of caffeine by now, any insight into the performance increase? I mean, is it visible or just measurable?

If its just measurable then it'll only affect the geeks being excited, but if its a significant visual performance increase, than Steve's discovery will (or should at least) affect hosting choices...

Jochem
Posted by Community Admin on 10-Jan-2013 00:00
Hi,

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,
Georgi
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Posted by Community Admin on 14-Nov-2013 00:00
Need to lift this thread up again.

Do we have an conclusion of this that 32-bit is a better option if I have a lot of SF on same server and 64-bit is a better choice if I need huge performance with thousand of users simultaneously?


Posted by Community Admin on 14-Nov-2013 00:00
Unless your sitefinity instance is in need of > 4 gigs of ram, 32 just runs better...in every case I've tested.
Posted by Community Admin on 15-Nov-2013 00:00
Just as I thought. SF climbs up approximately 900MB in 64 bit on our sites and the traffic they have, it is not at all necessary.

What does the SF team about to run 32 in all cases? Any issues with it if we run in 32 bit?
Posted by Community Admin on 19-Aug-2014 00:00

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?

 

Posted by Community Admin on 22-Aug-2014 00:00
Hello,

I would suggest you to review the following blog post:

blogs.msdn.com/.../chat-question-memory-limits-for-32-bit-and-64-bit-processes.aspx

Basically if 32-bit IIS process is used on 32-bit operating system and you could have maximum 2GB amount of memory available. If you are using 64-bit operating system you could have maximum 4GB amount of memory available.
    
Regarding the memory limits of the application pool, it can have a private memory limit and a virtual memory limit.

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.
    
You could also discuss these questions with your administrators who would provide further information.
   
Regards,
Stefani Tacheva
Telerik
 
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
 
This thread is closed