On Wed, Mar 16, 2011 at 4:07 PM, G.Waleed Kavalec <[email protected]> wrote: > Due to a third party app we have some servers running W2K8 32-bit > SQL 2008 on said machines does not seem to want to use the full 16GB
Okay, this gets complicated. Some 'splaining is needed: On any 32-bit x86 system, each process can access a maximum of 4 GiB of virtual address space. PAE lets the kernel keep track of the full 16 GiB, but it can only map a maximum of 4 GiB at a time into any given process's memory space. The pages mapped into that virtual address space can be and usually are different for each process. So one program's pages are kept in one spot in RAM, and another program's pages are kept in another spot in RAM, and all the kernel has to do is change the mapping at each task switch. So > 4 GiB RAM helps if you've got lots of processes. If the server is spending most of its time in a single process, > 4 GiB RAM may not help at all (AWE being the exception). On 32-bit Windows, by default, the 4 GiB virtual address space is split equally between the kernel and the user process. Thus, each process is limited to 2 GiB that it can use. If you add the /3GB switch to BOOT.INI, that changes the split to 3 GiB user / 1 GiB kernel. This in theory lets processes access up to 3 GiB of stuff. However, unless the program was specifically compiled with the LARGEADDRESSAWARE flag, the OS will only give that particular process 2 GiB. I presume SQL is compiled with LARGEADDRESSAWARE, but if your app has other executables running that interface to SQL, and they weren't built for it, they won't get any benefit from the /3GB switch. Worse, because the kernel is now limited to 1 GiB address space, *much* less address space is available for kernel purposes. It puts a ton of pressure on various kernel resources. So the /3GB switch is not always a performance win. AWE works like this: A process maps asks the kernel for some new pages. The kernel maps some RAM pages into the 2/3 GiB address space. The process puts data in those pages. The process tells the kernel to unmap those pages but keep them allocated to the process. The process then asks for more new pages. Repeat. If the process needs to access some of those pages it asked to be unmapped-but-retained, the process has to tell the kernel to unmap some *other* pages, and then tell the kernel what pages to map back in. This lets a process access more than 2/3 GiB of RAM, while still living in a 2/3 GiB address space. However, it's extremely cumbersome, so almost nothing does it. MS-SQL is one of the few things that does use AWE. > The vendor has NO plans to upgrade their product. (yeah I'm looking at YOU > Sterling Software) I hope you're looking for another app in the mean time. > I have PAE and AWE turned on, and the machine is still using 3GB of the page > file and running slow. ASB addressed this pretty well. In particular, I wonder if "using 3GB of the page file" and "running slow" are actually correlated. What stat are you looking at for "using 3GB of the page file"? If it's the one in Task Manager, that's a misleading label. It's actually reporting the amount of *committed* memory, i.e., memory which the OS has promised it can supply. Committed memory can be *backed* by the page file -- that is, space in the page file is reserved for it -- but it isn't necessarily *written* to the page file. So "using 3GB of the page file" may not actually result in any I/O to the disk holding the page file. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
