Last post Apr 26, 2005 03:25 PM by Kressilac
Apr 15, 2005 05:46 AM|alistairk|LINK
I've observed that on a 4GB box (32bit Win2K3 Ent RTM) that IIS6 seems to hit a limit of memory usage at 3GB. Does anybody know if it's possible to scale beyond this limit by running each web app instance as an isolated process?
Apr 17, 2005 10:01 PM|qbernard|LINK
AFAIK, in w2k IIS 5 can address up to 4GB of memory. Do you specify /PAE in boot.ini ?
Apr 18, 2005 09:30 PMfirstname.lastname@example.org|LINK
This isn't quite right.
This is a complicated question, that requires some history of IIS and Win32 memory management / limits of 32 bit memory management.
The design of the processes in IIS have changed a few times, in 1-3 things were all in process, 4 introduced out of process (I'm picking my old brain cells, I may miss a version # / date somewhere here), 5 changed the out of process file name and a few other
ANY 32 bit process can scale to 4gb of RAM, however the process can't address more than 4gb of RAM. You CAN have multiple processes which address 4gb of ram EACH, but a single process can't do over 4gb itself.
So in IIS 1-3, since it was one process, you had 4 gb total available for ALL sites, ALL isapi filters / isapi applications. You ran out of ram from time to time, but during 1-3s life 4gb of ram was pretty much unheard of (We started at IIS 1.0 hosting with
128mb ram in the boxes, and DRAMATICALYL outperformed other hosts because they were doing less ram - Kind of funny looking back on it, but at that time 48-64 mb was fairly normal ram)..
In IIS 4, with out of process, you could potentially have 4 gb PER PROCESS (i.e. in mtx.exe). In IIS5 this process changed to dllhost.exe - Not much else changed related to this between 4 and 5.
In IIS 5 when ASP.Net was released the applications ran out of process in their own context, instead of inside dllhost. So ASP.Net had it's own 4 gb of RAM (potentially).
Unfortunately we still host a fair number of sites that simply don't work in the new model and Windows 2000 servers are *FAR* more reliable than 2003 because of this exact reason.
Now, realize all this "ram" is virtual memory, it can be swapped out to disk, etc. This isn't particularly better - Also with context switches between applications NT isn't very good (*nix on the other hand handles process switches great, but generally
threading isn't available so by design you switch processses instead of threads). NT is more "thread" friendly, and performs FAR better with more threads in one process running.
So all this said in IIS6 this changes to ASP_WP.EXE (which is your application pool) running everything, and all the threads there. This is a single process - This increases performance (combined with numerous other changes). HOWEVER this also restricts
you to being at 4gb of RAM per process limit making that apply to almost ALL of the things loaded, not only asp.net
Some of the 4gb of ram is occupied with DLLs and such, so not all is addressible as data. I don't know the exact number, but probably 3gb is a safe number to assume.
You should be enabling recycling of the process if your ram usage gets too high, otherwise you'll get out of memory exceptions in your asp.net code.
I haven't tried this on 64 bit windows, but in theory processes will have far more addressable memory available, and this 4gb limit shouldn't apply. I'm sure soon we'll be testing 64 bit IIS internally, but so far we haven't done anything with it.
The /PAE switch, to the best of my knowledge, is ONLY for machines with > 4gb of ram - It has nothing to do with IIS, nor would it effect 3gb limit (or the 4gb per process). It has something to do with addressing larger amounts of ram - I didn't bother to
look this up for an exact definition of it.
Also be aware some motherboards have bugs at 3gb of ram, I don't have a list, but I've seen a few posts about that over the last few years - I don't recall where - Most were cheap desktop boards, not quality server grade hardware.
Hopefully this helps you understand numerous things about memory errors and limits of memory.
You can try using web farms in your application pool, that will split your load to 2 memory pools (4gb each). I've had mixed results with doing this strictly for memory allocation - It doesn't always work, sometimes it backfires.
Steve Radich - http://www.aspdeveloper.net - Virtual Server FAQ
BitShop, Inc. - http://www.bitshop.com - Managed Servers, Colocation,
Apr 19, 2005 02:06 AMemail@example.com|LINK
I'm sorry, I wasn't thinking when I wrote my last reply to this.
4gb is total available for kernel and application, 2gb for application. I don't know where my mind was <still looking for it :-) >
The other facts were correct, just the numbers were all wrong.
the /3gb option will change to 1 gb of kernel ram and 3gb user process ram, generally this works for some apps and not others. Personally mosttimes I've tried it with IIS I had no noticeable results (when you do that kernel ram is descreased, which includes
the disk cache, and other things the os really needs to have enough ram for).
Steve Radich - http://www.aspdeveloper.net - Virtual Server FAQ
BitShop, Inc. - http://www.bitshop.com - Managed Servers, Colocation, ASP.Net Development
Apr 19, 2005 09:36 PM|qbernard|LINK
Thanks for the info. and by default any win32 app will be able to get 2gb each. Reason for /3gb or /pae to is allow OS to address more memory space (large memory aware + AWE) which will facilitate IIS and other apps which need more memory.
/3gb for > 3gb and < 4gb
/pae for >= 4gb.
So for 4GB box, I always enable PAE.
Apr 21, 2005 06:31 AM|alistairk|LINK
Apr 26, 2005 03:25 PM|Kressilac|LINK
As far as I know, the OS is limited to either 2 or 3GB of ram using the 3GB switch. A machine running Windows anything 32bit is only ever capable of using 3GB of ram for user processes. Non-paged-pool and other OS memory chunks occupy the other 1GB on
4GB machines. Theoretically, each process can address 4GB of ram though there is only 3GB of ram available to all processes.
Now, PAE is offset technology equivalent to the FAR and NEAR pointers of 16bit days. In order to address any memory greater than 4GB the OS must calculate an offset from the base memory address of the ram over 4GB. Each call to PAE memory incurrs an additional
lookup in this address table. The OS, shifts its addressable window away from the base 4GB and points at the higher RAM, retrieves the values in memory and loads them into the CPU cache, then returns the memory address space back to the lower 4GB and resumes
operations. All in all PAE is a hack and only works for applications that are aware of the PAE memory offsetting functions. SQL Server is aware, Exchange is aware and I believe IIS is aware as well.
Given enough RAM, IIS processes could each address 4GB of their own ram through PAE extensions. On a server without PAE, your limit is at best 3GB and likely closer to 2 - 2.5 considering all the other processes and such running on a typical server.
Lastly, remember that with the 3GB switch, less memory is available to create TCP/IP socket handles and other OS only resources. Without the handles, the HTTP daemon in IIS can't serve a page. I'm not sure if a high traffic web site or three would cause
problems on a 3GB switched server. Perhaps someone else in this forum can shed light on this.
ps 64bit enables a greater address space removing the need for PAE. Whether anything changes with the non-paged-pool resources used for TCP/IP sockets is another matter entirely. I'm hoping 64bits also means we can address many more socket handles. We'll