메모리 관리 아키텍처 가이드Memory Management Architecture Guide

이 항목 적용 대상: 예SQL Server예Azure SQL 데이터베이스예Azure SQL 데이터 웨어하우스 예 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServeryesAzure SQL DatabaseyesAzure SQL Data Warehouse yesParallel Data Warehouse

Windows 가상 메모리 관리자Windows Virtual Memory Manager

주소 공간의 커밋된 영역은 Windows 가상 메모리 관리자(VMM)에 의해 사용할 수 있는 실제 메모리에 매핑됩니다.The committed regions of address space are mapped to the available physical memory by the Windows Virtual Memory Manager (VMM).

운영 체제별 지원되는 실제 메모리의 양에 대한 자세한 내용은 Windows 설명서 Windows 릴리스별 메모리 제한(Memory Limits for Windows Releases)을 참조하세요.For more information on the amount of physical memory supported by different operating systems, see the Windows documentation on Memory Limits for Windows Releases.

가상 메모리 체계를 사용하면 실제 메모리가 과다 커밋되어 가상 메모리와 실제 메모리의 비율이 1:1을 초과할 수 있습니다.Virtual memory systems allow the over-commitment of physical memory, so that the ratio of virtual-to-physical memory can exceed 1:1. 그 결과 실제 메모리가 다양하게 구성된 컴퓨터에서 대용량 프로그램을 실행할 수 있습니다.As a result, larger programs can run on computers with a variety of physical memory configurations. 그러나 모든 프로세스의 현재 평균 설정을 합한 값보다 너무 많은 가상 메모리를 사용하면 성능이 떨어질 수 있습니다.However, using significantly more virtual memory than the combined average working sets of all the processes can cause poor performance.

SQL ServerSQL Server 메모리 아키텍처 Memory Architecture

SQL ServerSQL Server 에서는 메모리를 필요에 따라 동적으로 확보하고 해제합니다. dynamically acquires and frees memory as required. 일반적으로 관리자는 SQL ServerSQL Server에 할당해야 하는 메모리의 양을 지정할 필요가 없습니다. 해당 옵션이 계속 유지되고 일부 환경에서는 필요할 경우에도 마찬가지입니다.Typically, an administrator does not have to specify how much memory should be allocated to SQL ServerSQL Server, although the option still exists and is required in some environments.

디스크 읽기 및 쓰기가 리소스를 가장 많이 소모하는 작업이기 때문에 모든 데이터베이스 소프트웨어의 주요 설계 목표 중 하나는 디스크 입/출력을 최소화하는 것입니다.One of the primary design goals of all database software is to minimize disk I/O because disk reads and writes are among the most resource-intensive operations. SQL ServerSQL Server 는 데이터베이스에서 읽은 페이지를 보관하도록 메모리에 버퍼 풀을 만듭니다. builds a buffer pool in memory to hold pages read from the database. SQL ServerSQL Server 코드 중 상당수가 디스크와 버퍼 풀 간의 물리적 읽기 횟수와 쓰기 횟수를 최소화하는 데 사용됩니다.Much of the code in SQL ServerSQL Server is dedicated to minimizing the number of physical reads and writes between the disk and the buffer pool. SQL ServerSQL Server 는 다음 두 가지 목표를 균형 있게 유지하려고 합니다. tries to reach a balance between two goals:

  • 전체 시스템의 메모리가 부족해지지 않도록 적정한 수준의 버퍼 풀 크기 유지Keep the buffer pool from becoming so big that the entire system is low on memory.
  • 버퍼 풀의 크기를 최대화하여 데이터베이스 파일에 대한 실제 입출력 최소화Minimize physical I/O to the database files by maximizing the size of the buffer pool.

참고

사용량이 많은 시스템에서는 많은 메모리가 필요한 일부 대규모 쿼리를 실행하는 경우 요청한 최소 메모리 용량을 얻지 못하고 메모리 리소스를 대기하는 동안 시간 초과 오류가 발생하게 됩니다.In a heavily loaded system, some large queries that require a large amount of memory to run cannot get the minimum amount of requested memory and receive a time-out error while waiting for memory resources. 이 문제를 해결하려면 query wait 옵션을 늘립니다.To resolve this, increase the query wait Option. 병렬 쿼리의 경우 max degree of parallelism 옵션을 줄여 보세요.For a parallel query, consider reducing the max degree of parallelism Option.

참고

사용량이 많고 메모리가 부족한 시스템에서는 쿼리가 비트맵에 필요한 최소 메모리를 얻지 못할 경우 쿼리 계획에 병합 조인, 정렬 및 비트맵이 포함된 쿼리에서 비트맵을 삭제할 수 있습니다.In a heavily loaded system under memory pressure, queries with merge join, sort and bitmap in the query plan can drop the bitmap when the queries do not get the minimum required memory for the bitmap. 이 경우 쿼리 성능에 영향을 줄 수 있으며 정렬 프로세스가 메모리에 들어가지 않을 경우 tempdb 데이터베이스의 작업 테이블 사용이 증가하여 tempdb가 확장될 수 있습니다.This can affect the query performance and if the sorting process can not fit in memory, it can increase the usage of worktables in tempdb database, causing tempdb to grow. 이 문제를 해결하려면 실제 메모리를 추가하거나 더 빠른 다른 쿼리 계획을 사용하도록 쿼리를 튜닝합니다.To resolve this problem add physical memory or tune the queries to use a different and faster query plan.

SQL ServerSQL Server에 최대 메모리 양 제공Providing the maximum amount of memory to SQL ServerSQL Server

AWE와 Lock Pages in Memory 권한을 사용하면 SQL ServerSQL Server 데이터베이스 엔진에 다음과 같이 메모리 양을 제공할 수 있습니다.By using AWE and the Locked Pages in Memory privilege, you can provide the following amounts of memory to the SQL ServerSQL Server Database Engine.

참고

다음 표에는 더 이상 사용할 수 없는 32비트 버전의 열이 나와 있습니다.The following table includes a column for 32-bit versions, which are no longer available.

32비트 132-bit 1 64비트64-bit
기본 메모리Conventional memory 모든 SQL ServerSQL Server 버전All SQL ServerSQL Server editions. 프로세스 가상 주소 공간 제한까지 허용됩니다.Up to process virtual address space limit:
- 2GB- 2 GB
- 3 GB /3gb 부팅 매개 변수를 사용하면 3GB 2- 3 GB with /3gb boot parameter 2
- WOW64에서는 4GB 3- 4 GB on WOW64 3
모든 SQL ServerSQL Server 버전All SQL ServerSQL Server editions. 프로세스 가상 주소 공간 제한까지 허용됩니다.Up to process virtual address space limit:
- IA64 아키텍처에서는 7TB(IA64는 SQL Server 2012SQL Server 2012 이상에서 지원되지 않음)- 7 TB with IA64 architecture (IA64 not supported in SQL Server 2012SQL Server 2012 and above)
- 최대 x64 아키텍처의 운영 체제가 지원하는 최대 크기 4- Operating system maximum with x64 architecture 4
AWE 메커니즘( SQL ServerSQL Server 에서 32비트 플랫폼의 프로세스 가상 주소 공간 제한을 초과할 수 있도록 허용)AWE mechanism (Allows SQL ServerSQL Server to go beyond the process virtual address space limit on 32-bit platform.) SQL ServerSQL Server Standard, Enterprise 및 개발자 버전: 버퍼 풀에서 최대 64GB의 메모리에 액세스할 수 있습니다. Standard, Enterprise, and Developer editions: Buffer pool is capable of accessing up to 64 GB of memory. 해당 사항 없음 5Not applicable 5
메모리의 페이지 잠금 운영 체제(OS) 권한(실제 메모리 잠금을 허용하여 잠긴 메모리의 OS 페이징 방지) 6Lock pages in memory operating system (OS) privilege (allows locking physical memory, preventing OS paging of the locked memory.) 6 SQL ServerSQL Server Standard, Enterprise 및 개발자 버전: SQL ServerSQL Server 프로세스에서 AWE 메커니즘을 사용하려면 필요합니다. Standard, Enterprise, and Developer editions: Required for SQL ServerSQL Server process to use AWE mechanism. AWE 메커니즘을 통해 할당된 메모리는 페이징할 수 없습니다.Memory allocated through AWE mechanism cannot be paged out.
AWE를 사용하지 않고 이 권한을 부여하면 서버에 영향을 주지 않습니다.Granting this privilege without enabling AWE has no effect on the server.
필요한 경우, 즉 sqlservr 프로세스가 페이징 아웃되고 있다는 징후가 있는 경우에만 사용됩니다. 이 경우 오류 17890이 다음 예제와 유사한 Errorlog에 보고됩니다.A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.Only used when necessary, namely if there are signs that sqlservr process is being paged out. In this case, error 17890 will be reported in the Errorlog, resembling the following example: A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

