Direct /Indirect 비교
direct checkpoint
- 동작 방식 : checkpoint 수행시, 메모리 내의 모든 페이지를 탐색하는 대신, BUF 배열을 생성하고 배열 전체를(시작부터 끝)을 탐색한다.
(이 말이 , data buffer 내 정렬을 한다는 의미는 아님, 페이지들은 메모리내에 무작위로 분산)
변경된 페이지(Dirty Page)가 발견되면 해당 페이지 주변의 페이지 블럭과 함께 디스크에 기록한다.
2012 - 32개씩 / 2016- 128개씩
- 효과 : HW IO 레벨에서 페이지를 정렬하는 Elavator Seek 문제를 피할 수 있다.
- 공식 : (로그레코드 * 복구를 위한 고정시간) > 복구 시간(Recovery Interval) 설정값 = 자동 체크포인트 큐잉
- 예시) 체크 포인트 로직
Is BUF[0] Dirty - No - Skip
Is BUF[1] Dirty - Yes - Write with gather near
indirect checkpoint
- 동작방식 : 간접 체크포인트는 이 'PrepareToDirty' 로직을 활용하며, Dirty Page 관리자에 의해 관리되는 변경페이지 목록에 Dirty Page를 LSN 순으로 정렬 및 추가
분할된 목록에서 페이지 ID 오름차순으로 정렬하여 내보내고(Swap) WriteFileGather를 활용하여 변경된 블록 혹은 페이지 집합을 기록
- 효과 : 전체 버퍼 집합을 탐색하여 변경페이지를 찾는 driect 대비 관리목록만 탐색 (변경된 페이지만 기록)
- 동작 기준 : TARGET_RECOVERY_TIME 설정값 (상세 공식은 찾지 못하였으며 direct와 유사할것으로 추정)
- 권장 시스템 : 4TB 시스템 = ~5억 개의 SQL Server BUF 구조
SQL Server 2016에서의 Checkpoint 변경사항
- 기본 체크포인트 방식 : Indriect Checkpoint
- ~SQL Server 2014 는 Direct Checkpoint가 기본 설정
- 2016에서 생성된 신규 DB가 적용되는 사항
- 업그레이드되거나 이전 버전에서 복원된 DB는 기존의 설정을 유지 (자동 검사점)
- 2016 버전에서의 변화
- Direct checkpoint 부하
- 아래의 사유로 2014대비 Checkpoint page/sec의 Peak가 높아질 수 있음
- I/O의 응답 시간 임계값을 기준으로 Outstanding I/O양을 조절
- Avg. Disk sec/Write : 2014 - 20ms / 2016-50ms
- 데이터 페이지가 물리적 수준에서 연속적일 경우 단일 물리적 전송으로 통합
- max size for a transfer : 2014-256K / 2016-1M
- InDriect checkpoint 부하
- 지속적인 백그라운드 쓰기로 인한 IO 점유가 발생할 수 있음
- 변경된 페이지에 대해 지속적으로 DISK에 쓰는 동작이 발생하며, 해당 동작을 함에도 TARGET_RECOVERY_TIME 초과시 Checkpoint 발생
- constant background writes of modified data pages vs. periodic flushes of modified pages
고찰
- 대용량 메모리 시스템의 경우 ,
- Direct Checkpoint 로직 (전체 버퍼 집합을 탐색)의 부하 수준이 클 것으로 보여 지속적으로 background Writer가 동작하는 InDriect가 좋을 것으로 보임
- 대용량이 아니며 간혈적 트래픽이 폭증하는 형태(짧은주기) 일 경우,
- 주기적 IO와 메모리내 연산을 하는 Indirect보다는 Checkpoint IO제한 + Direct checkpoint가 좋을것으로 보임
URL