메모리 관리 아키텍처 – 버퍼 관리

메모리 관리 아키텍처 – 버퍼 관리

 

• Version : SQL Server 2005, 2008, 2008R2

 

SQL Server 데이터베이스의 주 목적은 데이터 저장과 데이터 검색이므로 데이터베이스 엔진의 특성은 집중형 디스크 I/O이다. I/O 작업은 많은 리소스를 소비하며 완료하는 데 비교적 오랜 시간이 걸리므로 SQL Server에서는 I/O의 효율성을 높이는 것이 중요하다. 버퍼 관리는 이러한 효율성을 얻기 위한 핵심 구성요소이다.

 

버퍼 관리 구성 요소는 데이터베이스 페이지를 액세스하고 업데이트 하기 위한 버퍼 관리자와 데이터베이스 파일 I/O를 줄이기 위한 버퍼캐시(버퍼 풀이라고도 함)의 두 가지 메커니즘으로 구성되어 있다.

 

 

[버퍼 관리 작업 방법]

버퍼는 데이터 또는 인덱스 페이지와 같은 크기인 8KB 메모리 페이지 이다. 따라서 버퍼 캐시는 8KB 페이지 단위로 나누어 진다. 버퍼 관리자는 데이터 또는 인덱스 페이지를 데이터베이스 디스크 파일에서 버퍼캐시로 읽어오고 수정한 페이지를 디스크에 다시 쓰는 기능을 관리 한다.

 

페이지는 버퍼 관리자에 더 많은 데이터를 읽어올 버퍼 영역이 필요할 때까지 버퍼 캐시에 남아 있다. 데이터는 수정되는 경우에만 다시 디스크에 쓰여진다. 버퍼 캐시의 데이터는 여러 번 수정한 후 디스크에 다시 쓸 수 있다.

 

SQL Server 시작 시 시스템의 실제 메모리 양, 구성된 최대 서버 스레드 수, 다양한 시작 매개변수 등을 기반으로 버퍼 캐시의 가상 주소 공간 크기를 계산 한다. SQL Server에서는 계산된 가상 주고 공간(메모리 대상)을 버퍼 캐시용으로 예약하지만 현재 로드 된 파일에 대한 실제 메모리만 확보(커밋)한다.

 

Sys.dm_os_sys_info 카탈로그 뷰에서 bpool_commit_target 및 bpool_committed 정보는 메모리 대상으로 예약된 페이지 수와 버퍼 캐시에 현재 커밋된 페이지수를 확인 할 수 있다.

select bpool_committed, bpool_commit_target from sys.dm_os_sys_info

 

 

SQL Server 시작 시 버퍼 캐시가 해당 메모리 대상을 확보하는 시간 사이의 간격을 램프 업(ramp_up)이라고 한다. 이 시간 동안 필요에 따라 읽기 요청이 버퍼를 채운다. 예를 들어 단일 페이지 읽기 요청은 단일 버퍼 페이지를 채운다. 즉 램프 업은 클라이언트 요청의 개 수 및 유형에 따라 달라진다. 단일 페이지 읽기 요청을 정렬된 8페이지 요청으로 변환하여 램프 업을 신속히 처리 한다. 이를 통해 메모리가 많은 컴퓨터에서 램프 업이 더 빠르게 완료 될 수 있다.

 

 

버퍼 관리자는 SQL Server 프로세스에서 대부분의 메모리를 사용하므로 메모리 관리자와 협력하여 다른 구성 요소가 해당 버퍼를 사용 할 수 있도록 한다. 버퍼 관리자는 다음의 구성 요소와 상호 작용을 한다.

• 전체 메모리 사용량을 제어하며 32비트 플랫폼에서 주소 공간 사용량을 제어하는 리소스 관리자
• 하위 수준 파일 I/O 작업을 위한 SQLOS(SQL Server 운영체제) 및 데이터베이스 관리자
• 미리 쓰기 로깅을 위한 로그 관리자

 

 

[버퍼 관리자의 지원 기능]

• 버퍼 관리자는 NUMA(Non-Uniform Memory Access)를 인식한다. 버퍼 캐시 페이지는 하드웨어 NUMA, 노드에 분산되므로 스레드가 외부 메모리 대신 로컬 NUMA 노드에 할당 된 버퍼 페이지에 액세스 할 수 있다.

 

