Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « SQL Server DBA Tip 2 - Server Configuration – Data/Log FilesSQL Server Filegroups: The What, The Why and The How »
    comments

    For the first post in the SQL Server DBA Tip of the day series, MAX Memory configuration is the topic.  Let’s get right to it…

    SQL Server Maximum Memory configuration is a value specified to limit how much memory the buffer pool can have.  The Buffer Pool consists of dirty and clean pages that SQL Server has used.  The entire contents of the pool can be seen with the DMV sys.dm_os_buffer_descriptors and you can see the state of a page using the is_modified field.  This can be seen in great detail in a post by Paul Randal, “Inside the Storage Engine: What’s in the buffer pool?”  The page count per database in Paul’s post is extremely useful for an overview of the area that the pool is being used for most in terms of databases. 

    When SQL Server starts, it uses the maximum (and minimum) memory settings to determine how much memory it can utilize for the buffer pool.  By default, the maximum memory is set to 2TB or 2147483647 KB.  The entire 2TB of memory is not used (or allocated) initially when SQL Server starts, but SQL Server will start taking the allocated memory up to the configured maximum memory value.  This is what some in the past have referred to as SQL Server’s memory leak.  It is far from a leak and completely by design.  Most small to mid-size installations are not going to have 2TB of memory installed on their database servers.  That is why this configuration is so critical to understand.  If the defaults are not reconfigured for the hardware and software that is currently installed, SQL Server will consume all of the memory it is allowed.  This has potential for causing a server to become unresponsive once under extreme pressure and at the high range of the allocated amount of memory. 

    Configuring Maximum Memory

    There are some loose standards out there on which you can base initial maximum memory settings.  Jonathan Kehayias is widely respected for his knowledge of SQL Server Internals and these settings.  In one of Jonathan’s posts for an installation checklist, he provides the guidelines of:

    1. 8GB RAM = 6144 Max Server Memory
    2. 16GB RAM = 12228 Max Server Memory
    3. 32GB RAM = 28672 Max Server Memory

    That excerpt is slightly out of context when looking at 64bit to 32bit servers and available memory but sound.  The last point that Jonathan states is the most important:

    1. These are base values that will later be adjusted based on the Memory\Available MBytes counter being > 150 on the Server.

    The monitoring of available memory is the most important factor in using a guideline.  Once you have promoted SQL Server to production or found an existing SQL Server that is not being monitored, Performance Monitor should be setup to start setting the baseline of your memory usage.  This will also show problematic SQL Servers that require an adjustment based on a limited amount of memory resources.  If low counts from Memory\Available Mbytes are found, investigate further by looking at the Buffer Manager: Buffer Cache hit ratio, page life expectancy and process: working set.   Those counters can base the needs for simple configuration changes or the need to increase memory in the server itself (physically). 

    Resources:

     

    About the Author

    Ted Krueger is a SQL Server MVP and has been working in development and database administration for 13+ years. Specialties range from High Availability and Disaster / Recovery setup and testing methods down to custom assembly development for SQL Server Reporting Services. Ted blogs and is also one of the founders of LessThanDot.com technology community. Some of the articles focused on are Backup / Recovery, Security, SSIS and working on SQL Server and using all of the SQL Server features available to create stable and scalable database services. @onpnt
    Social SitingsTwitterLinkedInLTD RSS Feed
    1215 views
    Instapaper

    5 comments

    Comment from: David Forck (thirster42) [Member]
    great topic, and one that can be easily misconfigured.

    this book has a fantasic section covering this topic, and it's worth the read. i still haven't made it far in this book though... :(book
    04/26/11 @ 12:09
    Dugi Thanks for reminding us about the Memory config details!
    Really useful info, with some selected resources - and simple explanations!
    I'm looking forward for the next tip, Ted you are doing a great job man!
    04/26/11 @ 12:42
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) :D Thanks!!! Means a great deal to me hearing that!
    04/26/11 @ 12:43
    Comment from: Matt [Visitor]
    Matt Setting maximum memory has long been common advise. However, recently a more experienced DBA has made me reconsider. For a dedicated DB server, SQL Server is supposed to perform better without a maximum limit. BOL suggests to only set this if the server will be used with other software and to not set it if it is dedicated:
    http://msdn.microsoft.com/en-us/library/ms181453.aspx
    I am told that older versions of SQL Server were not very good at allocating memory intelligently--which is probably why it is so well-known--but that this has improved much in the newer versions.

    I would be interested in a more up-to-date discussion on the merits and need for this in recent versions.
    04/27/11 @ 04:29
    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) The difference in memory management from 2000 days to now is great and a vast improvement. You should always set the max memory setting allowing memory to windows though. I'll check the BOL article out. It sounds like maybe it is worded to possibly think it is stating not to do this. If windows starts reporting memory shortages, performance is going to suffer while memory starts being "trimmed" to account for it.

    BOL has some issues in some articles. If that page is saying you don't need to set the maximum memory allocated or SQL Server; it is one that has an issue ;-)
    04/27/11 @ 06:18

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)