June 4, 2008 at 10:09 am
I am still confused as to how can a 32-bit application reference above 2GB without AWE 32 as the /3GB switch just tells the O/S not to use it but make it available for application use, but the application needs AWE to be able to try and use the extra GB doesn't it?
June 4, 2008 at 10:15 am
sotn (6/4/2008)
I am still confused as to how can a 32-bit application reference above 2GB without AWE 32 as the /3GB switch just tells the O/S not to use it but make it available for application use, but the application needs AWE to be able to try and use the extra GB doesn't it?
in a word, no.
---------------------------------------------------------------------
June 4, 2008 at 10:19 am
sotn (6/4/2008)
I am still confused as to how can a 32-bit application reference above 2GB without AWE 32 as the /3GB switch just tells the O/S not to use it but make it available for application use, but the application needs AWE to be able to try and use the extra GB doesn't it?
I'm thinking you have your numbers crossed a little. 4GB is the max amount addressable by a 32-bit OS. In the first 4 - the OS "grabs" 2 for itself, leaving 2 available (again - in the lowest 4).
The /3GB forces the OS to operate only in 1GB instead of the 2GB it would usually use, which is why you can "memory starve" the OS side with the 3GB flag.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 4, 2008 at 10:25 am
Yes I misunderstood, as I thought a 32-bit is limited to 2GB but my maths were out, 32-bit = 4GB max
It all makes sense now.
Thanks
June 4, 2008 at 10:28 am
george sibbald (6/4/2008)
the /3GB switch is to access more than 2Gb in the first 4GB of memory. AWE (along with /PAE in the boot.ini) is to access memory above the 4GB line. If you have 16Gb or more actual RAM, remove /3GB switch so as not too starve OS of memory. some people have obviously hit problems with /3GB switch and less than 16Gb RAM, so you may need to test that option.
HTH
george
That's correct - with one extra qualification:
from http://support.microsoft.com/kb/283037/#appliesto:
In Windows Server 2003, PAE is automatically enabled only if the server is using hot-add memory devices. In this case, you do not have to use the /PAE switch on a system that is configured to use hot-add memory devices. In all other cases, you must use the /PAE switch in the Boot.ini file to take advantage of memory over 4GB.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
June 4, 2008 at 12:00 pm
MArios, hot add memory proviso useful to know, thanks.
thats the trouble, the playing field keeps changing........
---------------------------------------------------------------------
June 4, 2008 at 1:11 pm
george sibbald (6/4/2008)
MArios, hot add memory proviso useful to know, thanks.thats the trouble, the playing field keeps changing........
So true, trying to catch up myself... 🙂
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
June 11, 2008 at 7:51 am
I agree, an interesting discussion on using more than 4GB of RAM with 32bit hardware. Couple of points I would like to add/clarify:
No application references memory directly; all applications makes calls to the "virtual address space", which the Windows OS makes available. This virtual address space is reliant on several factors, including Page Table Entries, PTEs, which should be monitored (as PTEs consume memory).
"Pool Nonpaged MegaBytes", also called the "NonPaged Pool" or "Kernel Memory", is system memory which cannot be written to disk. Generally speaking, the max size for the NonPaged Pool is 256MB (although the theoretical max is around 460MB). This size is not configurable (except with the boot switch /3GB, which reduces the Pool to 128MB). Even with gigabytes of RAM, the NonPaged Pool size remains the same. I only know this because I recently had a hefty server, with 24GB of RAM, running MS SQL Server Reporting Services, fail because "The server was unable to allocate from the system nonpaged pool because the pool was empty", EventID 2019. That didn't impress the owners of the box, who had spent a lot of cash to obtain over-specced hardware. I advise you to monitor "Pool Nonpaged Bytes", available under either Memory or Process objects in Performance/PerfMon, especially if you use the /3GB switch.
There is a difference between an application referencing >4GB, the OS referencing >4GB, and the Processor referencing >4GB. Physical Address Extension, PAE, which enables support of more than 4GB of RAM, is an Intel technology. PAE is utilised by the OS, and all applications can benefit (the application itself is completely unaware of the trickery going on behind the scenes). PAE is enabled by adding the /PAE switch to the boot.ini file (or, if the processor supports DEP, it is enabled automatically).
AWE is an API; an application must be specifically coded to make use of AWE (SQL Server 2005 is one such application). AWE is reliant on PAE.
Sorry, this just gets more complicated.... Maybe Steve's suggestion to use 64bit hardware is well advised.
Andy
References:
"Memory Support and Windows Operating Systems"
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
"Physical Address Extension - PAE Memory and Windows"
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx
"Operating Systems and PAE Support"
http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
Understanding Pool Consumption and Event ID: 2020 or 2019:
Change the maximum amount of paged kernel memory
http://support.microsoft.com/default.aspx?scid=kb;EN-US;304101
June 11, 2008 at 7:56 am
Thank you AndyD for the very valuable info.
Wow, I'm still trying to wrap my head around memory architecture and what all the terms mean...
These are not easy concepts to master...
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
June 13, 2008 at 1:36 pm
please note that awe is available with 4gb of ram, you do not need more than 4gb to use it.
we're only talking x32 here. The real advice is to forget x32 and move to x64 - I just can't understand why anyone is still building x32 boxes unless the box doesn't support x64.
I can concur that throwing lots of memory at x32 boxes does not resolve basic lower memory issues, what surprises me is that x32 is still around - I asked at the launch of sql 2005 if we should be moving to a 64 bit platform and would we likely run into problems with x32 if we deployed SSIS, SSRS and any of the other extras along with IIS on a SQL server - the answer was go 64 bit. I've even heard tell that sql 2008 was planned as 64 bit only and some of the delay is making it run 32 bit - how true that is I don't know.
With hardware as it is and memory prices low I'm still quite surpised to find 4 and 8 core boxes with 4gb of ram - the amount of memory the schedulers require along with other background stuff makes x32 almost unworkable, and x64 is no exception to this, I put a minimum of 6gb to the o/s on x64.
If you monitor your paging you'll probably find sql server paging.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
June 13, 2008 at 5:12 pm
colin Leversuch-Roberts (6/13/2008)
please note that awe is available with 4gb of ram, you do not need more than 4gb to use it..
colin, you sure? Even if this is so surely you would never configure the server like this, especially with SQL 2000 where you have to fix the amount of memory.
---------------------------------------------------------------------
June 16, 2008 at 8:03 am
On the question of 64-bit over 32-bit, I don't believe that it is as clear-cut to say 64-bit will always perform better than 32-bit. There are a couple of situations where the oposite may be found, as per the following blog:
So, its a case of knowing the work-type/load of the database you have ;).
Another option we have used in the past for getting as much out of the resources was the /USERVA switch in-place of the /3GB switch. This allowed us to control the amount of extra memory we allocated to the SQL instance but ensuring that we didn't starve the OS and MemToLeave areas. On a SQL box with no other apps running and no etra 3rd party tools, such as litespeed, etc., we often found the best setting to be in the region of 2560 (2.5GB) to 2765 (2.7GB). Again, though, we tested and monitored the systems to make sure they didn't run into excessive paging or other memory issues.
Worth looking at http://chadhoc.net/post/2007/10/PAE-and-3GB-and-AWE-oh-my.aspx too.
HTH
June 16, 2008 at 9:51 am
http://chadhoc.net/post/2007/10/PAE-and-3GB-and-AWE-oh-my.aspx
Thanks for the link, an easy read but it explains some complex technologies. I wish I'd come across it a few months back.
June 16, 2008 at 1:00 pm
Well given a box with 4gb of ram if you want to play with the memory you can either enable the 3gb switch or enable awe and set sql server upper memory. With awe you only get a bigger data cache, which might be what you need.
as to x64 - x32 still constrains the procedure cache and other memory pools as well as being constrained in VAS. Remember there are a number of sql ops which run out of memory 9 or in lower 2gb ) these include any extended procedure calls, any procs which require more than 8kb, DTS, sysmaint.exe and let's not forget RDP/TS, anti virus, server monitoring software, all the windows services, backup agents, file copy. What you get with x64 is flat memory - take it from me I've not found an x64 box running slower than an x32 box - what tends to have brought this myth about is that many upgrades went from x32 sql 2000 to x64 sql 2005 - I've dome a few of these and changes in the compiler/optimiser could certainly make your code run very very badly compared to sql 2000.
In all the cases I worked this was down to poor queries, inappropriate indexes and wildly changing parameters to procs - what I'll say is that sql 2005 is less tolerant than sql 2000 from that point of view.
I'm very familiar with all the posts about x64 vs x32 , been there etc. etc. I have x32 and x64 test servers at home and I've been deploying x64 prod servers for over two years now without issue.
The point remains that 2gb VAS is not sufficient for sql server, SSRS, rendering, SSIS and so on and it's sensible to move to x64 as long as you have adequate memory, probably 16gb minimum.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
June 16, 2008 at 1:10 pm
colin Leversuch-Roberts (6/16/2008)
Well given a box with 4gb of ram if you want to play with the memory you can either enable the 3gb switch or enable awe and set sql server upper memory. With awe you only get a bigger data cache, which might be what you need.as to x64 - x32 still constrains the procedure cache and other memory pools as well as being constrained in VAS. Remember there are a number of sql ops which run out of memory 9 or in lower 2gb ) these include any extended procedure calls, any procs which require more than 8kb, DTS, sysmaint.exe and let's not forget RDP/TS, anti virus, server monitoring software, all the windows services, backup agents, file copy. What you get with x64 is flat memory - take it from me I've not found an x64 box running slower than an x32 box - what tends to have brought this myth about is that many upgrades went from x32 sql 2000 to x64 sql 2005 - I've dome a few of these and changes in the compiler/optimiser could certainly make your code run very very badly compared to sql 2000.
In all the cases I worked this was down to poor queries, inappropriate indexes and wildly changing parameters to procs - what I'll say is that sql 2005 is less tolerant than sql 2000 from that point of view.
I'm very familiar with all the posts about x64 vs x32 , been there etc. etc. I have x32 and x64 test servers at home and I've been deploying x64 prod servers for over two years now without issue.
The point remains that 2gb VAS is not sufficient for sql server, SSRS, rendering, SSIS and so on and it's sensible to move to x64 as long as you have adequate memory, probably 16gb minimum.
Regarding sql 2000 32-bit -> sql 2005 64-bit upgrades:
Would the problems you mention be remedied by simply updating the stats right after the upgrade?
Or are there any other curve balls to watch out for?
Thanks for the input! 🙂
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
Viewing 15 posts - 31 through 45 (of 64 total)
You must be logged in to reply to this topic. Login to reply