| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 27. 신뢰성과 로그 선행 기입 | Fast Forward | Next |
데이터베이스의 성능에 영향을 주는 WAL에 관련한 설정 매개변수가 다수 있습니다. 본절에서는, 그 사용법을 설명합니다. 서버 설정 매개변수의 설정 방법에 대한 자세한 것은 Chapter 17을 참조해 주세요.
체크포인트 는, 일련의 트랜잭션에서, 쓰여진 모든 정보가 데이터 파일이 체크 포인트 전에 갱신되고 있는지 보증하는 시점을 가리킵니다. 체크 포인트에서는, 모든 더티 데이터 페이지가 디스크에 내보내져, 특별한 체크 포인트 레코드가 로그 파일에 기입됩니다. 크래쉬 했을 때, 크래쉬 복구 처리는 마지막 체크 포인트 기록을 찾아내 로그 안에서 어느 레코드(redo 레코드로 불리는)로부터 복구 처리가 REDO 로그 조작을 시작해야할 것인가를 결정합니다. 이 체크 포인트 이전에 변경된 데이터는, 벌써 디스크상에 있는 것으로 알려져 있습니다. 따라서, 체크 포인트를 한 후, REDO 기록 내의 체크 포인트 이전의 로그 세그멘트는 불필요해져, 재이용 또는 삭제할 수가 있습니다 (WAL아카이브(archive)를 하는 경우, 이 로그 세그멘트는 삭제 혹은 재이용 되기 전에 보존되어야 합니다).
서버의 백그라운드 쓰기 프로세스는 자동적으로 체크 포인트를 빈번하게 실행합니다. checkpoint_segments로그 세그멘트 수에 이르는지, 또는 checkpoint_timeout초가 경과하는지, 둘 중 하나의 조건이 채워지면 체크 포인트가 작성됩니다. 기본값은 3 세그멘트와 300초가 각각 설정되고 있습니다. 또, CHECKPOINT SQL 명령을 사용해 강제적으로 체크 포인트를 작성할 수도 있습니다.
checkpoint_segments, checkpoint_timeout, 또는 둘 다 감소시키면, 체크 포인트는 보다 빈번하게 행해집니다. 이것에 의해, (재처리해야 할 일이 적기 때문에) 크래쉬 후의 복귀는 빨라집니다. 그러나, 보다 빈번하게 행해지는, 변경된 데이터 페이지의 출력으로 인해 증가하는 비용와 균형을 생각하지 않으면 안됩니다. full_page_writes는 설정된 경우(기본값으로), 그 밖에 고려해야 할 점이 있습니다. 데이터 페이지의 일관성을 보증하기 위해서, 각 체크 포인트 후에 최초로 변경되는 데이터 페이지는, 그 페이지 전체의 내용이 로그에 보존되게 됩니다. 이러한 경우, 체크 포인트의 간격을 줄이는 것은, WAL 로그에의 출력을 증가시켜, 간격을 짧게 하는 목적을 무의미하게 하며, 보다 많은 디스크 I/O가 발생합니다.
체크 포인트는 꽤 고가입니다. 1번의 이유는, 이 처리는 현시점의 모든 더티 버퍼를 써내야 한다는 것, 2번째의 이유는, 상기와 같이 그 후에 불필요한 WAL의 기입이 발생하는 것입니다. 그 때문에, 체크 포인트의 매개변수를 높게 해, 체크 포인트가 너무 빈발하는 것이 없게 하는 것을 권합니다. 간단한 체크 포인트의 매개변수의 건전성 검사로서 checkpoint_warning매개변수를 설정할 수가 있습니다. 체크 포인트의 발생 간격이checkpoint_warning초의 경우, checkpoint_segments의 증가를 권하는 메세지가 서버의 로그에 출력됩니다. 이 메세지가 드물게 나타났다고 해도 문제가 되지 않습니다만, 빈출하는 것 같으면, 체크 포인트의 제어 매개변수를 증가시켜야 합니다. checkpoint_segments를 충분히 높게 설정하고 있지 않으면 대규모COPY전송 등의 일괄 작업으로 이러한 경고가 많이 발생할지도 모릅니다.
WAL 세그멘트 파일은 항상 적어도 1개 있으며, 일반적으로 (2 + checkpoint_completion_target)×checkpoint_segments + 1보다 많지는 않습니다. 각 세그멘트 파일은 통상 16 메가바이트(이 사이즈는 서버의 컴파일시로 변경 가능)입니다. 이것으로부터, WAL로 필요하게 되는 영역을 추정할 수 있습니다. 보통, 낡은 세그멘트 파일이 불필요하게 되었을 때, 그것들은 재이용(차례로 다음 세그멘트가 되도록 이름을 변경)됩니다. 단시간의 로그 출력의 최고치 때문에, 세그멘트 파일수가 3×checkpoint_segments + 1을 넘었을 경우, 시스템은, 이 제한 최고치 이하가 될 때까지, 불필요하게 된 세그멘트 파일을 재이용하지 않고, 삭제합니다.
자주 사용되는 2개의 내부WAL함수가 있습니다.
LogInsert와 LogFlush입니다.
LogInsert는 공유 메모리상의 WAL버퍼에 새로운 레코드를 삽입합니다.
새로운 레코드를 삽입할 여지가 없을 때, LogInsert는 만배가 된 WAL버퍼를 기입(커넬 캐쉬에 이동) 해야 합니다.
이것은 바람직한 일이 아닙니다.
왜냐하면, 데이터베이스에 저레벨의 변경(예를 들면 행의 삽입)에 LogInsert가 불러지지만,
그러한 경우에는 변경을 받은 페이지에 대해서 단독 락이 걸려있으므로, 이 조작은 가능한 한 빠르게 실행되어야 합니다.
더 안좋은 것은, WAL버퍼에 기입 시에, 한층 더 시간이 걸리는, 강제적인 새로운 로그 세그멘트의 생성이 필요할지도 모릅니다.
일반적으로, WAL의 기입과 호출은 LogFlush요구로 실시됩니다.
이것은 대부분의 경우, 트랜잭션 커밋 시에 영구적인 기억 영역에 트랜잭션 레코드가 내보내지는 것을 보증하기 위해서 행해집니다.
로그 출력이 대량으로 행해지는 시스템에서는, LogInsert에 의해 필요한 기입을 막을 정도로는
LogFlush요구가 빈번하게 일어나지 않을지도 모릅니다.
그러한 시스템에서는, wal_buffers설정 매개변수를 변경해 WAL버퍼의 수를 늘려 주세요.
기본값의 WAL버퍼의 수는 8입니다.
이 수를 늘리면 공유 메모리의 사용량에 영향이 있습니다.
full_page_writes이 설정되어, 시스템이 고부하 상태인 경우, 이 값을 높게 해, 각 체크 포인트의 직후 응답 시간을 매끄럽게 할 수 있습니다.
commit_delay매개변수는, LogInsert가 커밋 레코드를 로그에 기입하고,
그러나, LogFlush를 하기 전에, 서버 프로세스가 몇 마이크로초 휴지하는지를 정의합니다.
이 지연에 의해, 다른 서버 프로세스가 커밋 레코드를 로그에 기입한 후, 그 모든 로그 레코드를 1회의 로그 동시에 내보낼 수 있습니다.
fsync 무효인 경우나, commit_siblings보다 적은 수의 세션이 현재 활동 중인 트랜잭션을 하지 않는 경우는,
휴지하지 않습니다.
이에 의해, 곧바로 커밋할 세션이 없을 것 같은 때에도, 휴지하는 것을 막을 수가 있습니다.
대부분의 플랫폼에서는, 휴지의 최소단위는 10 마이크로초인 것에 주의해 주세요.
그래서, 1마이크로초에서 10,000마이크로초 사이에서의, 0이 아닌 commit_delay의 설정은, 같은 효과를 가지게 될 것입니다.
이러한 매개변수의 적절한 값은 아직 명확하지는 않습니다. 실험이 필요합니다.
wal_sync_method매개변수는 PostgreSQL가 커넬에 대해서 WAL을 디스크에 갱신하는 것을 요구하는 방법을 결정합니다. 어떤 설정에서도 신뢰성은 같지만, 가장 빠른 것은 플랫폼 설정에따라 다릅니다. 덧붙여서, 이 매개변수는 fsync가 무효가 된 경우에는 도움이 되지 않습니다.
wal_debug설정 매개변수를 유효하게 하는 것으로,
LogInsert와LogFlush라고 하는 WAL호출은 매회 서버 로그에 로그가 남습니다
(이 매개변수를 지원하도록 PostgreSQL를 컴파일 할 필요가 있습니다).
후에, 이 옵션은 보다 일반적인 기계에 옮겨질 가능성이 있습니다.