SQL Server 데이터 페이지 버퍼 의 메모리 병목 분석

SQL Server 는 데이터 접근 속 도 를 높이 기 위해 자주 사용 하 는 데이터 캐 시 를 메모리 에 저장 합 니 다.디스크 접근 속도 가 메모리 보다 훨씬 낮 기 때문에 디스크 접근 을 줄 이 는 것 도 데이터베이스 최적화 의 중요 한 부분 이다.데이터 페이지 캐 시 에 메모리 가 부족 하면 조회 가 느 리 고 디스크 가 바 쁜 문제 가 발생 할 수 있 습 니 다.분석 방법:주로 성능 계수 기 를 사용한다.다음 성능 카운터 보기:1.SQL SERVER:Buffer Manager-Lazy Writes/sec:메모리 가 부족 하면 Lazy Writer 를 자주 호출 하여 데 이 터 를 디스크 에 기록 합 니 다.이 값 은 0.2.SQL SERVER:Buffer Manager-Page life expectancy:메모리 가 부족 할 때 이 계산 기 는 하락 세 를 보이 거나 낮은 값 에 머 물 러 있 습 니 다.3.SQL SERVER:Buffer Manager-Page reads/sec:메모리 가 부족 할 때 자주 사용 하지만 메모리 에 캐 시 되 지 않 은 데 이 터 를 조회 할 때 디스크 를 읽 을 필요 가 없습니다.이 값 은 지속 적 으로 상승 하거나 높 은 값 에 머 무 르 는 것 으로 나타 납 니 다.4.SQL SERVER:Buffer Manager-Stolen pages:Stolen pages 는 보통 캐 시 실행 계획 에 사 용 됩 니 다.메모리 가 부족 할 때 SQL Server 자체 메커니즘 은 실행 계획 캐 시 를 우선 삭제 합 니 다.이 값 은 낮 거나 낮은 수준 으로 표 시 됩 니 다.현재 사용자 퀘 스 트 조회 대기:

select * from sys.sysprocesses 

