Understanding the Importance of Memory Setting in SQL Server

Memory is one among the resources forming the performance triangle—CPU and storage being the other two. If one is hit, the other two take the load to try to bring the performance to acceptable levels, but there’s always the trade-off. Whatever transactions cannot be committed to the memory they would be forwarded to the disk subsystem by SQL Server. This causes a performance bottleneck. Therefore, the wait statistics can help identify performance issues on a SQL Server.

In this article, the following topics are discussed:

  1. Understanding internals of SQL Server memory setting and configuration
  2. The SQL Server memory and its impact on the database and application performance
  3. Discuss various SQL Server components that contribute to the memory usage
  4. Best practices and recommendation for memory sizing
  5. Multi-server memory report
  6. And more…

Memory management internals

SQL Server has a Memory Management Unit that performs automated dynamic memory management based on the workload of the system. This memory is the volatile space that’s critical to today’s Business – Tech needs, the right-sizing of which is vital to the optimal performance of the applications.

However, we all know that when setting up the server, the sizing contains some default values. in some cases, we soon find out that SQL Server uses almost all of the memory on the server, even though there’s no visible activity on the databases, bringing in the questions: Are the default values incorrect? If so, what should be the right size?

Memory Management on SQL Server works on the Fill-and-Flush algorithm. The default values do not restrict the memory consumption from growing unless there’s a request from the Operating System.

The sizing depends on various components of the system—in many cases, setting it between 70% and 80% is a good starting point. Then, you should also monitor it to see what else you may be missing and if you should tweak the setting. If you have other services on the SQL Server (you really shouldn’t), you may need to leave behind more, especially if these services are memory hogs. Consider revisiting the memory setting of the SQL instance in any of the following scenarios:

  • Unresponsiveness of the Operating System
  • Application exhaustion
  • Backup operations that require large memory buffers
  • In-Memory Optimized objects
  • Column store indexes, since they require large volumes of memory to perform index maintenances.

The memory setting on SQL Server is pretty straightforward. You can change the value using sp_configure or SSMS GUI. This is an online option but remember that setting or resetting these values may cause some of the internal cache objects to reshuffle, which will leave the system running slightly slower.

sp_configure ‘max server memory (MB)’,<Memory in MB>

In this case, the number “2147483647” means that SQL Server has no upper limit and will use all the memory on the server.

Min server memory: min server memory as a floor value; SQL Server will commit memory for its own use until it reaches the min server memory setting. After that, it will maintain at least this amount of usable memory.

Max server memory: In the same way that min server memory provides a floor, max server memory provides a ceiling.

The min and max memory levels are the lower and upper limit of the amount of memory allowed for use by the buffer pool. The buffer pool is the largest chunk of memory consumed by SQL Server. The following are the SQL Server components within the SQL instance that use memory from the buffer pool

  • Database Page Cache
  • Internal log caches
  • Procedure cache or query plan cache
  • Query Workload space
  • Locks (Memory grants)
  • Connection context
  • Optimizing queries
  • System-level data structures

The values of the important metrics such as Available Mbytes, Pages/Sec, Buffer Cache Hit Ratio, PLE, etc. determine the SQL Server performance.

Buffer Cache Hit Ratio is specific to each application. 90% is usually considered desirable. It means that over 90% of the requests were served by the cache, which is a good thing. If the value is lower, add more memory until it is consistently higher than 90%.

Available Bytes is nothing but an indication of how much memory is available for use. The Pages/sec counter shows how many pages were retrieved from the disk, or written to the disk, both due to hard page faults.

PLE stands for Page Life Expectancy, which is an indication of how many seconds the page will stay in the pool for.

For example,

Recommendations and best practices

Let us now briefly look at the techniques to size the memory.

  1. 1 GB of memory reserved for Operating System
  2. 1 GB each for every 4 GB of RAM after the initial 4 GB, up to 16 GB of RAM
  3. 1 GB each for every 8 GB in more than 16 GB of RAM

