데이터베이스 개발자 Tip & 강좌

SQLER의 개발자들이 만들어가는 데이터베이스 사용자 Tip & 강좌 게시판입니다. SQL서버, Oracle, MySQL 등 여러 클라우드/오픈소스 기반 데이터베이스 개발 및 운영 관련 팁과 쿼리 노하우를 이곳에서 가장 먼저 접하실 수 있습니다. 많은 도움 되시길 바랍니다.

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

 

  • Version : SQL Server 2005, 2008, 2008R2

 

SQL Server에서는 메모리를 필요에 따라 동적으로 확보하고 해제 한다. 일반적으로 관리자는 SQL Server에 할당 해야 하는 메모리 양을 지정할 필요가 없다. (필자의 생각은 SQL 전용 시스템의 경우 최소, 최대 메모리 할당을 통하여 만약의 사태에 SQL Server의 가용 메모리가 뺏기는 일이 없어야 한다고 생각한다.)

 

SQL Servers는 32비트의 Windows 운영체제에서 실제 메모리를 4GB이상 사용할 수 있도록 하는 AWE(Address Windowing Extensions)를 지원하여 최대 64GB의 실제 메모리가 지원된다.

 

 

Windows 2000에서 실행되는 SQL Server 인스턴스는 정적 AWE 메모리를 할당을 사용하고Windows 2003에서 실행되는 인스턴스는 동적 AWE 메모리 할당을 사용한다. SQL Server 2005부터는 인스턴스의 메모리를 동적으로 관리한다.

 

AWE 기능은 SQL Server Enterprise, Standard, Developer 버전에서만 지원되며 32비트 운영체제에만 적용 된다. Analysis Services에서는 AWE로 매핑 된 메모리를 이용할 수 없으며 사용할 수 있는 실제 메모리가 사용자 모드 가상 주소 공간보다 적으면 AWE를 사용할 수 없다.

 

 

디스크 읽기 및 쓰기는 리소스를 가장 많이 사용하는 작업에서 발생하므로 모든 데이터베이스 소프트웨어 디자인의 기본 목표 중 하나는 디스크 입/출력을 최소화 하는 것이다. SQL Server는 메모리에 버퍼 풀을 작성하여 데이터베이스에서 읽은 페이지를 유지 한다. SQL Server는 다음 두 목표간의 균형을 유지하려 한다.

  • 전체 시스템의 메모리가 부족해지지 않도록 적정한 수준의 버퍼 풀 크기 유지
  • 버퍼 풀의 크기를 최대화하여 데이터베이스 파일에 대한 실제 입출력 최소화

 

사용량이 많은 시스템에 많은 메모리가 필요한 대규모 쿼리를 실행할 경우 요청한 최소 메모리 용량을 얻지 못하고 메모리 리소스를 대기하는 동인 시간 초과 오류가 발생하게 된다. 이 문제를 해결하려면 query wait 옵션을 늘리거나 병렬쿼리의 경우 MAXDOP 옵션을 줄여서 해결 할 수 있다.

 

사용량이 많고 메모리가 부족한 시스템에서는 쿼리가 비트맵에 필요한 최소 메모리를 얻지 못 할경우 쿼리 계획에 병합 조인, 정렬 및 비트맵이 포함된 쿼리에서 비트맵을 삭제할 수 있다. 이 경우 쿼리 성능에 영향을 줄 수 있으며 정렬 프로세스가 메모리에 들어가지 않을 경우 tempdb 데이터베이스의 작업 테이블이 증가하여 tempdb가 확장 될 수도 있다. 이 문제를 해결하려면 실제 메모리를 추가하거나 더 빠른 다른 쿼리 계획을 사용하도록 튜닝을 해야 한다.

 

[SQL Server 최대 메모리 양]

AWE와 Lock Pages in Memory 권한을 사용하여 SQL Server에 다음과 같이 메모리 양을 제공할 수 있다.

 

32비트

64비트

기본 메모리

모든 SQL Server 버전 : 프로세스 가상 주소 공간 제한까지 허용.

  • 2GB
  • 3GB(/3gb 부트 매개 변수 사용)
  • 4GB(WOW64 사용)