• 버퍼 관리자는 Hot Add 메모리를 지원하므로 사용자가 서버를 다시 시작하지 않고도 실제 메모리를 추가할 수 있다.
• 버퍼 관리자는 AWE가 설정된 경우 Windows XP 32비트 및 Windows Server 2003 32비트 플랫폼에서 동적 메모리 할당을 지원한다. 동적 메모리 할당을 통해 데이터베이스 엔진은 버퍼 캐시에서 메모리를 효율적으로 확보 미 및 해제하여 현재 작업을 지원한다.
• 버퍼 관리자는 동적 관리 뷰를 통해 표시되는 추기 진단 기능을 제공한다. 이러한 뷰를 사용하여 다양한 SQL Server 관련 운영체제 리소스를 모니터링 할 수 있다. Sys.dm_os_buffer_descriptors 뷰를 버퍼 캐시의 페이지를 모니터링 할 수 있다.

 

 

[디스크 I/O]

버퍼 관리자는 데이터베이스에 대해 읽기 및 쓰기만 수행 한다. 열기, 닫기, 확장, 축소와 같은 기타 파일 및 데이터베이스 작업은 데이터베이스 관리자 및 파일 관리자 구성 요소에 의해 수행 된다.

 

버퍼 관리자가 수행하는 디스크 I/O 작업의 특성은 다음과 같다.

• 모든 I/O가 비동기적으로 수행되므로 I/O 작업이 백그라운드에서 수행되는 동안 호출한 스레드는 처리를 계속 할 수 있다.
• Affinity I/O 옵션을 사용하지 않은 한 모든 I/O는 호출한 스레드에서 실행 된다. Affinity I/O mask 옵션은 SQL Server 디스크 I/O를 지정된 CPU 하위 집합에 바인딩 한다. 고성능 SQL Server OLTP환경에서 이러한 확장을 통해 I/O를 실행하는 SQL Server 스레드의 성능을 향상 시킬 수 있다.
• 다중 페이지 I/O는 분산 수집 I/O로 수행 되므로 데이터를 인접하지 않은 메모리 영역으로 또는 이러한 영역 밖으로 전송할 수 있다. 이를 통해 실제 여러 I/O 요청을 피하면서 SQL Server에서 버퍼 캐시를 신속하게 채우거나 플러시 할 수 있다.

 

[긴 I/O 요청]

버퍼 관리자는 15초 이상 보류 상태에 있는 모든 I/O 요청을 보고 한다. 이를 통해 시스템 관리자는 SQL Server문제와 I/O 하위 시스템 문제를 구분 할 수 있다. 오류로그 833이 보고되며 SQL Server 오류 로그에 기록 된다.

 

긴 I/O는 읽기 또는 쓰기일 수 있으나 현재 이러한 정보는 메시지에 나타나 있지 않다. 긴 I/O 메시지는 오류가 아니라 경고이다. 또한 SQL Server 관련 문제를 나타내지 않는다. 해당 메시지의 발생이 특별한 동작을 해야 하는 것은 아니지만 관리자는 I/O 요청이 오래 걸리는 이유를 조사해야 할 필요는 있다.

 

[긴 I/O 요청 원인]

긴 I/O 메시지는 I/O가 영구적으로 차단되어 완료될 수 없거나 (손실된 I/O) 단순히 아직 완료되지 않았음을 나타낸다. 손실된 I/O로 인해 래치 제한 시간이 초과되는 경우가 많기는 하지만 메시지를 통해 어떤 시나리오가 이 경우에 해당하는지 알 수는 없다.

 

긴 I/O는 디스크 하위 시스템에 SQL Server 작업이 너무 많이 집중되어 있음을 나타낸다. 다음과 같은 경우 디스크 하위 시스템이 부적절한 상태에 있다는 메시지가 나타날 수 있다.

• 많은 SQL Server 작업을 수행하는 동안 여러 개의 긴 I/O 메시지가 오류 로그에 나타나는 경우
• Perfmon 카운터가 긴 디스크 지연시간, 긴 디스크 큐, 여유 없는 유휴 시간을 표시하는 경우

 

디스크 헤드의 현재 위치에 더 가까이 있는 새로운 요청을 처리하기 위해 이전 I/O 요청 처리를 계속 연기하는 I/O 경로의 구성 요소(드라이버, 펌웨어, 컨트롤러 등)로 인해 긴 I/O가 발생 할 수 도 있다.

 

