FAQ
체크포인트(checkpoint)에 관하여
분류 일반 등록일 2013-05-23 조회수 4256

체크포인트
     모든 변경된 데이터 페이지가 disk에 write 됩니다.
     io 수행 횟수 증가로, io bottleneck이 발생, 현재 트랜잭션의 수행에 영향을 미칠 수 있음.
     로그 디렉토리와 데이타 디렉토리를 분리할 경우, 영향 감소.

altibase.properties
     BUFFER_CHECK_POINT_INTERVAL_IN_FLUSH = 60 : DRDB의 체크포인트 수행 주기
     CHECK_POINT_INTERVAL_IN_SEC = 6000 : 체크 포인트 주기를 초 단위 시간으로 설정
     CHECK_POINT_INTERVAL_IN_LOG = 100 : 체크포인트 주기를 로그 파일이 생성되는 횟수로 설정

이 프로퍼티 값에 의해 체크포인트 요구가 발생할 당시 이미
체크포인트가 진행 중이거나 기타 다른 이유로 인하여
체크포인트가 수행되지 못하는 경우가 발생할 수 있다. 이 경우
이미 진행 중인 체크포인트가 끝난 후 바로 체크포인트를
수행하는 것이 아니라 현재의 체크포인트 요구는 바로
취소된다. 따라서, 최대 다음 체크포인트 요구는 이 프로퍼티에
설정된 값만큼 로그 파일이 새로 생기는 시점이 될 수 있다.

알티베이스 가동 중 ALTER SYSTEM 문을 이용하여 이
세가지 프로퍼티의 값을 변경할 수 있습니다.

Checkpoint 는 수행 중 최대 1개의 CPU와 높은 disk I/O를 유발하게 됩니다.
사이트 속성에 따라 checkpoint 주기를 짧게, 혹은 길게 가져갈 수 있는데

만약 이 주기를 6000 초로 설정한다면
6000 초 동안 변경된 page들을 disk image (?/dbs/mydb-0-x 파일) 에 반영하게 됩니다.
동일하게 600초로 설정한다면 600초 동안 변경된 page 만큼 반영하게 됩니다.

4.3.9.x 버전의 메모리쪽 page 크기가 32K 이므로 600초 동안 1000개의 페이지가 변경이 되었다면
32K * 1000, 즉 32M의 디스크 I/O가 발생하게 됩니다.
6000 초로 설정한 경우는 동일한 작업부하가 주어졌다면 최대 10000개의 페이지가 변경되겠지만,
한번 변경된 페이지가 다시 변경되는 경우가 있으므로
만약 중복비율이 20%정도라면 32M * 10의 DISK I/O 가 아닌 32M * 8 정도의 I/O 만 발생하게 됩니다.

즉 전체 I/O 의 총합 측면에서는 checkpoint 주기가 긴 것이 이득이 있으나
한번 checkpoint 시에 수행시간이 길어지므로 일반 app이 느끼는 성능편차가 더 심하게 됩니다.

사이트 사례를 보면
1> 증권사 업무와 같이 균일한 응답이 필요한 업무의 경우
     checkpoint 주기를 12시간이상 길게 설정하여
     장중에는 checkpoint가 발생하지 않도록 할 수 있고,
2> Tx이 지속적으로 높고, HW 사양이 높은 경우,
     오히려 checkpoint 주기를 아주 짤게 하여 계속 발생하게 할 수 있으며
3> HW 사양이 아주 낮은 경우, CHECKPOINT 주기 조절이 아니고
     checkpoint 수행히 sleep을 주어 수행하는 옵션을 적용하여
     느리게 처리하게 할 수 있습니다만
default 속성으로 운영하는 경우가 많습니다.

* CHECKPOINT 여부 trace

   체크포인트 발생시, $ALTIBASE_HOME/trc/altibase_sm.log 파일에 다음과 같이 로그가 남습니다. (altibase 4)
   [2007/09/19 14:43:40] [Thread-3] [Level-9]
   [CHECKPOINT-BEGIN]
   [2007/09/19 14:43:41] [Thread-3] [Level-9]
   [CHECKPOINT-END]

   altibase3 의 경우, $ALTIBASE_HOME/trc/altibase_boot.log에 남습니다.
목록