모든 SQL Server 버전 : 프로세스 가상 주소 공간 제한까지 허용.

  • 7TB(IA64 아키텍처 사용)
  • 8TB(x64 아키텍처 사용)

AWE

SQL Server STD, ENT, DEV 버전 : 버퍼 풀이 최대 64GB의 메모리에 액세스 할 수 있다.

해당 사항 없음

Lock page in Memory

SQL Server STD, ENT, DEV 버전 : SQL Server 프로세스에서 AWE 메커니즘을 사용하는데 필요. AWE 메커니즘을 통해 할당된 메모리는 페이징 할 수 없다. AWE를 사용하지 않고 이 권한을 부여하면 서버에 영향을 주지 않는다.

SQL Server ENT, DEV 버전 : 운영체제 페이징을 방지 하기 위해 권장. 작업에 다라 성능이 향상 될 수 있음. 액세스할 수 있는 메모리 양은 기본 메모리의 경우 유사하다.

 

 

[참고 자료]

 

 강성욱 / jevida@naver.com
Microsoft SQL Server MVP
Blog : http://sqlmvp.kr
Facebook : http://facebook.com/sqlmvp

No. Subject Author Date Views
1792 메모리 관리 아키텍처 – Hot Add 메모리 jevida(강성욱) 2016.09.28 929
1791 메모리 관리 아키텍처 – 버퍼 관리_페이지 쓰기 jevida(강성욱) 2016.09.28 1056
1790 메모리 관리 아키텍처 – 버퍼 관리_페이지 읽기 jevida(강성욱) 2016.09.28 1250
1789 메모리 관리 아키텍처 – 버퍼 관리 jevida(강성욱) 2016.09.28 1819
1788 메모리 관리 아키텍처 – Min/Max Server Memory 효과 jevida(강성욱) 2016.09.28 2557
1787 메모리 관리 아키텍처 – 동적 메모리 관리 jevida(강성욱) 2016.09.28 1365
1786 메모리 관리 아키텍처 – 프로세스 주소 공간 jevida(강성욱) 2016.09.28 1363
» 메모리 관리 아키텍처 – 메모리 아키텍처 jevida(강성욱) 2016.09.28 1873
1784 데이터 압축 상태에 대한 개체 크기 예상 jevida(강성욱) 2016.09.28 1371
1783 sp_MSforeachdb, sp_MSforeachtable 프로시저 활용하기 jevida(강성욱) 2016.09.28 2895
1782 SQL Server 쿼리 처리 아키텍처_분산 쿼리 아키텍처 jevida(강성욱) 2016.09.28 1145
1781 SQL Server 쿼리 처리 아키텍처_병렬 쿼리 처리 - 병렬 인덱스 작업 jevida(강성욱) 2016.09.28 1342
1780 SQL Server 쿼리 처리 아키텍처_병렬 쿼리 처리 - 병렬 처리 수준 jevida(강성욱) 2016.09.28 1856
1779 SQL Server 쿼리 처리 아키텍처_병렬 쿼리 처리 jevida(강성욱) 2016.09.28 1791
1778 SQL Server 쿼리 처리 아키텍처_실행 계획 캐싱 및 다시 사용 - Preparing SQL Statements jevida(강성욱) 2016.09.28 1009
1777 SQL Server 쿼리 처리 아키텍처_실행 계획 캐싱 및 다시 사용 - 강제 매개 변수화 jevida(강성욱) 2016.09.28 999
1776 SQL Server 쿼리 처리 아키텍처_실행 계획 캐싱 및 다시 사용 - 단순 매개 변수화 jevida(강성욱) 2016.09.28 880
1775 SQL Server 쿼리 처리 아키텍처_실행 계획 캐싱 및 다시 사용 - 매개 변수 및 실행 계획 재사용 jevida(강성욱) 2016.09.28 1101
1774 SQL Server 쿼리 처리 아키텍처_실행 계획 캐싱 및 다시 사용 jevida(강성욱) 2016.09.28 1442
1773 DMV를 이용한 캐시된 저장 프로시저 통계 정보 확인 jevida(강성욱) 2016.09.28 991





XE Login