ASP Application, Large Memory Needs, and 64bit IIS6

Ok... I still have not gotten around to writing that uber blog entry/guide on the ins and outs of 64bit IIS6 and WOW64... so I wager I should take little bites here and there as motivation.

Writing big long technical articles that try to answer lots of things is hard for me. It is far easier if three users asked questions about various related aspects of WOW64 around the same time... because then I get motivated to answer all those questions at once, and I'll naturally collapse them into that one uber blog entry... but as fortune goes...



I am wanting to run an ASP application on Windows 2003 64 bit edition.Because some of the COM components are compiled on 32 bit machines i understand that i have to run IIS in WOW64 compatibilty mode. Does this mean i will have the same memory limitations per process of w3wp.exe (2GB) ? Do i get any benefit memory wise running IIS in this mode on windows 2003 64 bit edition? My main issue is that my Application Pool recycles too fast. I have it recycle at 1500mb because at a setting higher than this i get memory problems. Could i increase this to something like 3000mb on Windows 2003 64 bit and if so what would you reccommend the paging file size be on the disk and physical ram?



I'll answer your question in multiple parts because I do not see how COM components require WOW64 nor how it relates to Application Pool recycling and memory limitations.

I am not certain your situation requires running IIS6 in WOW64 compatibility mode.

  1. It is possible to compile 64bit binaries on a 32bit machine.
  2. Even if the COM component is 32bit and you have a 64bit w3wp.exe process running ASP pages that are creating and using the 32bit COM component, COM+ is smart enough to start up a 32bit dllhost.exe process to load the 32bit COM component and run it.

    This "magic" fails if your 32bit COM component relies on being in the same process as the ASP code creating/using it - such as if the component tries to change a thread token or read the process token. But for the most part, this is an easy compatibility approach

So, I do not see a reason why you must run in WOW64 mode. There may be other issues involved, but not according to the rationale you gave.

I am a little confused by you saying that memory-based recycling at 1.5GB is reached "too-fast" yet your application gets memory problems if the value is set higher. It sounds like your application attempts to allocate large chunks of memory, which depending on memory fragmentation inside the process, may fail far earlier than exhausting available memory. This sort of problem gets relieved only by having a lower fragmenting heap or larger memory space of native 64bit. Memory-based recycling is not a good resolution to this issue. WOW64 is not a good resolution either.

To me, it seems that you got the 64bit machine to have access to larger memory address space to deal with your application's needs. Thus, you need to look into running pure 64bit instead of trying to make WOW64 work - because WOW64 is ultimately a compatibility layer, not an architectural layer to bet the future on.

Incidentally, this is the same sort of problem that drove to quickly move its website to x64 machines and all web applications to be pure 64bit or .Net 2.0... to reap the full benefits of 64bit computing.


Comments (4)

  1. sam says:

    Thanks for the info.
    Sorry i was not clear. I am recycling the memory based upon the virtual memory size. I presumed that by virtual memory it means memory stored on disk in the page file. Is this not the case?

    There is still physical ram free on the machine when i see the out of memory problems leading me to suspect either a memory leak or memory fragmentation.

    I see the virtual bytes counter rise quickly to 1500mb (2-3 times a day) whereas the physical Ram used by the w3wp process is only a few hundred MB with plenty of RAM left to spare. I’m not sure why the virtual memory grows so high when there is enough Physical RAM. I have tried using DebugDiag but the report generated is too high a level for me to understand without more

    An example from the DebugDiag report on the w3wp process when it had a high virtual memory usage:

    Virtual Memory Summary
    Size of largest free VM block 75.21 MBytes
    Free memory fragmentation 88.13%
    Free Memory 633.53 MBytes (30.93% of Total Memory)
    Reserved Memory 1.03 GBytes (51.29% of Total Memory)
    Committed Memory 364.06 MBytes (17.78% of Total Memory)
    Total Memory 2.00 GBytes
    Largest free block at 0x00000000`685ba000

    This is the heap I identified as using the most memory

    Heap Name msvcrt!_crtheap
    Heap Description This heap is used by msvcrt
    Reserved memory 868.25 MBytes
    Committed memory 89.16 MBytes (10.27% of reserved)
    Uncommitted memory 779.10 MBytes (89.73% of reserved)
    Number of heap segments 12 segments
    Number of uncommitted ranges 8207 range(s)
    Size of largest uncommitted range 32.20 MBytes
    Calculated heap fragmentation 95.87%

    Top Allocation – Allocation Size – 1048 29.42 MBytes 29435 allocation(s)

    There are 12 heap segments and nearly all have extremely high fragmentation and they have allocated a lot of reserved memory. The commited size in each segment is very low so i’m unsure why that is the case and where i go from here to debug the application further. This has been driving me nuts for months now and there isn’t anyone i know to ask other than you experts who
    write this stuff…

    Going back to your article you say that i should run the ASP on iis in a 64 bit process and that it will automatically create a seperate dll host for all the 32 bit com objects. Do i need to set the flag Enable32BitAppOnWin64 for this to work? How do i register the 32 bit components. Is it a case of simply using regsvr32?

  2. David Wang says:

    I found myself writing a very long response to a recent comment to this blog entry, so I decided to make…

Skip to main content