Microsoft SQL Server performs dynamic memory management based on the memory requirements of the current load and activities on the system. On a Windows Server 2003 or a Windows XP or later version system, SQL Server can use the memory notification mechanisms that are provided by the QueryMemoryResourceNotification Windows API. On a Microsoft Windows 2000 Server-based system, SQL Server periodically calculates the free physical memory on the system by using the native Windows API. Based on this information from the QueryMemoryResourceNotification Windows API or from the memory calculation, SQL Server responds to the current memory situation on a specific system. This provides the following benefits:
- The system does not page out the working set of the SQL Server process.
- The necessary database pages are available in memory to reduce physical I/O needs.
For more information, see the "Dynamic memory management" topic and the "Server memory options" topic in SQL Server Books Online.
In 64-bit editions of SQL Server, various problems may occur. For example, the following problems may occur:
- The performance of SQL Server decreases suddenly.
- A computer that is running SQL Server stops responding for a short time.
- A time-out occurs for applications that connect to SQL Server.
- Problems occur when you run even simple commands or use applications on the system.
If you installed SQL Server 2005 Service Pack 2 (SP2) or a later version, one of the following error messages is logged in the SQL Server error log when these problems occur:
Error message 1
date time spid1s A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 1086400, committed (KB): 2160928, memory utilization: 50%.
Error message 2
date time spid1s A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 315 seconds. Working set (KB): 410156, committed (KB): 2201296, memory utilization: 18%.
Error message 3
date time spid1s A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 646 seconds. Working set (KB): 901904, committed (KB): 2215752, memory utilization: 40%.
The Microsoft SQL Server support team has also observed additional error messages or warnings that are recorded in the SQL Server Error log or in the Windows Event logs. These messages resemble the following:
2009-05-05 15:43:56.01 Server Resource Monitor (0x13c43) Worker 0x0412C1E8 appears to be non-yielding on Node 0. Memory freed: 34152 KB. Approx CPU Used: kernel 171 ms, user 140 ms, Interval: 125093.
2009-05-05 12:54:52.18 Server * *******************************************************************************
2009-05-05 12:54:52.18 Server * BEGIN STACK DUMP:
2009-05-05 12:54:52.18 Server * 05/05/08 12:54:52 spid 0
2009-05-05 12:54:52.18 Server * Non-yielding Resource Monitor
2009-05-05 12:54:52.18 Server * *******************************************************************************
2009-06-10 09:13:53.44 Server * *******************************************************************************
2009-06-10 09:13:53.44 Server * BEGIN STACK DUMP:
2009-06-10 09:13:53.44 Server * 06/10/09 09:13:53 spid 0
2009-06-10 09:13:53.44 Server * Non-yielding IOCP Listener
2009-06-10 09:13:53.44 Server * *******************************************************************************
2009-06-10 09:13:55.85 spid2s LazyWriter: warning, no free buffers found.
2009-07-15 13:27:45.35 spid4s AppDomain xx (SQLCLR.dbo[runtime].xx) is marked for unload due to memory pressure.
2009-07-15 13:27:45.35 spid4s AppDomain xx (SQLCLR.dbo[runtime].xx) unloaded.
2009-07-15 13:37:51.42 Logon Error: 17189, Severity: 16, State: 1.
2009-07-15 13:37:51.42 Logon SQL Server failed with error code 0xc0000000 to spawn a thread to process a new login or connection. Check the SQL Server error log and the Windows event logs for information about possible related problems. [CLIENT: xx.xxx.xx.xx]
Event Type: Error
Event Source: SQLBrowser
Event ID: 8
Description: The SQLBrowser service was unable to process a client request.
These additional error messages or warnings may appear together with the "A significant part of sql server process memory has been paged out" error message. In several instances, these additional error messages or warnings did not appear together with the error message.
If you notice one of these error messages or warnings, consider the SQL Server working set paging that is discussed in this article as one possible cause but not as the only cause. These additional error messages or warnings could be logged because of various other conditions or causes.
This problem occurs because the Windows operating system pages out the working set of the SQL Server process.
These error messages are logged when the working set of a SQL Server process reaches 50 percent or less of the memory that is committed to the SQL Server process. You can use these error messages to determine the case in which SQL Server performance decreases significantly because the Windows operating system pages out the working set of the SQL Server process. Additionally, these error messages are logged every five minutes during the first 30 minutes. After the first 30 minutes, the frequency of these error messages doubles until the frequency reaches the maximum of one day.
When this problem occurs, you may notice that the working set of other applications on the system is also paged out around the same time.
For more information, visit the following Microsoft Web site:
Additionally, a known problem exists in SQL Server in which you may receive an instance of this error message. The error message is logged in the SQL Server Error log during the startup process of SQL Server. The error message might be a false warning. Therefore, it might not indicate that working set trim has actually occurred. For more information, visit the following Microsoft website:
Before you try to work around this problem, perform the steps in the "How to troubleshoot this problem" section to resolve this problem.
If you still experience this problem, you can prevent the Windows operating system from paging out the buffer pool memory of the SQL Server process by locking the memory that is allocated for the buffer pool in physical memory. You lock the memory by assigning the
Lock pages in memory user right to the user account that is used as the startup account of the SQL Server service.
Note For 64-bit editions of SQL Server, only SQL Server Enterprise Edition can use the
Lock pages in memory user right. This is applicable for SQL Server 2005 [RTM, SP1, SP2, SP3] and for SQL Server 2008 [RTM and SP1]. SQL Server 2008 SP1 Cumulative Update 2 and SQL Server 2005 SP3 Cumulative Update 4 introduce support for SQL Server Standard editions to use the
Lock pages in memory user right. For more information about support for locked pages on 64 bit systems, click the following article number to view the article in the Microsoft Knowledge Base:
970070
(http://support.microsoft.com/kb/970070/ )
Support for Locked Pages on SQL Server 2005 Standard Edition 64-bit systems and on SQL Server 2008 Standard Edition 64-bit systems
To assign the
Lock pages in memory user right, follow these steps:
- Click Start, click Run, type gpedit.msc, and then click OK.
Note The Group Policy dialog box appears.
- Expand Computer Configuration, and then expand Windows Settings.
- Expand Security Settings, and then expand Local Policies.
- Click User Rights Assignment, and then double-click Lock pages in memory.
- In the Local Security Policy Setting dialog box, click Add User or Group.
- In the Select Users or Groups dialog box, add the account that has permission to run the Sqlservr.exe file, and then click OK.
- Close the Group Policy dialog box.
- Restart the SQL Server service.
After you assign the
Lock pages in memory user right and you restart the SQL Server service, the Windows operating system no longer pages out the buffer pool memory within the SQL Server process. However, the Windows operating system can still page out the nonbuffer pool memory within the SQL Server process.
You can validate that the user right is used by the instance of SQL Server by making sure that the following message is written in the SQL Server Error Log at startup:
Using locked pages for buffer pool
This message applies only to 64-bit editions of SQL Server. For more information about this message in the ERRORLOG, visit the following Microsoft Web site:
When the Windows operating system pages out the nonbuffer pool memory, you may still encounter performance issues. However, the error messages that are mentioned in the "Symptoms" section are not logged in the SQL Server error log. This behavior occurs because the working set of a SQL Server process typically does not reach 50 percent or less of the committed memory.
How to troubleshoot this problem
To troubleshoot this problem, follow these steps:
- To resolve the known issues that cause the Windows operating system to page out the working set of the SQL Server process, apply the hotfixes that are described in the following Microsoft Knowledge Base articles.
Note Hotfixes are cumulative. A later version of a hotfix contains the earlier versions of that hotfix.
- Microsoft has found an issue that may cause the 64-bit edition of the SQL Server working set to be trimmed. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
905865
(http://support.microsoft.com/kb/905865/ )
The sizes of the working sets of all the processes in a console session may be trimmed when you use Terminal Services to log on to or log off from a computer that is running Windows Server 2003
- Computers that are running Windows Server 2003 can be too aggressive when they cache dirty buffers if there is an application performing buffered I/O, such as a file copy operation. This behavior can cause the working set in SQL Server to be trimmed. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
920739
(http://support.microsoft.com/kb/920739/ )
You may experience a decrease in overall system performance when you are copying files that are larger than approximately 500 MB in Windows Server 2003 S or in Windows Server 2003 S
- The SQL Server working set may be trimmed when the system is using some advanced TCP features. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
942861
(http://support.microsoft.com/kb/942861/ )
Error message when an application connects to SQL Server on a server that is running Windows Server 2003: "General Network error," "Communication link failure," or "A transport-level error"
- On a multiprocessor computer that is running Windows Server 2003, the System process may consume most of the available system memory. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
942486
(http://support.microsoft.com/kb/942486/ )
The System process may consume most of the available system memory on a multiprocessor computer that is running Windows Server 2003
- If a device driver uses the MmAllocateContiguousMemory function, and if it sets the value of the HighestAcceptableAddress parameter to less than 4 gigabytes (GB), the Windows operating system may page out the working set of the 64-bit SQL Server process. To resolve this problem, contact the vendor of the device driver for driver updates. For a list of drivers that have encountered problems, see the "other vendors" section in the following Microsoft Knowledge Base article:
2121098
(http://support.microsoft.com/default.aspx?scid=kb;en-US;2121098)
Recommended Operation System updates and drivers for SQL Server installations
- If you still encounter these problems after you apply these hotfixes, apply a Windows hotfix that limits the number of trim operations per process. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
938486
(http://support.microsoft.com/kb/938486/ )
A Windows Server 2003-based computer becomes unresponsive because of a memory manager trimming operation that is caused by an indeterminate module that requests lots of memory
956341
(http://support.microsoft.com/kb/956341/ )
A Windows Server 2003-based computer becomes unresponsive because of a large memory allocation request
When a device driver tries to allocate memory, the Windows operating system may page out the working set of other applications. This Windows hotfix lets you use event tracing to find the device driver that causes problem. To find more information about the specific driver that causes the working set trimming behavior, see the MSDN article "Identifying Drivers That Allocate Contiguous Memory
(http://msdn.microsoft.com/en-us/library/ff190924(VS.85).aspx)
."
- Applications may use the system cache too much, and may cause a large growth of the system cache. To respond to the growth of the system cache, the system pages out the working set of the SQL Server process or of other applications. If you experience this problem, you can use some memory management functions in the application. These functions control the system cache space that file I/O operations can use in the application. For example, you can use the SetSystemFileCacheSize function and the GetSystemFileCacheSize function to control the system cache space that file I/O operations can use.
You can use the Memory performance object to view the values of various counters in this object to determine whether the system cache working set uses too much memory. For example, you can view the Cache Bytes and System Cache Resident Bytes counters. For more information about this topic, visit the following Microsoft Web sites:
You can download and deploy the "Microsoft Windows Dynamic Cache Service" to control the memory that is consumed by the system cache.
- If SQL Server is running together with SAP R/3, you may experience a paging issue. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
931308
(http://support.microsoft.com/kb/931308/ )
You may experience increased paging to the hard disk when you run an SAP R/3 program on a Windows Server 2003-based computer
- If you are running SQL Server on Windows Server 2008, you must apply fixes for known issues that can lead to working set trimming or unnecessary excessive memory consumption by other operating system components. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
971442
(http://support.microsoft.com/kb/971442/ )
The system performance of the server becomes severely decreased when you try to copy files from a server that is running Windows Vista or Windows Server 2008 through a network
974609
(http://support.microsoft.com/kb/974609/ )
A computer that is running Windows Server 2008 randomly stops responding when you run a large application
971714
(http://support.microsoft.com/kb/971714/ )
The report generation process may stop responding when you run Perfmon.exe with the Active Directory Diagnostics template to generate a report on a Windows Server 2008-based domain controller
- If you are running SQL Server on Windows Serve 2008 R2, you must apply fixes for known issues that can lead to working set trimming. For more information, click the following article numbers to view the article in the Microsoft Knowledge Base:
979149
(http://support.microsoft.com/kb/979149/ )
A computer that is running Windows 7 or Windows Server 2008 R2 becomes unresponsive when you run a large application
2155311
(http://support.microsoft.com/kb/2155311/ )
Poor performance occurs on a computer that has NUMA-based processors and that is running Windows Server 2008 R2 or Windows 7 if a thread requests lots of memory that is within the first 4 GB of memory
2468345
(http://support.microsoft.com/kb/2468345/ )
Computer intermittently performs poorly or stops responding when the Storport driver is used in Windows Server 2008 R2
How to determine the memory that is used by 64-bit editions of SQL Server
You can use Performance Monitor to view the memory page that is used by 64-bit editions of SQL Server. To do this, monitor the following performance counter:
Performance object: Memory
Counter: Pages/Sec
For more information about how to use this counter to determine the memory page, click the following article number to view the article in the Microsoft Knowledge Base:
889654
(http://support.microsoft.com/kb/889654/ )
How to determine the appropriate page file size for 64-bit versions of Windows Server 2003 or Windows XP
Additionally, you can measure the effect of paging on 64-bit editions of SQL Server by monitoring the following performance counters:
Performance object: Process
Counter: Private Bytes
Instance: sqlservr
Performance object: Process
Counter: Working Set
Instance: sqlservr
The Private Bytes counter measures the memory that is currently committed. The Working Set counter measures the physical memory that is currently occupied by the process. 64-bit editions of SQL Server also use the following performance counter to expose the memory that the buffer pool allocates:
Performance object: SQL Server:Memory Manager
Counter: Total Server Memory(KB)
Note If the instance of the 64-bit edition of SQL Server is a named instance, the name of the performance object is as follows:
MSSQL$InstanceName: Memory Manager
If the value of the Working Set counter is less than the value of the Total Server Memory(KB) counter, at least some memory that is a part of the buffer pool was trimmed from the SQL Server working set.
After you assign the
Lock pages in memory user right and you restart the SQL Server service, the buffer pool of the SQL Server process still responds to memory resource notification events, and it dynamically increases or decreases in response to these events. However, you cannot see memory allocations for the buffer pool that are locked in memory in the following performance counters:
- The Private Bytes counter and the Working Set counter in Performance Monitor
- The Mem Usage column on the Processes tab in Task Manager
After these pages are locked, these performance counters represent the memory allocations inside the SQL Server process when those allocations do not use the buffer pool. The Total Server Memory(KB) counter of the SQL Server:Memory Manager performance object accurately represents the memory that is allocated for the buffer pool.
Important considerations before you assign the "Lock pages in memory" user right for an instance of a 64-bit edition of SQL Server
You should make additional considerations before you assign the
Lock pages in memory user right. If you assign this user right on systems that are configured incorrectly, the system may become unstable or experience a performance decrease of the whole system. Additionally, event ID 333 may be logged in the event log.
If you contact Microsoft Customer Support Service (CSS) for these problems, CSS engineers may ask you to revoke this user right for the user account that is used as the startup account of the SQL Server service. This step may be necessary to collect important performance data that CSS engineers can use for necessary configuration of the various options for SQL Server and for other applications that are running on the system. After CSS engineers collect the performance data, you can assign the
Lock pages in memory user right to the startup account of the SQL Server service.
Before you assign the
Lock pages in memory user right, make sure that you capture a Performance Monitor log to determine the memory requirements of various applications and services that are installed on the system. These applications also include SQL Server . To determine the memory requirements, collect the following baseline information:
- Make sure that you set the max server memory option and the min server memory option correctly. These options reflect only the memory requirement of the buffer pool of the SQL Server process. These options do not include the memory that is allocated for other components within the SQL Server process. These components include the following:
- The SQL Server worker threads
- The Multipage Allocator of SQL Server Memory Manager
- Various DLLs and components that the SQL Server process loads within the address space of the SQL Server process
- The backup and restore operations
- The DLLs and components include various OLE DB providers, extended stored procedures, Microsoft COM objects that are used for the sp_OACreate stored procedure, linked servers, and SQL Server CLR. Memory that is allocated for these components falls under the nonbuffer pool region of the address space of the SQL Server process. To ideally determine the maximum amount of memory that the whole SQL Server process can use, you must subtract the memory that is allocated for components that do not use the buffer pool from the total memory that you want the SQL Server process to use. Then, you can use the remainder value to set the max server memory option. Before you set the max server memory option and the min server memory option, you should carefully review the "Setting the memory options manually" topic in SQL Server Books Online.
- Determine the memory requirement of other applications and of the Windows operating system components. Applications may include other SQL Server components, for example, SQL Server Agent, SQL Server Replication Agents, SQL Server Reporting Services, SQL Server Analysis Services, SQL Server Integration Services, and SQL Server Full Text Search. Applications that perform backup operations and file copy operations may use lots of memory. Consider operations such as bulk copy and the Snapshot Agent that generate file IO. You must consider the memory requirement of all these applications when you determine the value of the max server memory option and of the min server memory option. You can use the Private Bytes counter and the Working Set counter under the Process object for every process to determine the memory requirement for a specific process.
- By default, the Lock pages in memory user right has already been assigned to the built-in Local System account. For more information, visit the following Microsoft Web site:
- If you use a Windows user account globally for all SQL Server processes in a domain, determine the user rights that are assigned by using a Group Policy configuration. A 32-bit SQL Server process may use this account as the startup account. However, this account requires the Lock pages in memory user right to enable the Address Windowing Extensions (AWE) feature. For more information, see the "Providing the maximum amount of memory to SQL Server" topic in SQL Server Books Online.
- Before you configure the max server memory option and the min server memory option for multiple SQL Server instances, consider the memory requirements of the nonbuffer pool for each instance of SQL Server. Then, configure these options for each instance of SQL Server.
Ideally, you collect this baseline information during peak loads. Therefore, you can determine the memory requirements for various applications and components to support the peak load. The memory requirements vary from one system to another system, depending on the activities and the applications that are running on the system.
How to use the information from SQL Server ring buffers to determine the memory conditions when paging occurs
You can use information from SQL Server ring buffers to determine the memory conditions on the server when paging occurs. You can use a script such as the following script to obtain this information.
SELECT CONVERT (varchar(30), GETDATE(), 121) as runtime,
DATEADD (ms, -1 * (sys.ms_ticks - a.[Record Time]), GETDATE()) AS Notification_time,
a.* , sys.ms_ticks AS [Current Time]
FROM
(SELECT x.value('(//Record/ResourceMonitor/Notification)[1]', 'varchar(30)') AS [Notification_type],
x.value('(//Record/MemoryRecord/MemoryUtilization)[1]', 'bigint') AS [MemoryUtilization %],
x.value('(//Record/MemoryRecord/TotalPhysicalMemory)[1]', 'bigint') AS [TotalPhysicalMemory_KB],
x.value('(//Record/MemoryRecord/AvailablePhysicalMemory)[1]', 'bigint') AS [AvailablePhysicalMemory_KB],
x.value('(//Record/MemoryRecord/TotalPageFile)[1]', 'bigint') AS [TotalPageFile_KB],
x.value('(//Record/MemoryRecord/AvailablePageFile)[1]', 'bigint') AS [AvailablePageFile_KB],
x.value('(//Record/MemoryRecord/TotalVirtualAddressSpace)[1]', 'bigint') AS [TotalVirtualAddressSpace_KB],
x.value('(//Record/MemoryRecord/AvailableVirtualAddressSpace)[1]', 'bigint') AS [AvailableVirtualAddressSpace_KB],
x.value('(//Record/MemoryNode/@id)[1]', 'bigint') AS [Node Id],
x.value('(//Record/MemoryNode/ReservedMemory)[1]', 'bigint') AS [SQL_ReservedMemory_KB],
x.value('(//Record/MemoryNode/CommittedMemory)[1]', 'bigint') AS [SQL_CommittedMemory_KB],
x.value('(//Record/@id)[1]', 'bigint') AS [Record Id],
x.value('(//Record/@type)[1]', 'varchar(30)') AS [Type],
x.value('(//Record/ResourceMonitor/Indicators)[1]', 'bigint') AS [Indicators],
x.value('(//Record/@time)[1]', 'bigint') AS [Record Time]
FROM (SELECT CAST (record as xml) FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR') AS R(x)) a
CROSS JOIN sys.dm_os_sys_info sys
ORDER BY a.[Record Time] ASC
Note This query is valid for both SQL Server 2005, and SQL Server 2008.
You can query the information that is provided in the dynamic management view sys.dm_os_process_memory to understand whether the system is encountering low memory conditions. For more information, see the SQL Server 2008 Books Online reference at the following MSDN Web site:
SQL Server 2008 R2 BPA information
The SQL Server 2008 R2 Best Practice Analyzer (SQL Server 2008 R2 BPA) provides multiple rules to detect situations that can result in working set trimming of SQL Server process. The SQL Server 2008 R2 BPA supports SQL Server 2008 and SQL Server 2008 R2.
If you run the BPA tool and receive the warning, "Database Engine - SQL Server memory settings are incorrect," you need to check the max server memory setting for this instance of SQL Server and follow the recommendations in the section “Important considerations before you assign the 'Lock pages in memory' user right for an instance of a 64-bit edition of SQL Server” of this article.
If you run the BPA tool and experience the error, "Database Engine - Operating system files and drivers needs update for working set trimming," you need to review all the fixes discussed in the "Resolution" section of this article and apply them.
If you run the BPA tool and experience the error "Database Engine - Significant portion of SQL Server memory has been paged out," you need to review the "Resolution" and "Workaround" sections of this article and take appropriate action.
References
Collapse this tableExpand this table
| Rule software | Rule title | Rule identifier |
| SQL Server 2008 R2 BPA Rule | SQL Server memory settings are incorrect | RID3804 |
| SQL Server 2008 R2 BPA Rule | Operating system files and drivers needs update for working set trimming | RID0059 |
| SQL Server 2008 R2 BPA Rule | Significant portion of SQL Server memory has been paged out | RID0049 |
Improvements in Windows Server 2008 and in Windows Server 2008 R2
Windows Server 2008 and Windows Server 2008 R2 improve the contiguous memory allocation mechanism. This improvement lets Windows Server 2008 and Windows Server 2008 R2 reduce to a certain extent the effects of paging out the working set of applications when new memory requests arrive.
The following is an explanation of the improvements from the Microsoft whitepaper "Advances in Memory Management in Windows":
In Windows Server 2008, the allocation of physically contiguous memory is greatly enhanced. Requests to allocate contiguous memory are much more likely to succeed because the memory manager now dynamically replaces pages, typically without trimming the working set or performing I/O operations. In addition, many more types of pages—such as kernel stacks and file system metadata pages, among others—are now candidates for replacement. Consequently, more contiguous memory is generally available at any given time. In addition, the cost to obtain such allocations is greatly reduced.
To view the "Advances in Memory Management in Windows" whitepaper, visit the following Microsoft Website:
For more information, visit the following Microsoft websites:
Note On a Windows Server 2008-based computer, you must install SQL Server Service Pack 2 (SP2) or a later SQL Server service pack.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