For example, if you have a 32 GB RAM Database Server, then memory to be given to Operating System would be

  1. 1 GB, the minimum allocation
  2. + 3 GB, since 16 GB – 4 GB = 12 GB; 12 GB divided by 4 GB (each 4 GB gets 1 GB) is 3GB.
  3. + 2 GB, as 32 GB – 16 GB = 16 GB; 16 divided by 8 (each 8 GB after 16 GB gets 1 GB) is 2 GB

So, in total, for a server with 32 GB of RAM, 7 GB will be reserved for the Operating System. This is the maximum memory allocated to SQL Server should be 25 GB. Similarly, for a 64 GB Server, 10 GB should be reserved for the Operating System & 54 GB should be allocated for SQL Server.

We’ve all, at some point or the other, heard of or used Windows Management Instrumentation (WMI). There are several classes in WMI, which allow us to extract information about the hardware, installed software, the operating system, or even the registry. We can even modify settings and perform actions on these aspects.

The win32_OperatingSystem class is a WMI class that has all the necessary information about the active operating system (in case you are, say, dual booting). This class can also be used to get the amount of memory allocated to the operating system. Here are some of the objects the class can return, which could be of help to us (memory is measured in kilobytes by this class):

  • TotalVisibleMemorySize: This field shows the total physical memory that is accessible to the operating system. Inaccessible chunks of memory may cause a smaller-than-installed number to be displayed here.
  • FreePhysicalMemory: This tells us what amount of physical memory is free.
  • TotalVirtualMemorySize: This is the total virtual memory available for the OS to use. This comprises the physical memory installed on the computer, along with the size of the pagefile.
  • FreeVirtualMemory: Similar to FreePhysicalMemory, but includes the free space in the paging memory as well.

We can fetch the page file information using the Win32_PageFileSetting WMI class.

The following query gives the high-level memory usage details of the SQL instance.

Prepare the script

Let’s integrate the aforementioned three outputs into a single memory output:

  1. SQL Internal Memory structures using Counter
  2. Available virtual and physical memory using WMI object
  3. Page file setting using WMI

The HTML content preparation is all about filling in the value fed from the different section of the script, between the right tags.

The script can build the valid HTML tags. The following are the functions used in the script.

  1. writeHTMLHeader: this function is used to generate the Header and define the style for the HTML file.
  2. writetableFooter: this defines the closing HTML tags.
  3. writeTableHeader: this defines the thirteen-columned output heading for the HTML file
  4. writeMemoryInfo: this is the function that carries out the merging of the two WMI class outputs. The output of Win32_PageFileSetting, Win32_OperatingSystem and SMO SQL is passed as arguments for this function. The values can also be further transformed or manipulated in this section.
  5. Email section


Wrapping Up

Now that you’ve learned some new things about SQL Server memory management, you’ll better understand SQL Server resources.

If there’s adequate RAM on the server, the data pages can have a longer life in the buffer pool which consequently results in a drastic reduction in the I/O needs.

While in most cases Database Administrators rely on default memory settings, we need to understand that the internals of memory requirements depend on the workload of the instance.

This article is a high-level walkthrough of SQL Server memory and its internals.  Also, it covers the various reasons behind the performance bottlenecks caused by not setting the max memory.

I’ve included step-by-step instructions to set up and configure a memory report. The steps on how to set the SQL memory are also included. Further, we discussed various SQL components that contribute to the use of the available memory on the SQL Server environment.

One point to remember is that allocation and de-allocation of memory slow down startup. Therefore, if you have several applications stopping and starting on the same server, it may affect the performance. Similarly, if there are several other applications running on the same server, setting the min server memory and max server memory becomes more important to ensure optimal performance.

That’s all for now…


  1. How much memory does my SQL Server actually need?
  2. Monitoring Memory Usage
  3. Importance of setting Max Server Memory in SQL Server and How to Set it
  4. Server Memory Server Configuration Options
Prashanth Jayaram

Prashanth Jayaram

Prashanth Jayaram is working as a DB Manager for a leading MNC, Database Technologist, Author, Blogger, Automation Expert, Technet WIKI Ninja, and Powershell Geek.
Prashanth Jayaram

Prashanth Jayaram

Prashanth Jayaram is working as a DB Manager for a leading MNC, Database Technologist, Author, Blogger, Automation Expert, Technet WIKI Ninja, and Powershell Geek.