1 32비트 버전은 SQL Server 2014SQL Server 2014부터 사용할 수 없습니다.1 32-bit versions are not available starting with SQL Server 2014SQL Server 2014.
2 /3gb는 운영 체제 부팅 매개 변수입니다.2 /3gb is an operating system boot parameter. 자세한 내용은 MSDN 라이브러리를 참조하세요.For more information, visit the MSDN Library.
3 WOW64(Windows on Windows 64)는 32비트 SQL ServerSQL Server 가 64비트 운영 체제에서 실행되는 모드입니다.3 WOW64 (Windows on Windows 64) is a mode in which 32-bit SQL ServerSQL Server runs on a 64-bit operating system.
4 SQL ServerSQL Server Standard Edition은 최대 128GB를 지원합니다.4 SQL ServerSQL Server Standard Edition supports up to 128 GB. SQL ServerSQL Server Enterprise Edition은 운영 체제가 지원하는 최대 크기를 지원합니다. Enterprise Edition supports the operating system maximum.
5 sp_configure awe enabled 옵션은 64비트 SQL ServerSQL Server에 있지만 무시됩니다.5 Note that the sp_configure awe enabled option was present on 64-bit SQL ServerSQL Server, but it is ignored.
6 32비트에서 AWE 지원에 대해 또는 64비트에서 단독으로 LPIM(메모리의 페이지 잠금) 권한이 부여된 경우 max server memory도 설정하는 것이 좋습니다.6 If lock pages in memory privilege (LPIM) is granted (either on 32-bit for AWE support or on 64-bit by itself), we recommend also setting max server memory. LPIM에 대한 자세한 내용은 서버 메모리 서버 구성 옵션을 참조하세요.For more information on LPIM, refer to Server Memory Server Configuration Options

참고

이전 버전의 SQL ServerSQL Server 는 32비트 운영 체제에서 실행할 수 있었습니다.Older versions of SQL ServerSQL Server could run on a 32-bit operating system. 32비트 운영 체제에서 4GB가 넘는 메모리에 액세스하려면 AWE(Address Windowing Extension)에서 메모리를 관리해야 합니다.Accessing more than 4 gigabytes (GB) of memory on a 32-bit operating system required Address Windowing Extensions (AWE) to manage the memory. 이는 SQL ServerSQL Server 를 64비트 운영 체제에서 실행할 경우에는 필요하지 않습니다.This is not necessary when SQL ServerSQL Server is running on 64-bit operation systems. AWE에 대한 자세한 내용은 SQL Server 2008SQL Server 2008 설명서에서 프로세스 주소 공간큰 데이터베이스의 메모리 관리를 참조하세요.For more information about AWE, see Process Address Space and Managing Memory for Large Databases in the SQL Server 2008SQL Server 2008 documentation.

SQL Server 2012SQL Server 2012부터 메모리 관리로 변경Changes to Memory Management starting with SQL Server 2012SQL Server 2012

이전 버전의 SQL Server( SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008SQL Server 2008 R2SQL Server 2008 R2)에서는 5가지 메커니즘을 사용하여 메모리 할당이 수행되었습니다.In earlier versions of SQL Server ( SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008 and SQL Server 2008 R2SQL Server 2008 R2), memory allocation was done using five different mechanisms:

  • 단일 페이지 할당자(SPA): SQL ServerSQL Server 프로세스에서 8KB 이하인 메모리 할당만 포함합니다.Single-page Allocator (SPA), including only memory allocations that were less than, or equal to 8-KB in the SQL ServerSQL Server process. max server memory(MB)min server memory(MB) 구성 옵션은 SPA가 사용한 실제 메모리의 한계를 결정했습니다.The max server memory (MB) and min server memory (MB) configuration options determined the limits of physical memory that the SPA consumed. 버퍼 풀은 SPA의 메커니즘이자 동시에 가장 큰 단일 페이지 할당 소비자였습니다.THe buffer pool was simultaneously the mechanism for SPA, and the largest consumer of single-page allocations.
  • 다중 페이지 할당자(MPA): 8KB 이상을 요청하는 메모리 할당입니다.Multi-Page Allocator (MPA), for memory allocations that request more than 8-KB.
  • CLR 할당자: SQL CLR 힙 및 CLR 초기화 중에 생성되는 전역 할당을 포함합니다.CLR Allocator, including the SQL CLR heaps and its global allocations that are created during CLR initialization.
  • SQL ServerSQL Server 프로세스에서 스레드 스택에 대한 메모리 할당.Memory allocations for thread stacks in the SQL ServerSQL Server process.
  • 직접 Windows 할당(DWA): Windows에 직접 요청된 메모리 할당입니다.Direct Windows allocations (DWA), for memory allocation requests made directly to Windows. 여기에는 Windows 힙 사용 및 SQL ServerSQL Server 프로세스로 로드되는 모듈에 의한 직접 가상 할당이 포함됩니다.These include Windows heap usage and direct virtual allocations made by modules that are loaded into the SQL ServerSQL Server process. 이러한 메모리 할당 요청의 예로는 확장 저장 프로시저 DLL의 할당, 자동화 프로시저(sp_OA 호출)를 사용하여 만든 개체 및 연결된 서버 공급자의 할당이 있습니다.Examples of such memory allocation requests include allocations from extended stored procedure DLLs, objects that are created by using Automation procedures (sp_OA calls), and allocations from linked server providers.

SQL Server 2012SQL Server 2012부터 단일 페이지 할당, 다중 페이지 할당 및 CLR 할당은 모두 "임의 크기" 페이지 할당자에 통합되며 max server memory(MB)min server memory(MB) 구성 옵션에 의해 제어되는 메모리 제한에 포함됩니다.Starting with SQL Server 2012SQL Server 2012, Single-lage allocations, Multi-Page allocations and CLR allocations are all consolidated into a "Any size" Page Allocator, and it's included in memory limits that are controlled by max server memory (MB) and min server memory (MB) configuration options. 이 변경으로 인해 SQL ServerSQL Server 메모리 관리자를 통과하는 모든 메모리 요구 사항에 대해 보다 정확한 크기 조정 기능이 제공되었습니다.This change provided a more accurate sizing ability for all memory requirements that go through the SQL ServerSQL Server memory manager.

중요

SQL Server 2012SQL Server 2012에서 SQL Server 2017SQL Server 2017로 업그레이드한 후 현재 max server memory(MB)min server memory(MB) 구성을 주의 깊게 검토합니다.Carefully review your current max server memory (MB) and min server memory (MB) configurations after you upgrade to SQL Server 2012SQL Server 2012 through SQL Server 2017SQL Server 2017. 이는 지금은 포함된 구성과 이전 버전과 비교하여 더 많은 메모리 할당을 위한 계정을 포함하는 SQL Server 2012SQL Server 2012에서 시작하기 때문입니다.This is because starting in SQL Server 2012SQL Server 2012, such configurations now include and account for more memory allocations compared to earlier versions. 이러한 변경 사항은 32비트 및 64비트 버전의 SQL Server 2012SQL Server 2012SQL Server 2014SQL Server 2014 그리고 64비트 버전의 SQL Server 2016SQL Server 2016에서 SQL Server 2017SQL Server 2017에 모두 적용됩니다.These changes apply to both 32-bit and 64-bit versions of SQL Server 2012SQL Server 2012 and SQL Server 2014SQL Server 2014, and 64-bit versions of SQL Server 2016SQL Server 2016 through SQL Server 2017SQL Server 2017.

다음 표는 특정 유형의 메모리 할당이 max server memory(MB)min server memory(MB) 구성 옵션으로 제어되는지 여부를 나타냅니다.The following table indicates whether a specific type of memory allocation is controlled by the max server memory (MB) and min server memory (MB) configuration options:

