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에 남습니다. |