메모리 가 부족 하면 많은 ASYNC 를 볼 수 있 습 니 다.IO_COMPLETION 대기 유형.이것 은 메모리 가 부족 할 때:a.메모리 와 디스크 간 에 자주 상호작용 을 하고 디스크 부하 가 증가 합 니 다.b.디스크 의 데 이 터 를 읽 고 조 회 를 완성 해 야 합 니 다.디스크 부하 가 증가 합 니 다.즉,이때 디스크 에 도 성능 병목 이 생 겼 지만 이것 은'표면'일 뿐 이 므 로 우 리 는 여러 가지 성능 지 표를 결합 하여 근본 적 인 원인 이'메모리 부족'이라는 것 을 인식 해 야 한다.압력 출처 확인 및 해결 방법:앞의 분석 을 통 해 데이터 페이지 캐 시 와 관련 된 메모리 병목 을 확정 했다.왜 그 랬 는 지,해결책 을 분석 해 야 지.주로 다음 과 같은 5 가지 측면 으로 나 뉜 다.1.외부 압력 이 OS 차원 이나 다른 응용 서비스 에 더 많은 메모리 가 필요 하 다 면 windows 는 Database 페이지 의 메모리 양 을 압축 할 것 이다.이때 메모리 압력 은 외부 에서 온다.다음 성능 계수 기 를 통 해 외부 압력 여 부 를 확인 할 수 있 습 니 다.1.SQL Server:Memory Manager-Total Server Memory:이 계수 기 는 값 이 떨 어 집 니 다.2.Memory:Available Mbytes:이 값 은 낮은 수준 으로 떨 어 집 니 다.3.AWE 나 Lock page in memory 를 사용 하지 않 은 전제 에서 Process:Private Bytes-SqlServer 와 Process:Working Set-sql Server 를 보면 이들 의 값 이 현저히 떨어진다.해결 방법:DB 전용 서버 가 아니라면 각 응용 서비스 간 의 중요성 을 따 져 서 메모 리 를 분배 하거나 메모 리 를 늘 려 야 합 니 다.가능 한 한 서버 가 SQL Server 만 실행 하도록 DB 전용 서버 가 되도록 한다.2.SQL Server 자체 가 Database Page 에 대한 사용 압력 은 Total Server Memory 가 설 정 된 Max Server Memory 에 도 달 했 거나 OS 에서 더 많은 메모 리 를 얻 을 수 없 지만 자주 방문 하 는 데 이 터 는 물리 적 메모리 가 데이터 캐 시 에 사용 하 는 용량 보다 훨씬 많 을 때 SQL Server 는 메모리 의 데 이 터 를 이동 하고 이동 시 켜 현재 조 회 를 완성 하도록 강요당 합 니 다.다음 성능 계수 기 를 관찰 합 니 다:1.SQL Server:Memory Manager-Total Server Memory 와 SQL Server:Memory Manager-Target Server Memory 두 값 은 같 습 니 다.그러나 전 자 는 후자 보다 크 지 않다.2.'분석 방법'에서 말 한 상황 이 나타 날 것 이다.해결 방법:데이터베이스 페이지 를 저장 할 메모리 가 충분 하지 않 은 이상 SQL Server 가 사용 하 는 메모리 의 양 을 늘 리 거나 사용 하 는 메모리 의 양 을 줄 입 니 다.추가:물리 적 메모 리 를 추가 하고 AWE 를 사용 하 는 방법 등 을 사용 할 수 있 습 니 다.감소:가로 확장 을 통 해 두 대 또는 여러 대의 서버 가 각각 라 이브 러 리 를 불 러 올 수 있 습 니 다.관련 독 서량 이 비교적 많은 문장 등 을 최적화 하 다.3.Buffer Pool 의 Stolen Memory 압력 이 정상 적 인 상황 에서 Buffer Pool 의 Stolen Memory 는 Database Pages 에 압력 을 주지 않 습 니 다.Database Pages 가 스트레스 를 받 기 때문에 Lazy Writes 를 촉발 하고 SQL Server 는 훔 친 메모리 의 실행 계획 캐 시 를 청소 합 니 다.단,사용자 가 너무 많은 대상 을 밝 히 고 로그 인하 지 않 으 며 메모리 사용량 이 너무 많 으 면 Database Pages 를 압축 합 니 다.예 를 들 어 커서,사용자 정의 참조 실행 계획 등 입 니 다.해결 방법:일반적으로 a)사용자 가 제출 한 요청 이 메모리 부족 으로 완료 되 지 않 아 701 오류 로 표 시 됩 니 다.b)일부 clerk 의 메모리 양 을 압축 하여 사용자 의 요청 을 완성 하고 응답 지연 과 느 린 시간 을 가 져 와 야 합 니 다.검색 을 통 해 sys.dmos_memory_clerks 의 필드 Singlepages_kb,어떤 clerk 가 너무 많은 메모 리 를 사 용 했 는 지 찾 아 그 원인 을 분석 한 다음 에 해결 합 니 다.4.Multi-Page 의 압력 multi-page 는 Buffer Pool 과 OS 의 가상 주소 공간 을 공유 하고 multi-page 가 메모 리 를 너무 많이 사용 하면 Datbase pages 를 압축 합 니 다.multi-page 메모리 사용량 이 비교적 적 고 상대 적 으로 고정 되 어 발생 할 수 있 는 상황 은 a.AWE 를 열지 않 은 32 비트 SQL Server 는 2G 주소 공간 만 있 고-g 로 매개 변 수 를 확장 하 는 MemToLeave 의 상한 선 을 시작 합 니 다.b.64 비트 SQL Server 는 메모리 가 유출 된 제3자 코드 를 조정 했다.c.대량의 인자 가 있 거나 긴'IN'문 구 를 사용 합 니 다.Network Packet Size 를 높 였 고 8KB 보다 크 거나 같 으 며 이런 연결 이 많 습 니 다.e.대량의 복잡 한 XML 조회 또는 세 번 째 코드.해결 방법:sys.dm 조회 통 해os_memory_clerks 의 필드 multipages_kb,어떤 clerk 가 너무 많은 메모 리 를 사 용 했 는 지 찾 아 그 원인 을 분석 한 다음 에 해결 합 니 다.저자:Joe.TJ