메모리 할당 유형Type of memory allocation SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008SQL Server 2008 R2SQL Server 2008 R2, SQL Server 2008SQL Server 2008 and SQL Server 2008 R2SQL Server 2008 R2 SQL Server 2012SQL Server 2012로 시작Starting with SQL Server 2012SQL Server 2012
단일 페이지 할당Single-page allocations Yes 예, "임의 크기" 페이지 할당에 통합됨Yes, consolidated into "any size" page allocations
다중 페이지 할당Multi-page allocations 아니요No 예, "임의 크기" 페이지 할당에 통합됨Yes, consolidated into "any size" page allocations
CLR 할당CLR allocations 아니요No Yes
스레드 스택 메모리Thread stacks memory 아니요No 아니요No
Windows에서 직접 할당Direct allocations from Windows 아니요No 아니요No

SQL Server 2012SQL Server 2012부터 SQL ServerSQL Server는 max server memory 설정에 지정된 값보다 많은 메모리를 할당할 수 있습니다.Starting with SQL Server 2012SQL Server 2012, SQL ServerSQL Server might allocate more memory than the value specified in the max server memory setting. 이 동작은 Total Server Memory(KB) 값이 이미 max server memory에 지정된 Target Server Memory(KB) 설정에 도달했을 때 발생할 수 있습니다.This behavior may occur when the Total Server Memory (KB) value has already reached the Target Server Memory (KB) setting (as specified by max server memory). 메모리 조각화로 인해 다중 페이지 메모리 요청(8KB 이상)의 요구를 충족시키기에 연속 여유 메모리가 충분하지 않은 경우 SQL ServerSQL Server은 메모리 요청을 거부하는 대신 과도한 커밋을 수행할 수 있습니다.If there is insufficient contiguous free memory to meet the demand of multi-page memory requests (more than 8 KB) because of memory fragmentation, SQL ServerSQL Server can perform over-commitment instead of rejecting the memory request.

이 할당이 수행되는 즉시 리소스 모니터 백그라운드 작업은 모든 메모리 소비자에게 할당된 메모리를 해제하도록 신호를 보내기 시작하고 Target Server Memory(KB) 사양 이하의 Total Server Memory(KB) 값을 아래에 가져오려 합니다.As soon as this allocation is performed, the Resource Monitor background task starts to signal all memory consumers to release the allocated memory, and tries to bring the Total Server Memory (KB) value below the Target Server Memory (KB) specification. 따라서 SQL ServerSQL Server 메모리 사용량이 최대 서버 메모리 설정을 잠시 초과할 수 있습니다.Therefore, SQL ServerSQL Server memory usage could briefly exceed the max server memory setting. 이 경우 Total Server Memory(KB) 성능 카운터 읽기가 max server memory 및 Target Server Memory(KB) 설정을 초과합니다.In this situation, the Total Server Memory (KB) performance counter reading will exceed the max server memory and Target Server Memory (KB) settings.

이 동작은 일반적으로 다음 작업 중에 관찰됩니다.This behavior is typically observed during the following operations:

  • 대규모 Columnstore 인덱스 쿼리.Large Columnstore index queries.
  • 대용량의 메모리를 사용하여 해시 및 정렬 작업을 수행하는 Columnstore 인덱스 (다시) 빌드.Columnstore index (re)builds, which use large volumes of memory to perform Hash and Sort operations.
  • 대용량 메모리 버퍼가 필요한 백업 작업.Backup operations that require large memory buffers.
  • 큰 입력 매개 변수를 저장해야 하는 추적 작업.Tracing operations that have to store large input parameters.

SQL Server 2012SQL Server 2012부터 "memory_to_reserve"로 변경Changes to "memory_to_reserve" starting with SQL Server 2012SQL Server 2012

이전 버전의 SQL Server( SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008SQL Server 2008 R2SQL Server 2008 R2)에서 SQL ServerSQL Server 메모리 관리자는 Multi-Page Allocator(MPA), CLR 할당자, SQL Server 프로세스에서 스레드 스택에 대한 메모리 할당, Direct Windows 할당(DWA)으로 사용하기 위해 프로세스 가상 주소 공간(VAS)의 일부로 따로 지정했습니다.In earlier versions of SQL Server ( SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008 and SQL Server 2008 R2SQL Server 2008 R2), the SQL ServerSQL Server memory manager set aside a part of the process virtual address space (VAS) for use by the Multi-Page Allocator (MPA), CLR Allocator, memory allocations for thread stacks in the SQL Server process, and Direct Windows allocations (DWA). 가상 주소 공간의 이 부분은 "Mem-To-Leave" 또는 "non-Buffer Pool" 영역으로도 알려져 있습니다.This part of the virtual address space is also known as "Mem-To-Leave" or "non-Buffer Pool" region.

이러한 할당을 위해 예약된 가상 주소 공간은 memory_to_reserve 구성 옵션에 의해 결정됩니다.The virtual address space that is reserved for these allocations is determined by the memory_to_reserve configuration option. SQL ServerSQL Server가 사용하는 기본값은 256MB입니다.The default value that SQL ServerSQL Server uses is 256 MB. 기본값을 재정의하려면 SQL ServerSQL Server -g 시작 매개 변수를 사용합니다.To override the default value, use the SQL ServerSQL Server -g startup parameter. -g 시작 매개 변수에 대한 자세한 내용은 데이터베이스 엔진 서비스 시작 옵션의 설명서 페이지를 참조하세요.Refer to the documentation page on Database Engine Service Startup Options for information on the -g startup parameter.

SQL Server 2012SQL Server 2012부터 새 "임의 크기" 페이지 할당자는 8KB보다 큰 할당을 처리하기 때문에 memory_to_reserve 값은 다중 페이지 할당을 포함하지 않습니다.Because starting with SQL Server 2012SQL Server 2012, the new "any size" page allocator also handles allocations greater than 8 KB, the memory_to_reserve value does not include the multi-page allocations. 이 변경 사항을 제외하고 나머지는 이 구성 옵션과 함께 동일하게 유지됩니다.Except for this change, everything else remains the same with this configuration option.

다음 표는 특정 유형의 메모리 할당이 SQL ServerSQL Server 프로세스의 가상 주소 공간의 memory_to_reserve 영역에 속하는지 여부를 나타냅니다.The following table indicates whether a specific type of memory allocation falls into the memory_to_reserve region of the virtual address space for the SQL ServerSQL Server process:

메모리 할당 유형Type of memory allocation SQL Server 2005SQL Server 2005, SQL Server 2008SQL Server 2008SQL Server 2008 R2SQL Server 2008 R2, SQL Server 2008SQL Server 2008 and SQL Server 2008 R2SQL Server 2008 R2 SQL Server 2012SQL Server 2012로 시작Starting with SQL Server 2012SQL Server 2012
단일 페이지 할당Single-page allocations 아니요No 아니요, "임의 크기" 페이지 할당에 통합됨No, consolidated into "any size" page allocations
다중 페이지 할당Multi-page allocations Yes 아니요, "임의 크기" 페이지 할당에 통합됨No, consolidated into "any size" page allocations
CLR 할당CLR allocations Yes Yes
스레드 스택 메모리Thread stacks memory Yes Yes
Windows에서 직접 할당Direct allocations from Windows Yes Yes

동적 메모리 관리Dynamic Memory Management

SQL ServerSQL Server SQL Server 데이터베이스 엔진SQL Server Database Engine의 기본 메모리 관리 동작은 시스템에 메모리가 부족해지지 않도록 필요한 만큼 메모리를 확보하는 것입니다.The default memory management behavior of the SQL ServerSQL Server SQL Server 데이터베이스 엔진SQL Server Database Engine is to acquire as much memory as it needs without creating a memory shortage on the system. SQL Server 데이터베이스 엔진SQL Server Database Engine은 Microsoft Windows의 메모리 알림 API를 사용하여 이 작업을 수행합니다.The SQL Server 데이터베이스 엔진SQL Server Database Engine does this by using the Memory Notification APIs in Microsoft Windows.

