App Pool memory drastically different from 32-64 bit - Bugs & Issues - Bugs & Issues - Progress Community

App Pool memory drastically different from 32-64 bit

 Bugs & Issues

App Pool memory drastically different from 32-64 bit

  • 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?

  • f1976382-65ad-411b-be3d-c1b5172b9a4e_memory.png
    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 :).

    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
  • So after a couple days of 700-900 megs, I changed back to 32 bit...and I'm now at 300-500 again.

    ??
  • 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

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

    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