We help IT Professionals succeed at work.

SBS2008 Memory management with SQL

Medium Priority
1,446 Views
Last Modified: 2012-05-11
It seems that SBS 2008 has an insatiable thirst for system resources, and since many of our deployments are somewhat limited in terms of hardware, we're looking for ways to decrease the physical memory usage of SBS 2008. its not uncommon for many of our sites to see 90-99% memory utilization with 8GB RAM under no significant load. One of the things that has stood out to us are the Share Point and WSUS SQL processes. I've read that these will use the maximum allotment of RAM unless its needed by another process, but when i look at \\.\pipe\mssql$microsoft##ssee\sql\query and check the RAM allocation its listed as
Minimum Server Memory : 1280
Maximum Server Memory: 6400
Are these values reasonable for the built-in OS databases? Considering that if Share Point isnt being used, I'd like to know how low we can set these values and maintain a stable environment.

I've looked fairly thoroughly and havent been able to find any authoritative guide to Tuning the Memory usage on SBS 2008, and what little i have seen has been very vague or suggesting that i run 32GB of RAM, so any advice on this would be helpful.
Comment
Watch Question

DonNetwork Administrator
CERTIFIED EXPERT

Commented:
IT

Author

Commented:
I know that i *can* limit this, but more importantly is what the limits should reasonably be.
Network Administrator
CERTIFIED EXPERT
Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
CERTIFIED EXPERT
Distinguished Expert 2018

Commented:
RAM that isn't being used is RAM that is going to waste. This is true for desktops and servers alike. RAM is faster than disk access, so you *want* to see high memory usage. More specifically, however, SQL and Exchange are particularly transaction oriented, so they have been designed to grab memory to improve performance. While you *can* limit memory, this actually decreases performance, not increases it, so in most cases it is best to leave the defaults as is.

-Cliff
DonNetwork Administrator
CERTIFIED EXPERT

Commented:
@redeyeinc

limiting my WSUS SQL memory allowed our other applications that also use SQL to perform much better.

So there are definitely logical useful reasons to throttle SQL instances from hogging memory.
IT

Author

Commented:
@Cliff

i realise and appreciate that, however if all the RAM is being used this does not allow for any volatility in the workload without lots of paging, and since we're not using Share Point, and our updates are being deployed manually there is no sound reasoning for allowing the SQL db to use as much RAM as is currently allocated for it.
IT

Author

Commented:
@dstewartjr

I'm waiting to touch base with the Microsoft team before making the change, but i'll let you know how it goes.
CERTIFIED EXPERT
Top Expert 2012

Commented:
The only reason you need to limit the memory used by SQL Server, is if you are sharing the server with other applications (this is not recommended).  Otherwise SQL Server operates best with as much memory as you can afford.
IT

Author

Commented:
@acperkins

SBS2008 includes SQL for managing its own OS db's. In this case its not optional to run these on a different server.
CERTIFIED EXPERT
Top Expert 2012

Commented:
If you cannot run SQL Server standalone, then you have no choice but to cripple it, by setting the max memory used by it.
IT

Author

Commented:
The answer didnt really give any insight as to the reasoning behind it, and it was merely anecdotal, however it appears to be an accurate solution.
CERTIFIED EXPERT
Distinguished Expert 2018

Commented:
To be very clear here, SQL and Exchange will both give up memory if they detect other applications requesting it, so the "using all RAM does not provide volatility and causes paging" is actually not accurate. If you have a quick spike, there will be *some* paging, but not much, and if an app is requesting memory long enough for SQL to detect it, SQL will give up what it is using. Again, this is some automatic performance tuning, and it actually works very well.

As far as not running sharepoint and doing manual updates, you still missed the third thing that SQL is used or on SBS. The daily monitoring reports all use data that is regularly gathered, stored in SQL, and then reported on. this is so baked into SBS that it isn't really guttable like WSUS or SharePoint. Letting SQL run as intended adds a fairly significant performance increase to both requested reports and the automated report generation, as well as better performance all around while the server collects and writes that data for later performing. By limiting SQL, this data is still being collected, but actually causes more paging which has a negative impact on your I/O across the board.

-Cliff

Commented:
SQL wil release memory... at least that is suppost to happen but some cases to late....whic can lead to out of memory...


When u have more instances it wil be a problem because they al want memory.


its better to set some limits...
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.