SQL ServerSQL Server 가 동적으로 메모리를 사용하면 주기적으로 시스템을 쿼리하여 사용할 수 있는 메모리 양을 확인합니다.When SQL ServerSQL Server is using memory dynamically, it queries the system periodically to determine the amount of free memory. 사용 가능한 메모리를 이 수준으로 유지 관리하면 OS(운영 체제)에서 페이징을 방지합니다.Maintaining this free memory prevents the operating system (OS) from paging. 사용 가능한 메모리가 이보다 적은 경우 SQL ServerSQL Server 는 메모리를 OS로 해제합니다.If less memory is free, SQL ServerSQL Server releases memory to the OS. 사용 가능한 메모리가 이보다 많은 경우 SQL ServerSQL Server 에서 더 많은 메모리를 할당할 수 있습니다.If more memory is free, SQL ServerSQL Server may allocate more memory. SQL ServerSQL Server 는 작업에 메모리가 더 필요한 경우에만 메모리를 추가합니다. 서버가 유휴 상태이면 가상 주소 공간 크기가 증가하지 않습니다. adds memory only when its workload requires more memory; a server at rest does not increase the size of its virtual address space.

max server memorySQL ServerSQL Server 메모리 할당, 컴파일 메모리, 모든 캐시(버퍼 풀 포함), 쿼리 실행 메모리 부여, 잠금 관리자 메모리 및 CLR1 메모리를 제어합니다(기본적으로 sys.dm_os_memory_clerks에 있는 모든 메모리 클럭).Max server memory controls the SQL ServerSQL Server memory allocation, compile memory, all caches (including the buffer pool), query execution memory grants, lock manager memory, and CLR1 memory (essentially any memory clerk found in sys.dm_os_memory_clerks).

1 SQL Server 2012SQL Server 2012부터 CLR 메모리는 max_server_memory 할당에서 관리됩니다.1 CLR memory is managed under max_server_memory allocations starting with SQL Server 2012SQL Server 2012.

다음 쿼리는 현재 할당된 메모리에 대한 정보를 반환합니다.The following query returns information about currently allocated memory:

SELECT 
  physical_memory_in_use_kb/1024 AS sql_physical_memory_in_use_MB, 
    large_page_allocations_kb/1024 AS sql_large_page_allocations_MB, 
    locked_page_allocations_kb/1024 AS sql_locked_page_allocations_MB,
    virtual_address_space_reserved_kb/1024 AS sql_VAS_reserved_MB, 
    virtual_address_space_committed_kb/1024 AS sql_VAS_committed_MB, 
    virtual_address_space_available_kb/1024 AS sql_VAS_available_MB,
    page_fault_count AS sql_page_fault_count,
    memory_utilization_percentage AS sql_memory_utilization_percentage, 
    process_physical_memory_low AS sql_process_physical_memory_low, 
    process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;  

스레드 스택용 메모리1, CLR2, 확장 프로시저 .dll 파일, 분산 쿼리에 의해 참조되는 OLE DB 공급자, Transact-SQLTransact-SQL 문에서 참조되는 자동화 개체, 그리고 비 SQL ServerSQL Server DLL에 의해 할당된 메모리는 최대 서버 메모리에 의해 제어되지 않습니다.Memory for thread stacks1, CLR2, extended procedure .dll files, the OLE DB providers referenced by distributed queries, automation objects referenced in Transact-SQLTransact-SQL statements, and any memory allocated by a non SQL ServerSQL Server DLL are not controlled by max server memory.

1 현재 호스트에서 선호도가 높은 CPU의 지정된 수에 대해 계산된 기본 작업자 스레드에 대한 내용은 max worker threads 서버 구성 옵션 구성 방법에 대한 설명서 페이지를 참조하세요.1 Refer to the documentation page on how to Configure the max worker threads Server Configuration Option, for information on the calculated default worker threads for a given number of affinitized CPUs in the current host. SQL ServerSQL Server 스택 크기는 다음과 같습니다. stack sizes are as follows:

SQL Server 아키텍처SQL Server Architecture OS 아키텍처OS Architecture 스택 크기Stack Size
x86(32비트)x86 (32-bit) x86(32비트)x86 (32-bit) 512KB512 KB
x86(32비트)x86 (32-bit) x64(64비트)x64 (64-bit) 768KB768 KB
x64(64비트)x64 (64-bit) x64(64비트)x64 (64-bit) 2048KB2048 KB
IA64(Itanium)IA64 (Itanium) IA64(Itanium)IA64 (Itanium) 4096KB4096 KB

2 SQL Server 2012SQL Server 2012부터 CLR 메모리는 max_server_memory 할당에서 관리됩니다.2 CLR memory is managed under max_server_memory allocations starting with SQL Server 2012SQL Server 2012.

SQL ServerSQL Server는 메모리 알림 API QueryMemoryResourceNotification을 사용하여 SQL ServerSQL Server Memory Manager가 메모리를 할당하고 해제하는 시기를 결정합니다. uses the memory notification API QueryMemoryResourceNotification to determine when the SQL ServerSQL Server Memory Manager may allocate memory and release memory.

SQL ServerSQL Server 가 시작되면 시스템에 있는 실제 메모리 양 등의 여러 매개 변수, 서버 스레드 수 및 다양한 시작 매개 변수를 기준으로 버퍼 풀의 가상 주소 공간 크기를 계산합니다.When SQL ServerSQL Server starts, it computes the size of virtual address space for the buffer pool based on a number of parameters such as amount of physical memory on the system, number of server threads and various startup parameters. SQL ServerSQL Server 는 버퍼 풀에 사용할 해당 프로세스 가상 주소 공간 크기를 계산하여 예약하지만 현재 로드에 필요한 실제 메모리 양만 확보합니다(커밋). reserves the computed amount of its process virtual address space for the buffer pool, but it acquires (commits) only the required amount of physical memory for the current load.

그런 다음 인스턴스가 작업을 지원하는 데 필요한 메모리를 계속 확보합니다.The instance then continues to acquire memory as needed to support the workload. 더 많은 사용자가 연결하여 쿼리를 실행하면 SQL ServerSQL Server 에서 필요할 때마다 실제 메모리를 더 확보합니다.As more users connect and run queries, SQL ServerSQL Server acquires the additional physical memory on demand. SQL ServerSQL Server 인스턴스는 max server memory 할당 목표량에 도달하거나 Windows에서 더 이상 여유 메모리가 없다고 표시할 때까지 실제 메모리를 계속 확보합니다. min server memory 설정보다 메모리가 많거나 Windows에서 사용 가능한 메모리가 부족하다고 표시하면 메모리를 해제합니다.A SQL ServerSQL Server instance continues to acquire physical memory until it either reaches its max server memory allocation target or Windows indicates there is no longer an excess of free memory; it frees memory when it has more than the min server memory setting, and Windows indicates that there is a shortage of free memory.

다른 응용 프로그램은 SQL ServerSQL Server인스턴스를 실행 중인 컴퓨터에서 시작될 때 메모리를 소비하므로 사용 가능한 실제 메모리 양이 SQL ServerSQL Server 목표량 아래로 떨어집니다.As other applications are started on a computer running an instance of SQL ServerSQL Server, they consume memory and the amount of free physical memory drops below the SQL ServerSQL Server target. SQL ServerSQL Server 인스턴스가 메모리 소비를 조정합니다.The instance of SQL ServerSQL Server adjusts its memory consumption. 다른 응용 프로그램이 중지되어 가용 메모리가 늘어나면 SQL ServerSQL Server 의 인스턴스가 메모리 할당량을 늘립니다.If another application is stopped and more memory becomes available, the instance of SQL ServerSQL Server increases the size of its memory allocation. SQL ServerSQL Server 는 초 단위로 몇 MB의 메모리를 해제하고 확보하기 때문에 메모리 할당량 변화에 따라 빠르게 조정됩니다. can free and acquire several megabytes of memory each second, allowing it to quickly adjust to memory allocation changes.

min 및 max server memory의 효과Effects of min and max server memory