읽기/쓰기 헤드의 현재 위치에 가장 가까운 요청을 우선적으로 처리하는 방법을 [엘리베이터 검색]이라고 하며 대부분의 I/O가 즉시 처리되므로 perfmon에서 확인 하는 것은 어렵다. 긴 I/O 요청은 백업과 복원, 테이블 검색, 정렬, 인덱스 생성, 대량 로드, 파일 비우기와 같은 순차 I/O를 대량으로 수행하는 작업으로 인해 악화 될 수 있다.

 

[오류 검색]

데이터베이스 페이지는 디스크에 쓸 때부터 다시 읽을 때까지의 페이지 무결성을 보장하는 두 가지 선택적 메커니즘인 [조각난 페이지 보호]와 [체크섬 보호] 중 하나를 사용한다. 이러한 메커니즘을 사용하면 데이터 저장소 뿐만 아니라 컨트롤러, 드라이버, 케이블, 운영체제, 하드웨어 구성요서의 정확성을 확인하는 독자적인 방법을 활용 할 수 있다. 이러한 보호는 페이지를 디스크에 쓰기 바로 전에 페이지에 추가되며 디스크에서 읽은 후 확인된다.

 

[조각난 페이지 보호]

SQL Server 2000 부터 도입된 기능으로 주로 전원 오류로 인한 페이지 손상을 검색하는 방법이다. 조각난 페이지 보호를 사용하면 원래의 2비트가 페이지 머리글로 복사된 후 페이지의 각 512바이트 구역 끝에 2비트 서명이 저장된다. 페이지를 쓸 때마다 서명은 이진수 01과 10을 번갈아 사용되므로 구역의 일부만 디스크에 쓰여진 경우 이를 알 수 있다. 나중에 페이지를 읽을 때 비트가 잘못된 상태에 있으면 페이지가 잘못 쓰인 것이며 조각난 페이지가 검색 된다. 조각난 페이지 검색은 최소한의 리소스를 사용하지만 디스크 하드웨어 오류로 인한 모든 오류를 검색하지는 않는다.

 

[체크섬 보호]

SQL Server 2005 부터 도입된 체크섬은 데이터 무결성 검사 기능을 제공한다. 체크섬은 쓰인 각 페이지의 데이터에 대해 계산되어 페이지 머리글에 저장된다. 저장된 체크섬이 있는 페이지를 디스크에서 읽을 때마다 데이터베이스 엔진은 페이지의 데이터에 대한 체크섬을 다시 계산하고 새 체크섬이 저장된 체크섬과 다를 경우 824 오류를 반환한다. 체크섬 보호는 페이지의 모든 바이트에 의해 영향을 받으므로 조각나 페이지 보호보다 더 많은 오류를 catch 할 수 있지만 많은 리소스를 소비한다. 체크섬을 설정하면 버퍼관리자가 디스크에서 페이지를 읽을 때마다 전원 오류 및 결함이 있는 하드웨어나 펌웨어로 인한 오류를 검색 할 수 있다.

 

페이지 보호 메커니즘은 데이터베이스 생성 시 지정하며 ALTER DATABASE를 사용하여 변경 할 수 있으며 sys.database 카탈로그 뷰의 page_verify_option 열 또는 DATABASEPROPERTYEX 함수의 is TornPageDetectionEnabled 속성을 쿼리하여 현재 페이지 보호 설정을 확인 할 수 있다.

 

페이지 보호 설정을 변경해도 새 설정이 전체 데이터베이스에 즉시 영향을 주지는 않으며 페이지는 다음에 쓰일 때부터 데이터베이스의 현재 보호 수준을 적용한다. 이에 따라 데이터베이스가 보호 유형이 서로 다른 여러 페이지로 구성 될 수 있다.

 

 

[참고자료]

버퍼관리 : http://msdn.microsoft.com/ko-kr/library/aa337525(v=sql.105).aspx

SQL Server 2008 NUMA and Foreign Pages :

http://blogs.msdn.com/b/psssql/archive/2010/02/23/how-it-works-sql-server-2008-numa-and-foreign-pages.aspx

 

 

 

2013-05-31 / 강성욱 / http://sqlmvp.kr