App Pool memory drastically different from 32-64 bit

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?

So after a couple days of 700-900 megs, I changed back to 32 bit...and I'm now at 300-500 again.

??

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.

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 :).

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

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.

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...

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.

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.

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 

Default can be changed too (for anyone else reading this)
www.iis.net/.../32-bit-mode-worker-processes

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.

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

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" :). 

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?

Unless your sitefinity instance is in need of > 4 gigs of ram, 32 just runs better...in every case I've tested.

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?

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?

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.