min server memory 및 max server memory 구성 옵션은 SQL ServerSQL Server 데이터베이스 엔진의 버퍼 풀 및 기타 캐시에서 사용하는 메모리 양의 상한 및 하한을 설정합니다.The min server memory and max server memory configuration options establish upper and lower limits to the amount of memory used by the buffer pool and other caches of the SQL ServerSQL Server Database Engine. 버퍼 풀은 min server memory에 지정된 메모리의 양을 즉시 확보하지 않습니다.The buffer pool does not immediately acquire the amount of memory specified in min server memory. 버퍼 풀은 초기화하는 데 필요한 메모리만으로 시작합니다.The buffer pool starts with only the memory required to initialize. SQL Server 데이터베이스 엔진SQL Server Database Engine 작업이 증가할 때 버퍼 풀에서는 작업을 지원하는 데 필요한 메모리를 계속 확보합니다.As the SQL Server 데이터베이스 엔진SQL Server Database Engine workload increases, it keeps acquiring the memory required to support the workload. 버퍼 풀은 min server memory에 지정된 양에 도달할 때까지 확보한 메모리를 해제하지 않습니다.The buffer pool does not free any of the acquired memory until it reaches the amount specified in min server memory. min server memory에 도달하면 버퍼 풀은 표준 알고리즘을 사용하여 필요할 때 메모리를 확보하고 해제합니다.Once min server memory is reached, the buffer pool then uses the standard algorithm to acquire and free memory as needed. 유일한 차이점은 버퍼 풀이 min server memory에 지정된 수준 아래로 메모리 할당량을 떨어뜨리지 않고 max server memory에 지정된 수준보다 더 많은 메모리를 절대로 확보하지 않는다는 것입니다.The only difference is that the buffer pool never drops its memory allocation below the level specified in min server memory, and never acquires more memory than the level specified in max server memory.

참고

SQL ServerSQL Server 는 프로세스로서 max server memory 옵션이 지정한 것 보다 더 많은 메모리를 확보합니다. as a process acquires more memory than specified by max server memory option. 내부 및 외부 구성 요소 모두 추가 메모리를 사용하는 버퍼 풀 외부로 메모리를 할당할 수 있지만 일반적으로 버퍼 풀에 할당된 메모리가 여전히 SQL ServerSQL Server에서 사용하는 메모리의 가장 큰 부분을 차지합니다.Both internal and external components can allocate memory outside of the buffer pool, which consumes additional memory, but the memory allocated to the buffer pool usually still represents the largest portion of memory consumed by SQL ServerSQL Server.

SQL Server 데이터베이스 엔진SQL Server Database Engine에서 확보한 메모리 양은 인스턴스에 배치된 작업에 따라 완전히 달라집니다.The amount of memory acquired by the SQL Server 데이터베이스 엔진SQL Server Database Engine is entirely dependent on the workload placed on the instance. 많은 요청을 처리하지 않은 SQL ServerSQL Server 인스턴스는 min server memory에 절대로 도달할 수 없습니다.A SQL ServerSQL Server instance that is not processing many requests may never reach min server memory.

min server memory 및 max server memory 둘 모두에 같은 값이 지정된 경우 SQL Server 데이터베이스 엔진SQL Server Database Engine에 할당된 메모리가 해당 값에 도달하면 SQL Server 데이터베이스 엔진SQL Server Database Engine는 버퍼 풀에 대한 메모리의 동적 해제 및 확보를 중지합니다.If the same value is specified for both min server memory and max server memory, then once the memory allocated to the SQL Server 데이터베이스 엔진SQL Server Database Engine reaches that value, the SQL Server 데이터베이스 엔진SQL Server Database Engine stops dynamically freeing and acquiring memory for the buffer pool.

SQL ServerSQL Server 인스턴스가 다른 응용 프로그램이 자주 중지되거나 시작되는 컴퓨터에서 실행 중인 경우 SQL ServerSQL Server 인스턴스에 의한 메모리 할당 및 할당 취소는 다른 응용 프로그램의 시작 시간을 늦출 수 있습니다.If an instance of SQL ServerSQL Server is running on a computer where other applications are frequently stopped or started, the allocation and deallocation of memory by the instance of SQL ServerSQL Server may slow the startup times of other applications. 또한 SQL ServerSQL Server 가 단일 컴퓨터에서 실행되는 여러 서버 응용 프로그램 중 하나인 경우 시스템 관리자는 SQL ServerSQL Server에 할당된 메모리 양을 제어해야 할 수도 있습니다.Also, if SQL ServerSQL Server is one of several server applications running on a single computer, the system administrators may need to control the amount of memory allocated to SQL ServerSQL Server. 이러한 경우 min server memory 및 max server memory 옵션을 사용하여 SQL ServerSQL Server 가 사용할 수 있는 메모리 양을 제어할 수 있습니다.In these cases, you can use the min server memory and max server memory options to control how much memory SQL ServerSQL Server can use. min server memorymax server memory 옵션은 MB 단위로 지정됩니다.The min server memory and max server memory options are specified in megabytes. 자세한 내용은 Server Memory Configuration Options(서버 메모리 구성 옵션)를 참고하세요.For more information, see Server Memory Configuration Options.

SQL ServerSQL Server 개체 사양에서 사용하는 메모리Memory used by SQL ServerSQL Server objects specifications

다음 표에서는 SQL ServerSQL Server의 다양한 개체에서 사용하는 대략적인 메모리 양을 설명합니다.The following list describes the approximate amount of memory used by different objects in SQL ServerSQL Server. 제시된 크기는 추정값이기 때문에 사용 중인 환경과 개체 생성 방법에 따라 다를 수 있습니다.The amounts listed are estimates and can vary depending on the environment and how objects are created:

  • 잠금(잠금 관리자에 의해 유지 관리됨): 64바이트+32바이트(소유자당)Lock (as maintained by the Lock Manager): 64 bytes + 32 bytes per owner
  • 사용자 연결: 약 (3 * network_packet_size + 94KB)User connection: Approximately (3 * network_packet_size + 94 kb)

네트워크 패킷 크기는 응용 프로그램과 SQL ServerSQL Server 데이터베이스 엔진 간의 통신에 사용하는 TDS(Tabular Data Stream) 패킷의 크기입니다.The network packet size is the size of the tabular data scheme (TDS) packets that are used to communicate between applications and the SQL ServerSQL Server Database Engine. 기본 패킷 크기는 4KB이며 네트워크 패킷 크기 구성 옵션으로 제어됩니다.The default packet size is 4 KB, and is controlled by the network packet size configuration option.

다중 활성 결과 집합(MARS)을 사용할 수 있으면 사용자 연결은 약 (3 + 3 * num_logical_connections) * network_packet_size + 94KB입니다.When multiple active result sets (MARS) are enabled, the user connection is approximately (3 + 3 * num_logical_connections) * network_packet_size + 94 KB

버퍼 관리Buffer management

SQL ServerSQL Server 데이터베이스의 주 목적은 데이터 저장 및 검색이므로 데이터베이스 엔진의 핵심 특성은 집중형 디스크 I/O입니다.The primary purpose of a SQL ServerSQL Server database is to store and retrieve data, so intensive disk I/O is a core characteristic of the Database Engine. 디스크 I/O 작업은 많은 리소스를 소비하며 완료하는 데 비교적 오랜 시간이 걸리므로 SQL ServerSQL Server 에서는 I/O의 효율성을 높이는 데 주안점을 둡니다.And because disk I/O operations can consume many resources and take a relatively long time to finish, SQL ServerSQL Server focuses on making I/O highly efficient. 버퍼 관리는 이러한 효율성을 얻기 위한 핵심 구성 요소입니다.Buffer management is a key component in achieving this efficiency. 버퍼 관리 구성 요소는 데이터베이스 페이지에 액세스하고 업데이트하기 위한 버퍼 관리자와 데이터베이스 파일 I/O를 줄이기 위한 버퍼 캐시(버퍼 풀이라고도 함)의 두 가지 메커니즘으로 구성되어 있습니다.The buffer management component consists of two mechanisms: the buffer manager to access and update database pages, and the buffer cache (also called the buffer pool), to reduce database file I/O.

버퍼 관리 작업 방법How buffer management works

