| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 22. 데이터베이스 정기 점검 작업 | Fast Forward | Next |
PostgreSQL의 VACUUM커맨드는 일정한 기본에서 실행되어야만 하는 몇 가지 이유가 있습니다.
업데이트나 삭제된 행이 차지하는 디스크 영역 복구 또는 재사용
PostgreSQL 쿼리 planner에서 사용하는 데이터 통계 정보의 업데이트
트랜잭션 ID의 wraparound에 의한 매우 오래된 데이터의 손실 방지
VACUUM 연산의 사용 빈도와 범위는 각 사이트마다 다른 이유로 실행되어집니다. 그러므로 데이터베이스 관리자는 이러한 사항을 이해하고 적절한 점검 계획을 개발, 실시해야 합니다. 본 절에서는 상위 단계의 설명에 집중하겠습니다. 커맨드 구문과 관련된 사항이나 그 외의 정보는 VACUUM 참조 페이지를 살펴 보십시요.
VACUUM 표준 형식은 실행 중인 데이터베이스의 연산과 병행하여 실행될 수 있습니다. SELECT, INSERT, UPDATE, DELETE등의 커멘드는 평상시처럼 계속해서 작동합니다. 그러나 vacuuming 동안은 ALTER TABLE ADD COLUMN등의 커멘드를 사용해 테이블 정의를 변경할 수 없습니다. 또한, VACUUM에는 상당한 양의 I/O 트래픽이 요구됩니다. 때문에 다른 실행 중인 세션의 성능을 악화시키는 경우가 있습니다. 백그라운드 vacuuming의 작업효율 감소에 영향을 줄일 수 있는 설정 파라미터가 있습니다. Section 17.4.4를 참조해 주십시요.
필요한 VACUUM 연산을 수행하는 자동 매커니즘은 PostgreSQL 8.1에서 추가되었습니다. Section 22.1.4를 살펴보십시요.
보통 PostgreSQL 연산에서 행의 UPDATE나 DELETE는 오래된 버전의 행을 바로 삭제하지 않습니다. 이러한 접근 방법은 여러 버전에서 동시 제어(Chapter 12 참조)의 장점을 얻기 위해 필요합니다. 버전의 행은 다른 트랜잭션로부터 참조될 가능성이 있는 경우에는 삭제되지 않습니다. 그러나 결국에는, 오래되거나 삭제된 행에 대한 트랜잭션의 관심은 없어집니다. 필요한 디스크 용량이 무한정 늘어나는 걸 피하기 위해, 이들이 차지하는 영역은 새로운 행으로 재이용될 수 있도록 해야 합니다. 이것은 VACUUM를 실행하여 처리됩니다.
분명히, 빈번하게 업데이트 되거나 삭제되는 테이블은 드물게 갱신되는 테이블보다 자주 vacuuming이 필요로 합니다. 주기적으로 cron 작업을 설정해 놓는 것이 좋습니다. cron 작업은 VACUUM이 테이블을 선택만 하고, 변화가 적다고 보고되는 테이블을 건너뛰는 일을 합니다. 크고 무겁게 업데이트된 테이블과 크고 드물게 업데이트되는 테이블 모두를 가졌을 경우, 이 작업은 매우 유용합니다. 작은 테이블에 대한 vacuuming의 추가 코스트는 걱정하지 않으셔도 됩니다.
VACUUM커멘드는 2 종류가 있습니다. 첫 번째 형식은 "lazy vacuum"으로 알려졌으나 그냥 VACUUM로 불립니다. 이것은 테이블이나 인덱스 내의 불필요한 데이터에 대해 향후 재사용할 수 있게 표시하는 일을 합니다. 불필요한 데이터가 있는 영역은 영역이 테이블 마지막에 있거나, 배타적 테이블 락이 쉽게 얻어지는 경우를 제외하면 회수되지 않습니다 . 파일의 시작이나 중간의 불필요한 영역에 대한 파일 축소는 실행되지 않으며, 파일 내의 미사용 영역은 operating system에 반환되지 않습니다. 이런 종류의 VACUUM는 일반적인 데이터베이스 연간과 동시에 실행할 수 있습니다.
두 번째의 형식은 VACUUM FULL커멘드입니다. 이는 보다 공격적인 알고리즘을 사용하여 불필요하게 된 버전의 행이 차지하는 영역을 회수합니다. VACUUM FULL로 해방된 모든 영역은 바로 operating system에 반환되고, 테이블 데이터는 디스크상에서 물리적으로 축소됩니다. 유감스럽게도 이런 종류의 VACUUM커멘드는 VACUUM FULL이 처리 중인 테이블마다 배타적인 락을 요구합니다. 따라서, VACUUM FULL를 빈번하게 사용하면, 동시에 실행되는 데이터베이스 쿼리의 성능이 느려질 수있습니다.
VACUUM 표준 형식은 디스크 공간의 안정된 사용을 점검하는 목적으로 가장 적합합니다. 디스크 공간을 operating system에 리턴해야할 경우, VACUUM FULL —를 사용할 수 있습니다. 그러나, 곧바로 다시 할당되어질 디스크 공간이 해제된 것의 포인트는 무엇일까요? 적당하게 표준 VACUUM를 실행하는 것은 무거운 갱신이 이루어지는 테이블을 점검하기 위해 VACUUM FULL를 가끔 실행하는 것보다 훨씬 나은 방법입니다.
비슷 자동 vaccuming을 사용하지 않는 경우, 하나의 방법은 데이터베이스 전체의VACUUM를 1일 1회 사용 빈도가 낮은 시간대에 스케줄 하는 것입니다. 필요하면, 갱신이 빈번하고 무거운 테이블의 vaccuming 처리를 보다 빈번하게 실시하도록 추가해 주십시요 (매우 높은 빈도로 데이터의 업데이트를 실시하는 Installation 중에서는 매 분마다 한번씩 가장 바쁜 테이블의VACUUM를 실시하는 일도 있습니다). 1개의 클러스터에 복수의 데이터베이스가 있는 경우, 각각을 vaccuming 하는 것을 잊지 말아 주십시요. vacuumdb 프로그램이 도움을 줄 것입니다.
VACUUM FULL는 테이블 내의 대부분의 행을 삭제했을 경우 추천됩니다. 안정적인 상태의 테이블 크기는 VACUUM FULL의 보다 적극적인 방식에 의해 크게 축소될 수 있기 때문입니다. 용량의 복구를 위한 정상적인 vaccuming 처리에는 VACUUM FULL이 아닌, 일반적인 VACUUM를 사용해 주십시요.
테이블의 내용이 정기적으로 완전히 삭제될 경우, DELETE의 뒤에 VACUUM를 사용하는 것보다는 TRUNCATE를 사용하는 것이 더 좋습니다. TRUNCATE는 테이블의 모든 내용을 즉석에서 삭제합니다. 또한, 그 후에 안 쓰이는 디스크 용량을 회수하기 위해 VACUUM나 VACUUM FULL를 실시할 필요가 없습니다.
PostgreSQL쿼리 planner는 뛰어난 쿼리 계획을 작성하기 위해, 테이블의 내용에 관한 통계 정보를 의존합니다. 이 통계 정보는 ANALYZE 에 의해 수집됩니다. 이 커멘드는 자기자신이나 VACUUM의 옵션적 단계로서 호출될 수 있습니다. 합리적으로 정확한 통계 정보를 가지는 것은 중요합니다. 그렇지 않으면 비효율적인 계획을 선택해, 데이터베이스 성능을 악화킬 것입니다.
영역 복구를 위한 vaccuming 처리와 같이, 빈번한 통계 정보의 갱신은 드물게 갱신되는 테이블보다 갱신의 빈번한 테이블에게 유익합니다. 그러나 빈번하게 갱신되는 테이블이어도, 데이터의 통계적인 분포가 크게 변경되지 않으면, 통계 정보를 갱신할 필요가 없습니다. 단순한 경험 방법은 테이블 내의 열의 최소치, 최대치에 어느 정도의 변화가 있었는지를 생각하는 것입니다. 예를 들면, 행의 갱신 시각을 보관하는timestamp열의 경우, 최대치는 행이 추가와 갱신되는 것에 따라 단순하게 증가합니다. 이러한 열은 아마도, 예를 들면, Web 사이트 상의 액세스된 페이지 URL를 보관하는 열보다 빈번하게 통계 정보를 갱신할 필요가 있겠습니다. 이 URL열의 갱신 빈도도 높을 지는 모르지만, 그 값의 통계적인 분포의 변경은 상대적으로 낮을 것입니다.
특정한 테이블에 대해서 ANALYZE를 실행할 수 있습니다. 또한, 테이블의 특정한 열에만 실행할 수 있습니다. 그러므로, 어플리케이션의 요구에 상응하여 보다 빈번하게 일부 통계 정보를 갱신할 수 있는 유연성이 있습니다. 그러나 실제로는 빠른 연산이 아니라, 단지 데이터베이스 전체를 해석하는 것이 최선입니다. 모든 하나의 행을 읽는 것보다는 테이블에서 랜덤의 행을 추출해 통계 처리에 사용합니다.
Tip: 열 단위에서의ANALYZE실행 빈도의 조정은 매우 실용적이다고는 말할 수는 없지만, ANALYZE로 집계되는 통계 정보의 상세 레벨 조정을 열 단위로 실시하는 것은 유용할 수 있습니다. WHERE구로 자주 사용되어 데이터 분포의 규칙성이 거의 없는 열은, 다른 열보다 더 상세한 데이터 도수 분포가 필요할 것입니다. ALTER TABLE SET STATISTICS를 참조해 주십시요.
하루 중 사용 빈도가 낮은 때 데이터베이스 전체에 대해 ANALYZE 를 스케줄하는 것은 좋은 방법입니다. 이는 밤마다 VACUUM와 유용하게 결합될 수 있습니다. 그러나 테이블 통계정보를 변경하는 것이 상대적으로 늦은 사이트에서는 지나친 행동입니다. 보다 낮은 빈도로 ANALYZE를 실행하는 것으로 충분합니다.
PostgreSQL의 MVCC 트랜잭션의미는 트랜잭션 ID(XID) 숫자 비교가 가능한 것에 의존하고 있습니다. 현재의 트랜잭션의 XID보다 최근의 XID를 가진 버전의 행은 "미래의 것"이며, 현재의 트랜잭션로부터 보여지지 않습니다. 그러나 트랜잭션 ID의 크기에는 제한(집필 시점에서 32 비트)이 있어, 장시간(40억 트랜잭션) 가동하고 있는 클러스터는트랜잭션의 랩어라운드를 겪게 됩니다. XID의 카운터가 0으로 돌아오고 돌연에, 지난 트랜잭션이 미래의 것으로 보이도록, 즉, 출력이 보여지 않습니다. 단적으로 말하면, 파멸적인 데이터의 손실입니다 (실제는 데이터는 보관되고 있지만, 그것을 획득할 수 없으면, 소용 없을 것입니다). 이것을 막기 위해서는 전체 데이터베이스의 모든 테이블을 적어도 20억 트랜잭션 마다 vaccuming 할 필요가 있습니다.
정기적인 vaccuming 처리에 의해 이 문제가 해결되는 이유는 PostgreSQL가 특별한 XID, FrozenXID를 구별하고 있기 때문에입니다. 이 XID는 항상 모든 보통의 XID보다 낡은 것으로 간주해집니다. 보통의 XID(2이상의 값)는 modulo-231의 수식을 사용해 비교됩니다. 이는 모든 일반적인 XID에서는 20억"보다 낡은"XID와 20억"보다 새로운"XID가 존재하는 것을 의미합니다. 바꾸어 말하면, 보통의 XID 공간은 끝나지 않고 순환되고 있습니다. 그 때문에, 어느 특정한 XID인 버전의 행을 작성하면, 그 버전의 행은 이후의 20억 트랜잭션로부터는 어느 보통의 XID에 대한 비교와는 관계없이, "과거의 것"으로 인식됩니다. 그 버전의 행이 20억 트랜잭션 후에도 존재할 경우, 갑자기 미래의 것으로 인식됩니다. 이는 데이터의 손실을 막기 위해, 오래된 행 버전은 20억의 트랜잭션이 되기 전에, 이따금 XID FrozenXID 를 재설계해야 합니다. 특수한 XID에 한번 할당되면, 이들은 랩어라운드 문제에 관계없이, 모든 보통의 트랜잭션에게 "과거의 것"으로서 인식되며 또한, 버전의 행은 얼마나 긴가와 상관 없이 삭제될때까지 좋은 상태가 됩니다. 이 오래된 XID를 다시 지정하는 것은 VACUUM에 의해 다루어집니다.
VACUUM의 동작은 설정 파라미터vacuum_freeze_min_age에 의해서 제어됩니다. vacuum_freeze_min_age트랜잭션보다 낡은 XID는 모두, FrozenXID로 치환됩니다. 보다 큰vacuum_freeze_min_age값은 트랜잭션 정보를 장기간 보관합니다. 한편, 테이블의 vaccuming이 다시 실행되기 전에 작은 값들은 트랜젝션의 숫자를 계속 증가시킬 수 있습니다.
테이블이 vaccuming하지 않을 수있는 최대 시간은, 마지막 vaccuming이 끝나고 20억 트랜잭션으로부터 사용된 vacuum_freeze_min_age를 공제한 것입니다. 이 시간보다 장기간 vaccuming을 실시하지 않으면 데이터 손실이 발생합니다. 이것을 확실히 방지하기 위해서, 자동 vaccuming demon 는 autovacuum_freeze_max_age설정 파라미터로 지정되었던 기간보다 낡은 XID를 가질 가능성이 있는 임의의 테이블을 호출합니다. (이것은 자동 vaccuming을 사용할 수 없을 때도 일어납니다. )
이는 테이블이 vaccuming되어 있지 않았다면, 자동 vaccuming이 대략 autovacuum_freeze_max_age - vacuum_freeze_min_age트랜잭션마다 호출된다는 것을 의미합니다. 파티션을 위해 정상적으로 vaccuming 처리를 실시하는 테이블에서는 중요하지 않습니다. 그러나 (삽입만 하고, 갱신이나 삭제를 하지 않는 테이블을 포함) 정적인 테이블에서는 파티션을 위한 vaccuming 처리를 실시할 필요가 없어지기 때문에, 매우 장기간 정적인 테이블에서는 강제적인 자동 vaccuming간의 간격을 최대까지 늘릴 수 있습니다. 기재할 필요는 없지만, autovacuum_freeze_max_age를 늘림으로서 vacuum_freeze_min_age를 줄임으로서 실행할 수 있습니다.
autovacuum_freeze_max_age를 늘리는 것에는 1개 결점이 있습니다. 그것은 데이터베이스 클러스터의 하위 디렉토리pg_clog가 더 큰 용량이 되는 것입니다. 이것은 autovacuum_freeze_max_age의 범위까지 모든 트랜잭션의 처리 상황을 저장해야 하기 때문입니다. 처리 상황은 트랜잭션 하나 마다 2 비트 사용하기 때문에, 만약autovacuum_freeze_max_age가 최대 허용치인 2억에서 조금 적은 값을 설정한 경우, pg_clog는 약 0.5기가바이트의 용량이 될 것으로 예상할 수 있습니다. 만약 당신의 데이터베이스 총 용량과 비교해서 사소하다고 여겨질 경우는, autovacuum_freeze_max_age를 최대 허용치로 설정할 것을 권합니다. 반대일 경우는 pg_clog 용량으로 허용 할 수 있는 값에 따라 설정해 주십시요. (디폴트는 2000만 트랜잭션입니다. 환산하면 pg_clog는 대략 50 메가바이트의 용량이 됩니다. )
vacuum_freeze_min_age를 줄이는 것은 단점을 하나 가지고 있습니다. 이로 인해 VACUUM가 도움이 되지 않게 될지도 모릅니다. 테이블 행이 곧바로 변경되는 경우(새로운 XID를 획득하게 됩니다), 테이블 행의 XID를FrozenXID로 변경하는 것은 쓸데없는 작업입니다. 때문에, 이 설정은 행의 변경이 일어나지 않을 때까지, 멈추지 않을 만하게 충분한 크기여야 합니다. 설정을 줄이는 것의 다른 단점은 행을 삽입 또는 변경한 트랜잭션에 관한 정보가 곧바로 없어지는 것입니다. 이 정보는 특히, 데이터베이스 장애 후에, 무엇이 잘못 되었나를 해석하는 경우 편리합니다. 이 2개의 이유로 설정을 줄이는 것은 완전한 정적 테이블이 아닌 이상 추천되지 않습니다.
데이터베이스 내의 가장 오래된 XID의 기간을 추적하기 위해서, VACUUM는 시스템 테이블pg_class와 pg_database에 XID 통계 정보를 보관합니다. 특히, 테이블pg_class행의relfrozenxid열에는 테이블에 대한 마지막VACUUM로 사용된 동결된 cutoff XID가 포함됩니다. cutoff XID보다 오래된 모든 보통 XID는 테이블 내에서 FrozenXID에 의해 치환되는 것을 보증하고 있습니다. 비슷하게 데이터베이스 pg_database행의 datfrozenxid열은 데이터베이스 내에서 나타나는 일반적인 XID의 하한치입니다. 이는 데이터베이스 내의 테이블 마다 relfrozenxid값의 최소치입니다. 이 정보를 검사하는 간편한 방법은 이하의 쿼리를 실행하는 것입니다.
SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r'; SELECT datname, age(datfrozenxid) FROM pg_database;
age열은 cuoff XID로부터 현재의 트랜잭션 XID까지의 트랜잭션 수를 측정합니다. VACUUM 직후, age(relfrozenxid)는 사용된vacuum_freeze_min_age설정보다 약간 커질 것입니다 (VACUUM를 개시한 후, 시작된 트랜잭션의 수에 의해 커집니다). age(relfrozenxid)가 autovacuum_freeze_max_age를 초과하는 경우, 테이블에 대한 자동 vaccuming이 바로 강요되어집니다.
몇 가지 이유로 자동 vaccuming이 테이블의 오래된 XID 정리하는 것을 실패했을 경우, 시스템은 데이터베이스의 가장 오래된 XID가 랩어라운드 포인트로부터 1000만 트랜잭션에 이르렀을 경우와 같은 경고 메세지를 발행하기 시작합니다.
WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb".
이러한 경고가 무시되면, 시스템은 정지하고 랩어라운드할 때까지 100만보다 트랜잭션이 적은 새로운 트랜잭션운 실행을 거절당합니다.
ERROR: database is shut down to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
100만 트랜잭션라고 하는 안전 마진은 관리자가 필요한 VACUUM커멘드를 수동으로 실행하는 것으로, 데이터 손실 없이 복원 할 수 있도록 하기 위해 존재합니다. 그러나 시스템이 안전 정지 모드가 되면, 커멘드를 실행하지 않으므로, 실행을 위해서는 서버를 정지하고 싱글 유저 백엔드로 VACUUM를 실행하는 것 외에 없습니다. 정지 모드는 싱글 유저 백엔드로 강요되지 않습니다. 싱글 유저 백엔드 사용에 관한 자세한 사항은 postgres 메뉴얼 페이지를 참조해 주십시요.
PostgreSQL 8.1을 시작으로 자동 vaccuming 이라고 불리는 별도의 선택 가능한 서버 프로세스가 있습니다. 이것은 VACUUM와 ANALYZE커멘드의 실행을 자동화하는 것을 목적으로 합니다. 활성화 되면, 자동 vaccuming은 대량의 튜플 삽입, 갱신, 삭제가 이루어졌던 테이블을 검사합니다. 이 검사는 행 수준의 통계 정보수집 기능을 사용합니다. 따라서, stats_start_collector와 stats_row_level가 true로 설정되어 있지 않으면 자동 vaccuming daemon을 사용할 수 없습니다. 또한, superuser_reserved_connections 의 값을 선택할 때 자동 vaccuming 프로세스를 위한 슬롯을 허가하는 것은 중요합니다.
자동 vaccuming daemon이 가능할 경우, 매 autovacuum_naptime초 실행됩니다. 각각의 실행에서, 처리하기 위해 하나의 데이터베이스를 선택하고, 그 데이터베이스 내의 각 테이블을 검사합니다. VACUUM나 ANALYZE 커맨드는 필요할 때 지시됩니다.
테이블의 relfrozenxid값이 autovacuum_freeze_max_age트랜잭션보다 오래된 경우, 그 테이블은 항상 vaccuming 됩니다. 그와 반대일 때는 적용할 연산을 결정하기 위해 2개의 조건을 사용됩니다. 마지막 VACUUM의 뒤에 안 쓰이는 튜플수가 "vaccuming threshold"을 초과하면, 테이블은 vaccuming 됩니다. 이 vaccuming threshold은 이하와 같이 정의됩니다.
vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples
여기서, vaccuming 기초 threshold은autovacuum_vacuum_threshold, vaccuming 스케일 계수는autovacuum_vacuum_scale_factor, 튜플 수는pg_class. reltuples입니다. 안 쓰이는 튜플 수는 통계 수집가로부터 얻어집니다. 이는 각 UPDATE, DELETE 연산으로 갱신되는 거의 정확한 수입니다. (높은 부하로 일부 정보는 손실될 수 있기 때문에, 이것은 거의 정확한 수입니다.) 분석을 위해서 비슷한 조건이 사용됩니다.
analyze threshold = analyze base threshold + analyze scale factor * number of tuples
이하에 정의되는 threshold이 마지막 ANALYZE의 뒤에 삽입, 갱신된 튜플 수로 비교됩니다.
디폴트 threshold과 스케일 계수는 postgresql.conf로부터 얻어지지만, pg_autovacuum 시스템 카탈로그에 항목을 생성하는 것으로, 테이블마다 겹쳐 쓰는 것이 가능합니다. 특정한 테이블에 대해서pg_autovacuum행이 존재할 경우, 그곳에 지정한 설정이 적용됩니다. 그와 반대일 경우, 전체적인 설정이 사용됩니다. 전체적인 설정에 관한 자세한 사항은 Section 17.9을 참조해 주십시요.
기본 threshold과 스케일 계수 외에, pg_autovacuum의 각 테이블에 대해 5개 이상의 파라미터를 설정할 수 있습니다. 1 번째는 pg_autovacuum.enabled로, false로 설정하여 자동 vacuumming demon이 테이블 전체를 건너 뛰도록 지시합니다. 이 경우 자동 vacuumming은 트랜잭션 ID의 랩어라운드를 막아야 할 때만 테이블을 대상으로 합니다. 다음의 2개의 파라미터, vaccuming 코스트 지연(pg_autovacuum.vac_cost_delay)와 vaccuming 코스트 제한(pg_autovacuum. vac_cost_limit)입니다. 이것들은 코스트에 근거하는 Vacuum 지연 기능용으로 테이블 고유의 값을 설정하기 위해 사용됩니다. 마지막 2개의 파라미터(pg_autovacuum.freeze_min_age) 및pg_autovacuum.freeze_max_age)는 각각 테이블 지정 값을 vacuum_freeze_min_age, autovacuum_freeze_max_age를 위해 설정하는 데 사용됩니다.
pg_autovacuum내의 값의 일부가 음의 숫자로 설정되었거나 특정한 테이블을 위한 pg_autovacuum에 행이 존재하지 않는 경우, postgresql.conf내의 대응되는 값이 사용됩니다.
현시점에서는 pg_autovacuum카탈로그에 항목을 생성하려면, 수동으로 카탈로그에 INSERT할 수 밖에 없습니다. 이 기능은 향후의 릴리스로 개선 될 예정입니다. 또한, 카탈로그의 정의도 변경될 예정입니다.
| Caution |
|
현재 pg_autovacuum시스템 카탈로그의 내용은 pg_dump와 pg_dumpall툴로 작성된 데이터베이스 덤프에 저장되지 않습니다. 덤프/리로드의 과정에서 이들을 보관하고 싶을 경우, 카탈로그를 수동으로 확실히 덤프하여 주십시요. |