버퍼는 데이터 또는 인덱스 페이지와 같은 크기인 8KB 메모리 페이지입니다.A buffer is an 8 KB page in memory, the same size as a data or index page. 따라서 버퍼 캐시는 8KB 페이지로 나누어집니다.Thus, the buffer cache is divided into 8 KB pages. 버퍼 관리자는 데이터 또는 인덱스 페이지를 데이터베이스 디스크 파일에서 버퍼 캐시로 읽어 오고 수정한 페이지를 디스크에 다시 쓰는 기능을 관리합니다.The buffer manager manages the functions for reading data or index pages from the database disk files into the buffer cache and writing modified pages back to disk. 페이지는 버퍼 관리자에 더 많은 데이터를 읽어 올 버퍼 영역이 필요할 때까지 버퍼 캐시에 남아 있습니다.A page remains in the buffer cache until the buffer manager needs the buffer area to read in more data. 데이터는 수정되는 경우에만 다시 디스크에 쓰여집니다.Data is written back to disk only if it is modified. 버퍼 캐시의 데이터는 여러 번 수정한 후 디스크에 다시 쓸 수 있습니다.Data in the buffer cache can be modified multiple times before being written back to disk. 자세한 내용은 페이지 읽기페이지 쓰기를 참조하세요.For more information, see Reading Pages and Writing Pages.

SQL ServerSQL Server 가 시작되면 시스템에 있는 실제 메모리 크기, 구성된 서버 스레드 개수, 다양한 시작 매개 변수 등 여러 매개 변수를 기준으로 버퍼 캐시의 가상 주소 공간 크기를 계산합니다.When SQL ServerSQL Server starts, it computes the size of virtual address space for the buffer cache based on a number of parameters such as the amount of physical memory on the system, the configured number of maximum server threads, and various startup parameters. SQL ServerSQL Server 는 버퍼 캐시에 사용할 해당 프로세스 가상 주소 공간(메모리 대상이라고도 함) 크기를 계산하여 예약하지만 현재 로드에 필요한 실제 메모리 양만 확보합니다(커밋). reserves this computed amount of its process virtual address space (called the memory target) for the buffer cache, but it acquires (commits) only the required amount of physical memory for the current load. sys.dm_os_sys_info 카탈로그 뷰에서 bpool_commit_targetbpool_committed columns 열을 쿼리하여 메모리 대상으로 예약된 페이지 수와 버퍼 캐시에 현재 커밋된 페이지 수를 각각 반환할 수 있습니다.You can query the bpool_commit_target and bpool_committed columns in the sys.dm_os_sys_info catalog view to return the number of pages reserved as the memory target and the number of pages currently committed in the buffer cache, respectively.

SQL ServerSQL Server 시작 시간과 버퍼 캐시가 해당 메모리 대상을 확보하는 시간 사이의 간격을 램프 업(ramp-up)이라고 합니다.The interval between SQL ServerSQL Server startup and when the buffer cache obtains its memory target is called ramp-up. 이 시간 동안 필요에 따라 읽기 요청이 버퍼를 채웁니다.During this time, read requests fill the buffers as needed. 예를 들어 단일 8KB 페이지 읽기 요청은 단일 버퍼 페이지를 채웁니다.For example, a single 8 KB page read request fills a single buffer page. 즉, 램프 업은 클라이언트 요청의 개수 및 유형에 따라 달라집니다.This means the ramp-up depends on the number and type of client requests. 단일 페이지 읽기 요청을 정렬된 8페이지 요청으로 변환하여 램프 업을 신속히 처리합니다(하나의 익스텐트 만들기).Ramp-up is expedited by transforming single page read requests into aligned eight page requests (making up one extent). 이를 통해 메모리가 많은 컴퓨터에서 특히 램프 업이 더 빠르게 완료될 수 있습니다.This allows the ramp-up to finish much faster, especially on machines with a lot of memory. 페이지 및 익스텐트에 대한 자세한 내용은 페이지 및 익스텐트 아키텍처 가이드를 참조하세요.For more information about pages and extents, refer to Pages and Extents Architecture Guide.

버퍼 관리자는 SQL ServerSQL Server 프로세스에서 대부분의 메모리를 사용하므로 메모리 관리자와 협력하여 다른 구성 요소가 해당 버퍼를 사용할 수 있도록 합니다.Because the buffer manager uses most of the memory in the SQL ServerSQL Server process, it cooperates with the memory manager to allow other components to use its buffers. 버퍼 관리자는 다음 구성 요소와 주로 상호 작용합니다.The buffer manager interacts primarily with the following components:

  • 전체 메모리 사용량을 제어하며 32비트 플랫폼에서 주소 공간 사용량을 제어하는 리소스 관리자Resource manager to control overall memory usage and, in 32-bit platforms, to control address space usage.
  • 하위 수준 파일 I/O 작업을 위한 SQLOS( SQL ServerSQL Server 운영 체제) 및 데이터베이스 관리자Database manager and the SQL ServerSQL Server Operating System (SQLOS) for low-level file I/O operations.
  • 미리 쓰기 로깅을 위한 로그 관리자Log manager for write-ahead logging.

지원되는 기능Supported Features

버퍼 관리자는 다음과 같은 기능을 지원합니다.The buffer manager supports the following features:

  • 버퍼 관리자는 NUMA(Non-Uniform Memory Access)를 인식합니다.The buffer manager is non-uniform memory access (NUMA) aware. 버퍼 캐시 페이지는 하드웨어 NUMA 노드에 분산되므로 스레드가 외부 메모리 대신 로컬 NUMA 노드에 할당된 버퍼 페이지에 액세스할 수 있습니다.Buffer cache pages are distributed across hardware NUMA nodes, which allows a thread to access a buffer page that is allocated on the local NUMA node rather than from foreign memory.
  • 버퍼 관리자는 Hot Add 메모리를 지원하므로 사용자가 서버를 다시 시작하지 않고도 실제 메모리를 추가할 수 있습니다.The buffer manager supports Hot Add Memory, which allows users to add physical memory without restarting the server.
  • 버퍼 관리자는 64비트 플랫폼에서 큰 페이지를 지원합니다.The buffer manager supports large pages on 64-bit platforms. 페이지 크기는 Windows 버전에 따라 달라집니다.The page size is specific to the version of Windows.

    참고

    SQL Server 2012SQL Server 2012 이전에는 SQL ServerSQL Server에서 큰 페이지를 활성화하려면 추적 플래그 834가 필요합니다.Prior to SQL Server 2012SQL Server 2012, enabling large pages in SQL ServerSQL Server requires trace flag 834.

  • 버퍼 관리자는 동적 관리 뷰를 통해 표시되는 추가 진단 기능을 제공합니다.The buffer manager provides additional diagnostics that are exposed through dynamic management views. 이러한 뷰를 사용하여 다양한 SQL ServerSQL Server관련 운영 체제 리소스를 모니터링할 수 있습니다.You can use these views to monitor a variety of operating system resources that are specific to SQL ServerSQL Server. 예를 들어 sys.dm_os_buffer_descriptors 뷰를 사용하여 버퍼 캐시의 페이지를 모니터링할 수 있습니다.For example, you can use the sys.dm_os_buffer_descriptors view to monitor the pages in the buffer cache.

디스크 I/ODisk I/O

버퍼 관리자는 데이터베이스에 대해 읽기 및 쓰기만 수행합니다.The buffer manager only performs reads and writes to the database. 열기, 닫기, 확장, 축소와 같은 기타 파일 및 데이터베이스 작업은 데이터베이스 관리자 및 파일 관리자 구성 요소에 의해 수행됩니다.Other file and database operations such as open, close, extend, and shrink are performed by the database manager and file manager components.

버퍼 관리자가 수행하는 디스크 I/O 작업의 특성은 다음과 같습니다.Disk I/O operations by the buffer manager have the following characteristics:

  • 모든 I/O가 비동기적으로 수행되므로 I/O 작업이 백그라운드에서 수행되는 동안 호출한 스레드는 처리를 계속할 수 있습니다.All I/Os are performed asynchronously, which allows the calling thread to continue processing while the I/O operation takes place in the background.
  • affinity I/O 옵션을 사용하지 않는 한 모든 I/O는 호출한 스레드에서 실행됩니다.All I/Os are issued in the calling threads unless the affinity I/O option is in use. affinity I/O mask 옵션은 SQL ServerSQL Server 디스크 I/O를 지정된 CPU 하위 집합에 바인딩합니다.The affinity I/O mask option binds SQL ServerSQL Server disk I/O to a specified subset of CPUs. 고성능 SQL ServerSQL Server OLTP(온라인 트랜잭션 처리) 환경에서 이러한 확장을 통해 I/O를 실행하는 SQL ServerSQL Server 스레드의 성능을 향상시킬 수 있습니다.In high-end SQL ServerSQL Server online transactional processing (OLTP) environments, this extension can enhance the performance of SQL ServerSQL Server threads issuing I/Os.
  • 다중 페이지 I/O는 분산 수집 I/O로 수행되므로 데이터를 인접하지 않은 메모리 영역으로 또는 이러한 영역 밖으로 전송할 수 있습니다.Multiple page I/Os are accomplished with scatter-gather I/O, which allows data to be transferred into or out of noncontiguous areas of memory. 이를 통해 여러 실제 I/O 요청을 피하면서 SQL ServerSQL Server 에서 버퍼 캐시를 신속하게 채우거나 플러시할 수 있습니다.This means that SQL ServerSQL Server can quickly fill or flush the buffer cache while avoiding multiple physical I/O requests.

긴 I/O 요청Long I/O requests

버퍼 관리자는 15초 이상 보류 상태에 있는 모든 I/O 요청을 보고합니다.The buffer manager reports on any I/O request that has been outstanding for at least 15 seconds. 이를 통해 시스템 관리자는 SQL ServerSQL Server 문제와 I/O 하위 시스템 문제를 구분할 수 있습니다.This helps the system administrator distinguish between SQL ServerSQL Server problems and I/O subsystem problems. 다음과 같이 오류 메시지 833이 보고되어 SQL ServerSQL Server 오류 로그에 나타납니다.Error message 833 is reported and appears in the SQL ServerSQL Server error log as follows:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

긴 I/O는 읽기 또는 쓰기일 수 있으나 현재 이러한 정보는 메시지에 나타나 있지 않습니다.A long I/O may be either a read or a write; it is not currently indicated in the message. 긴 I/O 메시지는 오류가 아니라 경고입니다.Long-I/O messages are warnings, not errors. 이들은 SQL ServerSQL Server과 관련된 문제점이 아닌 기본 I/O 시스템과 관련된 문제점을 나타냅니다.They do not indicate problems with SQL ServerSQL Server but with the underlying I/O system. 시스템 관리자는 보고되는 메시지를 통해 느린 SQL ServerSQL Server 응답 시간의 원인을 보다 빨리 찾고 SQL ServerSQL Server제어를 벗어난 문제를 구분할 수 있습니다.The messages are reported to help the system administrator find the cause of poor SQL ServerSQL Server response times more quickly, and to distinguish problems that are outside the control of SQL ServerSQL Server. 해당 메시지를 받는다고 해서 특별한 동작을 수행해야 하는 것은 아니지만 시스템 관리자는 I/O 요청이 오래 걸리는 이유와 그러한 지연에 적합한 이유가 있는지 여부를 조사해야 합니다.As such, they do not require any action, but the system administrator should investigate why the I/O request took so long, and whether the time is justifiable.

긴 I/O 요청의 원인Causes of Long-I/O Requests

긴 I/O 메시지는 I/O가 영구적으로 차단되어 완료될 수 없거나(손실된 I/O) 단순히 아직 완료되지 않았음을 나타냅니다.A long-I/O message may indicate that an I/O is permanently blocked and will never complete (known as lost I/O), or merely that it just has not completed yet. 손실된 I/O로 인해 래치 제한 시간이 초과되는 경우가 많기는 하지만 메시지를 통해 어떤 시나리오가 이 경우에 해당하는지 알 수는 없습니다.It is not possible to tell from the message which scenario is the case, although a lost I/O will often lead to a latch timeout.

긴 I/O는 디스크 하위 시스템에 SQL ServerSQL Server 작업이 너무 많이 집중되어 있음을 나타냅니다.Long I/Os often indicate a SQL ServerSQL Server workload that is too intense for the disk subsystem. 다음과 같은 경우 디스크 하위 시스템이 부적절한 상태에 있다는 메시지가 나타날 수 있습니다.An inadequate disk subsystem may be indicated when:

  • 많은 SQL ServerSQL Server 작업을 수행하는 동안 여러 개의 긴 I/O 메시지가 오류 로그에 나타나는 경우Multiple long I/O messages appear in the error log during a heavy SQL ServerSQL Server workload.
  • Perfmon 카운터가 긴 디스크 지연 시간, 긴 디스크 큐 또는 디스크 유휴 시간 없음을 표시하는 경우Perfmon counters show long disk latencies, long disk queues, or no disk idle time.

디스크 헤드의 현재 위치에 더 가까이 있는 새로운 요청을 처리하기 위해 이전 I/O 요청 처리를 계속 연기하는 I/O 경로의 구성 요소(예: 드라이버, 컨트롤러 또는 펌웨어)로 인해 긴 I/O가 발생할 수도 있습니다.Long I/Os may also be caused by a component in the I/O path (for example, a driver, controller, or firmware) continually postponing servicing an old I/O request in favor of servicing newer requests that are closer to the current position of the disk head. 읽기/쓰기 헤드의 현재 위치에 가장 가까운 요청을 우선적으로 처리하는 방법을 "엘리베이터 검색"이라고 합니다.The common technique of processing requests in priority based upon which ones are closest to the current position of the read/write head is known as "elevator seeking." 대부분의 I/O가 즉시 처리되므로 Windows 시스템 모니터 도구(PERFMON.EXE)로 이를 확인하는 것은 어려울 수 있습니다.This may be difficult to corroborate with the Windows System Monitor (PERFMON.EXE) tool because most I/Os are being serviced promptly. 긴 I/O 요청은 백업과 복원, 테이블 검색, 정렬, 인덱스 생성, 대량 로드, 파일 비우기와 같은 순차 I/O를 대량으로 수행하는 작업으로 인해 악화될 수 있습니다.Long I/O requests can be aggravated by workloads that perform large amounts of sequential I/O, such as backup and restore, table scans, sorting, creating indexes, bulk loads, and zeroing out files.

위에 나열된 어떤 조건과도 관련되지 않은 격리된 긴 I/O는 하드웨어 또는 드라이버 문제로 인해 발생할 수 있습니다.Isolated long I/Os that do not appear related to any of the previous conditions may be caused by a hardware or driver problem. 시스템 이벤트 로그에 문제를 진단하는 데 도움이 되는 관련 이벤트가 포함되어 있을 수 있습니다.The system event log may contain a related event that helps to diagnose the problem.

오류 검색Error Detection

데이터베이스 페이지는 페이지를 디스크에 쓸 때부터 다시 읽을 때까지의 페이지 무결성을 보장하는 두 가지 선택적 메커니즘인 조각난 페이지 보호와 체크섬 보호 중 하나를 사용할 수 있습니다.Database pages can use one of two optional mechanisms that help insure the integrity of the page from the time it is written to disk until it is read again: torn page protection and checksum protection. 이러한 메커니즘을 사용하면 데이터 저장소뿐만 아니라 컨트롤러, 드라이버, 케이블, 심지어는 운영 체제를 비롯한 하드웨어 구성 요소의 정확성을 확인하는 독자적인 방법을 활용할 수 있습니다.These mechanisms allow an independent method of verifying the correctness of not only the data storage, but hardware components such as controllers, drivers, cables, and even the operating system. 이러한 보호는 페이지를 디스크에 쓰기 바로 전에 페이지에 추가되며 디스크에서 읽은 후 확인됩니다.The protection is added to the page just before writing it to disk, and verified after it is read from disk.

SQL ServerSQL Server는 체크섬, 조각난 페이지 또는 기타 I/O 오류로 읽기가 실패할 경우 4번 다시 시도합니다. will retry any read that fails with a checksum, torn page, or other I/O error four times. 다시 시도 중에 한 번이라도 읽기가 성공하면 오류 로그에 메시지가 기록되고 해당 읽기를 트리거한 명령이 계속 수행됩니다.If the read is successful in any one of the retry attempts, a message will be written to the error log and the command that triggered the read will continue. 다시 시도가 실패하면 824 오류 메시지와 함께 명령이 실패합니다.If the retry attempts fail, the command will fail with error message 824.

사용되는 페이지 보호 유형은 페이지를 포함하는 데이터베이스의 특성입니다.The kind of page protection used is an attribute of the database containing the page. 체크섬 보호는 SQL Server 2005SQL Server 2005 이상 버전에서 생성된 데이터베이스의 기본 보호 메커니즘입니다.Checksum protection is the default protection for databases created in SQL Server 2005SQL Server 2005 and later. 페이지 보호 메커니즘은 데이터베이스 생성 시 지정하며 ALTER DATABASE SET를 사용하여 변경할 수 있습니다.The page protection mechanism is specified at database creation time, and may be altered by using ALTER DATABASE SET. sys.databases 카탈로그 뷰의 page_verify_option 열 또는 DATABASEPROPERTYEX 함수의 IsTornPageDetectionEnabled 속성을 쿼리하여 현재 페이지 보호 설정을 확인할 수 있습니다.You can determine the current page protection setting by querying the page_verify_option column in the sys.databases catalog view or the IsTornPageDetectionEnabled property of the DATABASEPROPERTYEX function.

참고

페이지 보호 설정을 변경해도 새 설정이 전체 데이터베이스에 즉시 영향을 주지는 않습니다.If the page protection setting is changed, the new setting does not immediately affect the entire database. 대신 페이지는 다음에 쓰일 때부터 데이터베이스의 현재 보호 수준을 적용합니다.Instead, pages adopt the current protection level of the database whenever they are written next. 이에 따라 데이터베이스가 보호 유형이 서로 다른 여러 페이지로 구성될 수 있습니다.This means that the database may be composed of pages with different kinds of protection.

조각난 페이지 보호Torn Page Protection

SQL ServerSQL Server 2000에 도입된 조각난 페이지 보호는 주로 전원 오류로 인한 페이지 손상을 검색하는 방법입니다.Torn page protection, introduced in SQL ServerSQL Server 2000, is primarily a way of detecting page corruptions due to power failures. 예를 들어 예기치 않은 전원 오류로 인해 페이지의 일부만 디스크에 쓰일 수 있습니다.For example, an unexpected power failure may leave only part of a page written to disk. 조각난 페이지 보호를 사용하면 8KB 데이터베이스 페이지의 각 512바이트 섹터에 대해 특정 2비트 서명 패턴이 작성되고 페이지가 디스크에 쓰여질 때 데이터베이스 페이지 헤더에 저장됩니다.When torn page protection is used, a specific 2-bit signature pattern for each 512-byte sector in the 8-kilobyte (KB) database page and stored in the database page header when the page is written to disk. 디스크에서 페이지를 읽으면 페이지 헤더에 저장된 조각난 비트가 실제 페이지 섹터 정보와 비교됩니다.When the page is read from disk, the torn bits stored in the page header are compared to the actual page sector information. 매번 쓸 때마다 서명 패턴은 이진 01과 이진 10이 번갈아 사용되기 때문에 섹터의 일부분만 디스크에 기록되는 경우가 있으면 빠짐없이 이를 알려줍니다. 나중에 페이지를 읽을 때 비트가 잘못된 상태이면 페이지가 잘못 작성된 것이며 조각난 페이지가 검색됩니다.The signature pattern alternates between binary 01 and 10 with every write, so it is always possible to tell when only a portion of the sectors made it to disk: if a bit is in the wrong state when the page is later read, the page was written incorrectly and a torn page is detected. 조각난 페이지 검색은 최소한의 리소스를 사용하지만 디스크 하드웨어 오류로 인한 모든 오류를 검색하지는 않습니다.Torn page detection uses minimal resources; however, it does not detect all errors caused by disk hardware failures. 조각난 페이지 검색 설정에 대한 자세한 내용은 ALTER DATABASE SET Options (Transact-SQL)을 참조하세요.For information on setting torn page detection, see ALTER DATABASE SET Options (Transact-SQL).

체크섬 보호Checksum Protection

SQL Server 2005SQL Server 2005에 도입된 체크섬 보호는 보다 강력한 데이터 무결성 검사 기능을 제공합니다.Checksum protection, introduced in SQL Server 2005SQL Server 2005, provides stronger data integrity checking. 체크섬은 쓰인 각 페이지의 데이터에 대해 계산되어 페이지 머리글에 저장됩니다.A checksum is calculated for the data in each page that is written, and stored in the page header. 저장된 체크섬이 있는 페이지를 디스크에서 읽을 때마다 데이터베이스 엔진은 페이지의 데이터에 대한 체크섬을 다시 계산하고 새 체크섬이 저장된 체크섬과 다를 경우 오류 824를 발생시킵니다.Whenever a page with a stored checksum is read from disk, the database engine recalculates the checksum for the data in the page and raises error 824 if the new checksum is different from the stored checksum. 체크섬 보호는 페이지의 모든 바이트에 의해 영향을 받으므로 조각난 페이지 보호보다 더 많은 오류를 catch할 수 있지만 많은 리소스를 소비합니다.Checksum protection can catch more errors than torn page protection because it is affected by every byte of the page, however, it is moderately resource intensive. 체크섬을 설정하면 버퍼 관리자가 디스크에서 페이지를 읽을 때마다 전원 오류 및 결함이 있는 하드웨어나 펌웨어로 인한 오류를 검색할 수 있습니다.When checksum is enabled, errors caused by power failures and flawed hardware or firmware can be detected any time the buffer manager reads a page from disk. 체크섬 설정에 대한 자세한 내용은 ALTER DATABASE SET Options (Transact-SQL)을 참조하세요.For information on setting checksum, see ALTER DATABASE SET Options (Transact-SQL).

중요

사용자 또는 시스템 데이터베이스를 SQL Server 2005SQL Server 2005 이상 버전으로 업그레이드하는 경우 PAGE_VERIFY 값(NONE 또는 TORN_PAGE_DETECTION)이 유지됩니다.When a user or system database is upgraded to SQL Server 2005SQL Server 2005 or a later version, the PAGE_VERIFY value (NONE or TORN_PAGE_DETECTION) is retained. CHECKSUM을 사용하는 것이 좋습니다.We recommend that you use CHECKSUM. TORN_PAGE_DETECTION은 리소스는 덜 사용하지만 CHECKSUM 보호를 최소한으로 제공합니다.TORN_PAGE_DETECTION may use fewer resources but provides a minimal subset of the CHECKSUM protection.

NUMA(Non-Uniform Memory Access) 이해Understanding Non-uniform Memory Access

SQL ServerSQL Server 는 NUMA(Non-Uniform Memory Access)를 인식하며 특수한 구성 없이 NUMA 하드웨어에서 원활하게 작동합니다. is non-uniform memory access (NUMA) aware, and performs well on NUMA hardware without special configuration. 클럭 속도와 프로세서 수가 증가할수록 이러한 추가 처리 능력을 사용하는 데 필요한 메모리 대기 시간을 줄이기가 더 어려워집니다.As clock speed and the number of processors increase, it becomes increasingly difficult to reduce the memory latency required to use this additional processing power. 이러한 문제를 피하기 위해 하드웨어 공급업체에서는 대용량의 L3 캐시를 제공하지만 이는 제한적인 해결책입니다.To circumvent this, hardware vendors provide large L3 caches, but this is only a limited solution. NUMA 아키텍처는 확장성 있는 솔루션으로 이 문제를 해결합니다.NUMA architecture provides a scalable solution to this problem. SQL ServerSQL Server 는 응용 프로그램을 변경할 필요 없이 NUMA 기반 컴퓨터를 활용하도록 설계되었습니다. has been designed to take advantage of NUMA-based computers without requiring any application changes. 자세한 내용은 방법: 소프트 NUMA를 사용하도록 SQL Server 구성을 참조하세요.For more information, see How to: Configure SQL Server to Use Soft-NUMA.

관련 항목:See Also

서버 메모리 서버 구성 옵션 Server Memory Server Configuration Options
페이지 읽기 Reading Pages
페이지 쓰기 Writing Pages
방법: 소프트 NUMA를 사용하도록 SQL Server 구성 How to: Configure SQL Server to Use Soft-NUMA
메모리 액세스에 최적화된 테이블 사용을 위한 요구 사항 Requirements for Using Memory-Optimized Tables
메모리 최적화 테이블을 사용하여 메모리 부족 문제 해결Resolve Out Of Memory Issues Using Memory-Optimized Tables