23.1. 일상적인 진공 범퍼카 토토

23.1.1. 진공청소기 기본 사항

포스트그레SQL's진공명령은 각 테이블을 한 번에 처리해야 합니다. 여러 가지 이유로 정기적으로:

1. 업데이트되거나 삭제된 디스크 공간을 복구하거나 재사용하려면 행.

2. 다음에서 사용하는 데이터 통계를 업데이트하려면포스트그레SQL쿼리 플래너.

3. 가시성 지도를 업데이트하여 색인 전용 속도를 높이려면 스캔합니다.

4. 다음으로 인해 매우 오래된 데이터의 손실을 방지하기 위해트랜잭션 ID 랩어라운드또는Multixact ID 랩어라운드.

이러한 각 이유는 수행을 결정합니다.진공다양한 빈도와 범위의 작업 다음 하위 섹션에서 설명합니다.

다음에는 두 가지 변형이 있습니다.진공: 기준진공그리고진공이 가득 참. 진공 가득 참더 많은 디스크 공간을 확보할 수 있지만 훨씬 더 느리게 실행됩니다. 또한, 의 표준형진공실행 가능 프로덕션 데이터베이스 작업과 병행합니다. (다음과 같은 명령)선택, 삽입, 업데이트및삭제그러나 계속해서 정상적으로 작동할 것입니다. 다음을 사용하여 테이블 정의를 수정할 수 없습니다. 다음과 같은 명령은테이블 변경그동안 진공 청소기로 범퍼카 토토 중입니다.)진공이 가득 참요구됨 작업 중인 테이블에 대한 배타적 잠금이 있으므로 이를 수행할 수 없습니다. 테이블의 다른 사용과 동시에 수행됩니다. 일반적으로, 따라서 관리자는 표준을 사용하도록 노력해야 합니다.진공그리고 피하세요진공 가득한.

진공상당한 양의 생성 다른 활성 시스템의 성능 저하를 유발할 수 있는 I/O 트래픽 세션. 조정할 수 있는 구성 매개변수가 있습니다. 백그라운드 진공청소로 인한 성능 영향을 줄이기 위해 — 참조섹션 18.4.4.

23.1.2. 디스크 공간 복구 중

에포스트그레SQL,업데이트또는삭제행의 행의 이전 버전을 즉시 제거하지 않습니다. 이것 다중 버전의 이점을 얻으려면 접근 방식이 필요합니다. 동시성 제어(MVCC, 참조13장): 행 버전은 다음과 같을 수 없습니다. 잠재적으로 다른 사람에게 표시되는 동안 삭제되었습니다. 업무. 그러나 결국 오래되거나 삭제된 행 버전은 더 이상 어떤 거래에도 관심이 없습니다. 그것이 차지하는 공간 그런 다음 새로운 행에서 재사용할 수 있도록 회수해야 합니다. 디스크 공간 요구 사항 증가. 이는 다음을 실행하여 수행됩니다.진공.

의 표준형진공제거 테이블과 인덱스의 데드 로우 버전을 확인하고 공간을 표시합니다. 향후 재사용이 가능합니다. 그러나 공간을 반환하지는 않습니다. 단, 특별한 경우를 제외하고는 운영 체제에 하나 또는 테이블 끝에 있는 더 많은 페이지가 완전히 무료가 되고 전용 테이블 잠금 장치를 쉽게 얻을 수 있습니다. 대조적으로,진공 가득 참적극적으로 테이블을 압축합니다. 데드 없이 완전히 새로운 버전의 테이블 파일 작성 공간. 이렇게 하면 테이블 크기가 최소화되지만 시간이 오래 걸릴 수 있습니다. 시간. 또한 새 복사본을 위한 추가 디스크 공간이 필요합니다. 작업이 완료될 때까지 테이블에 보관됩니다.

일상적인 진공 청소의 일반적인 목표는 표준을 수행하는 것입니다.진공필요를 피할 수 있을 만큼 자주진공 가득 참. Autovacuum 데몬이 작동을 시도합니다. 이런 식으로 실제로 발행되지 않습니다.진공 가득한. 이 접근 방식에서는 테이블을 다음과 같이 유지하는 것이 아닙니다. 최소 크기이지만 디스크의 안정적인 사용 상태를 유지하기 위해 공간: 각 테이블은 최소 크기에 해당하는 공간을 차지합니다. 게다가 진공 청소기로 청소하는 사이에 많은 공간이 사용됩니다. 하지만진공 가득 참테이블을 축소하는 데 사용할 수 있습니다. 최소 크기로 돌아가 디스크 공간을 운영 체제로 되돌립니다. 시스템에서 테이블이 계속 커지면 별 의미가 없습니다. 앞으로도 다시. 따라서 중간 빈도 표준진공실행은 드물게 실행하는 것보다 더 나은 접근 방식입니다.진공이 가득 참유지관리를 위해 실행됩니다. 많이 업데이트된 테이블입니다.

일부 관리자는 스스로 진공 청소 일정을 잡는 것을 선호합니다. 부하가 적은 밤에 모든 작업을 수행하는 예입니다. 그만큼 정해진 일정에 따라 진공청소기를 청소하는 것이 어렵습니다. 테이블의 업데이트 활동이 예기치 않게 급증하는 경우 너무 부풀어 오르다진공이 가득 참공간을 확보하려면 정말 필요합니다. Autovacuum 데몬 사용 데몬이 진공 청소를 예약하므로 이 문제가 완화됩니다. 업데이트 활동에 따라 동적으로 반응합니다. 비활성화하는 것은 현명하지 않습니다. 극도로 예측 가능한 경우가 아니면 데몬을 완전히 삭제합니다. 작업량. 가능한 절충안 중 하나는 데몬의 매개변수를 설정하는 것입니다. 비정상적으로 과도한 업데이트 활동에만 반응하므로 예정된 동안 일이 통제되지 않도록 유지진공s는 다음과 같은 경우에 대부분의 작업을 수행할 것으로 예상됩니다. 부하는 일반적입니다.

autovacuum을 사용하지 않는 경우 일반적인 접근 방식은 다음과 같습니다. 데이터베이스 전체 예약진공하루에 한 번 사용량이 적은 기간에는 더 자주 진공청소기로 보충 필요에 따라 크게 업데이트된 테이블. (일부 설치에서는 매우 높은 업데이트 속도로 가장 바쁜 테이블을 최대한 자주 진공 청소합니다. 몇 분에 한 번씩.) 하나의 데이터베이스에 여러 개의 데이터베이스가 있는 경우 클러스터, 잊지 마세요진공각각; 프로그램vacuumdb도움이 될 것 같아요.

23.1.3. 플래너 업데이트 중 통계

그포스트그레SQL쿼리 플래너 테이블 내용에 대한 통계 정보에 의존합니다. 쿼리에 대한 좋은 계획을 생성하기 위해. 이 통계는 에 의해 수집됨PostgreSQL : 문서 : 9.3 : 토토 커뮤니티명령, 단독으로 호출하거나 다음의 선택적 단계로 호출할 수 있습니다.진공. 합리적으로 정확하게 파악하는 것이 중요합니다. 그렇지 않으면 계획을 잘못 선택하면 데이터베이스 성능이 저하될 수 있습니다. 성능.

autovacuum 데몬이 활성화되면 자동으로 실행됩니다분석다음의 내용이 나타날 때마다 명령합니다. 테이블이 충분히 변경되었습니다. 그러나 관리자는 다음을 수행할 수 있습니다. 수동으로 예약하는 것을 선호함분석작업, 특히 다음과 같이 알려진 경우 테이블의 업데이트 활동은 통계에 영향을 미치지 않습니다."흥미롭다"열. 데몬 일정분석엄격히 함수로서 삽입되거나 업데이트된 행 수 그것은 지식이 없다 그것이 의미 있는 통계적 변화로 이어질지 여부.

공간 복구를 위한 진공 청소와 마찬가지로 자주 업데이트되는 통계는 테이블보다 자주 업데이트되는 테이블에 더 유용합니다. 거의 업데이트되지 않는 것. 그러나 크게 업데이트된 테이블의 경우에도 통계가 다음과 같은 경우 통계 업데이트가 필요하지 않을 수 있습니다. 데이터 분포는 크게 변하지 않습니다. 간단한 규칙 엄지손가락은 최소값과 최대값이 얼마인지 생각하는 것입니다. 테이블의 열이 변경됩니다. 예를 들어,타임스탬프행 업데이트 시간이 포함된 열 행이 추가됨에 따라 최대값이 지속적으로 증가합니다. 업데이트되었습니다. 그러한 열은 아마도 더 자주 필요할 것입니다 예를 들어 페이지의 URL이 포함된 열보다 통계가 업데이트됩니다. 웹사이트에서 접속함. URL 열은 다음과 같이 변경 사항을 수신할 수 있습니다. 자주 발생하지만 해당 값의 통계적 분포는 아마도 상대적으로 느리게 변경됩니다.

실행이 가능합니다분석켜짐 특정 테이블, 심지어는 테이블의 특정 열만 포함하므로 일부 통계를 보다 자주 업데이트할 수 있는 유연성이 있습니다. 귀하의 응용 프로그램에 필요한 경우 다른 것. 그러나 실제로는 일반적으로 전체 데이터베이스를 분석하는 것이 가장 좋습니다. 빠른 작업.분석다음을 사용합니다 통계적으로 테이블 행을 무작위로 샘플링하는 것이 아니라 모든 행을 읽습니다.

23.1.4. 가시성 업데이트 지도

진공은 a를 유지합니다롤 토토 : 문서 : 9.3 : 가시성 맵각 테이블에 대해 어떤 페이지에 튜플만 포함되어 있는지 추적 모든 활성 트랜잭션(그리고 모든 페이지가 다시 수정될 때까지 향후 거래). 이것은 두 가지 목적. 첫째, 진공청소기 자체는 다음 페이지에서 이러한 페이지를 건너뛸 수 있습니다. 달려라, 정리할 게 없으니까.

둘째, 그것은 허용합니다PostgreSQL에 인덱스를 참조하지 않고 인덱스만 사용하여 일부 쿼리에 응답합니다. 기본 테이블. 부터포스트그레SQL색인에는 튜플 가시성 정보가 포함되어 있지 않습니다. 일반 색인 scan은 일치하는 각 인덱스 항목에 대해 힙 튜플을 가져와서 확인합니다. 현재 트랜잭션에서 표시되어야 하는지 여부입니다. 안색인 전용 스캔23752_24101

23.1.5. 거래 ID 방지 랩어라운드 실패

포스트그레SQL의 MVCC 거래 의미론은 트랜잭션 ID를 비교할 수 있는지에 따라 달라집니다. (XID) 숫자: 행 버전 현재 트랜잭션의 XID보다 큰 삽입 XID가 있는 경우"미래에"그러면 안 됩니다 현재 거래에 표시됩니다. 하지만 거래 ID에는 제한된 크기(32비트) 오랫동안 실행되는 클러스터(더 40억 건 이상의 거래)이 어려움을 겪을 것입니다.트랜잭션 ID 랩어라운드: XID 카운터가 래핑됩니다. 0에 가까워졌고 갑자기 거래가 발생했습니다. 과거는 미래에 있는 것처럼 보입니다. 이는 결과가 다음과 같이 됨을 의미합니다. 보이지 않는. 즉, 치명적인 데이터 손실입니다. (실제로 데이터는 아직 거기 있지만, 접근할 수 없다면 그것은 차갑고 위안이 됩니다.) 이를 방지하려면 모든 데이터베이스의 모든 테이블을 정리해야 합니다. 20억 건의 거래마다 최소 한 번씩.

주기적인 진공 청소로 문제가 해결되는 이유는 다음과 같습니다.PostgreSQL특별한 XID를 예약합니다 처럼FrozenXID. 이 XID는 다음을 따르지 않습니다. 일반적인 XID 비교 규칙이며 항상 다음보다 오래된 것으로 간주됩니다. 모든 일반 XID. 일반 XID는 다음을 사용하여 비교됩니다. 모듈로-2³²산술. 이는 모든 정상에 대해 XID에는 20억 개의 XID가 있습니다."나이가 많은"그리고 20억이"최신"; 또 다른 말로 하면 정상적이라는 것이다. XID 공간은 끝점이 없는 원형입니다. 그러므로 한 줄에 한 번씩 버전이 특정 일반 XID로 생성되었습니다. 버전은 다음과 같습니다."과거에"다음 20억 트랜잭션의 경우, 어떤 일반 XID에 관계없이 우리는 이야기하고 있습니다. 이후에도 행 버전이 여전히 존재하는 경우 20억 건 이상의 거래가 발생하면 갑자기 미래. 이를 방지하려면 이전 행 버전을 다시 할당해야 합니다. XIDFrozenXID그들이 도달하기 전에 언젠가 20억 건의 거래가 이루어진 기록입니다. 일단 할당되면 특수 XID는 다음과 같습니다."에서 과거"랩어라운드에 관계없이 모든 일반 거래에 적용 문제가 있으므로 해당 행 버전은 삭제될 때까지 유효합니다. 그게 얼마나 오래 걸리든 상관없어요. 이전 XID의 재할당이 처리됩니다. 에 의해진공.

vacuum_freeze_min_ageXID 값이 대체되기까지의 기간을 제어합니다.FrozenXID. 이 설정의 더 큰 값 거래 정보는 더 오래 보존하고 가치는 더 작게 유지 이전에 경과할 수 있는 트랜잭션 수를 늘립니다. 테이블을 다시 진공청소해야 합니다.

진공일반적으로 그렇지 않은 페이지를 건너뜁니다. 데드 행 버전이 있지만 해당 페이지에는 여전히 행이 있을 수 있습니다. 이전 XID 값이 있는 버전. 모든 이전 XID가 삭제되었는지 확인하려면 다음으로 대체됨FrozenXID, 전체 스캔 테이블이 필요합니다.vacuum_freeze_table_age언제 제어진공그렇습니다: 전체 테이블이 완전히 스캔되지 않은 경우 테이블 스윕이 강제 실행됩니다.vacuum_freeze_table_age마이너스vacuum_freeze_min_age거래. 0으로 설정 힘진공항상 모든 페이지를 스캔하려면, 가시성 맵을 효과적으로 무시합니다.

테이블이 비워지지 않을 수 있는 최대 시간은 20억입니다. 거래 마이너스vacuum_freeze_min_age당시의 값진공마지막으로 전체 테이블을 스캔했습니다. 그렇다면 그보다 오랫동안 진공 상태로 있으면 데이터가 손실될 수 있습니다. 에게 이런 일이 발생하지 않도록 하려면 autovacuum이 호출됩니다. 지정된 연령보다 오래된 XID를 포함할 수 있는 테이블 구성 매개변수autovacuum_freeze_max_age. (이것은 autovacuum이 비활성화된 경우에도 발생합니다.)

이것은 테이블이 달리 진공청소되지 않으면, autovacuum은 대략 한 번씩 호출됩니다.autovacuum_freeze_max_age마이너스vacuum_freeze_min_age거래. 테이블의 경우 공간 회수를 위해 정기적으로 진공 청소를 합니다. 중요성이 거의 없습니다. 그러나 정적 테이블(테이블 포함)의 경우 삽입을 수신하지만 업데이트나 삭제는 받지 않음), 필요하지 않습니다. 공간 회수를 위해 진공 청소기로 청소하는 것이 유용할 수 있습니다. 매우 큰 경우 강제 autovacuum 사이의 간격을 최대화합니다. 정적 테이블. 분명히 다음 중 하나를 증가시켜 이를 수행할 수 있습니다.autovacuum_freeze_max_age또는 감소vacuum_freeze_min_age.

다음에 대한 유효 최대값vacuum_freeze_table_age0.95 *입니다autovacuum_freeze_max_age; 보다 높은 설정 최대치로 제한됩니다. 다음보다 큰 값autovacuum_freeze_max_age말이 안 돼요 랩어라운드 방지 autovacuum이 실행될 것이기 때문입니다. 어쨌든 포인트를 지정하고 0.95 승수를 사용하면 숨쉴 여지가 조금 남습니다. 매뉴얼을 실행하다진공그 일이 일어나기 전에. 경험상,vacuum_freeze_table_age값으로 설정되어야 합니다 다소 아래autovacuum_freeze_max_age, 충분한 간격을 두어 정기적인 일정을 계획하세요.진공또는 일반 삭제에 의해 트리거된 자동 진공 해당 창에서 업데이트 활동이 실행됩니다. 너무 가깝게 설정함 랩어라운드 방지 autovacuum으로 이어질 수 있습니다. 최근 공간을 확보하기 위해 진공 청소기로 청소한 반면, 값이 낮을수록 전체 테이블 스캔을 더 자주 수행합니다.

증가의 유일한 단점autovacuum_freeze_max_age(그리고vacuum_freeze_table_age그리고) 그것은pg_clog데이터베이스의 하위 디렉토리 클러스터는 커밋을 저장해야 하므로 더 많은 공간을 차지합니다. 모든 거래 상태를 다시autovacuum_freeze_max_age수평선. 커밋 상태 트랜잭션당 2비트를 사용하므로, 만약autovacuum_freeze_max_age최대값으로 설정되어 있습니다. 허용되는 값은 20억입니다.pg_clog할 수 있다 약 0.5GB까지 증가할 것으로 예상됩니다. 이것이 사소한 일이라면 총 데이터베이스 크기와 비교하여 설정autovacuum_freeze_max_age최대 허용치까지 값을 권장합니다. 그렇지 않으면 자신이 무엇인지에 따라 설정하십시오. 기꺼이 허용하겠습니다pg_clog저장. (기본값인 2억 트랜잭션은 약 50MB에 해당합니다.pg_clog저장.)

감소의 한 가지 단점vacuum_freeze_min_age그것이 원인이 될 수도 있다는 것입니다진공쓸데없는 일을 하기 위해: 테이블 행의 XID를FrozenXID낭비입니다 그 후 곧 행이 수정되는 경우의 시간(행이 획득하게 됨) 새 XID). 따라서 설정은 행이 표시되지 않을 만큼 충분히 커야 합니다. 더 이상 변하지 않을 때까지 동결됩니다. 또 다른 이 설정을 줄이는 단점은 행에 삽입되거나 수정된 ​​트랜잭션이 정확히 손실됩니다. 더 빨리. 이 정보는 때때로 유용합니다. 특히 데이터베이스 장애 후 무엇이 잘못되었는지 분석하려고 할 때. 이러한 두 가지 이유로 인해 이 설정을 줄이는 것은 권장되지 않습니다. 완전히 정적인 테이블은 제외합니다.

데이터베이스에서 가장 오래된 XID의 기간을 추적하려면,진공시스템 테이블에 XID 통계를 저장합니다pg_class그리고pg_database. 특히,relfrozenxid테이블의 열pg_class행에는 동결 컷오프 XID가 포함되어 있습니다. 마지막 전체 테이블에서 사용되었습니다.진공해당 테이블에 대해. 이 컷오프 XID보다 오래된 모든 일반 XID는 다음으로 교체되었음을 보장합니다.FrozenXID테이블 내. 마찬가지로,datfrozenxid데이터베이스의 열pg_database행은 하한값입니다. 해당 데이터베이스에 나타나는 일반 XID — 이는 단지 최소값일 뿐입니다. 테이블당relfrozenxid값 데이터베이스 내에서. 이 정보를 검사하는 편리한 방법 다음과 같은 쿼리를 실행하는 것입니다.

c.oid::regclass를 table_name으로 선택하고,
       가장 큰(age(c.relfrozenxid),age(t.relfrozenxid))(나이)
pg_class c에서
왼쪽 조인 pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm');

pg_database에서 datname, age(datfrozenxid) 선택;

그나이열은 다음의 수를 측정합니다. 컷오프 XID부터 현재 트랜잭션까지의 트랜잭션 XID.

진공일반적으로 다음 페이지만 검색합니다. 마지막 진공 이후 수정되었지만relfrozenxid전체가 테이블이 스캔되었습니다. 전체 테이블은 다음과 같은 경우에 스캔됩니다.relfrozenxid이상vacuum_freeze_table_age오래된 거래, 언제진공's정지옵션이 사용되거나 모든 페이지를 진공 청소해야 하는 경우 데드 행 버전을 제거합니다. 언제진공완료된 후 전체 테이블을 스캔나이(relfrozenxid)다음보다 조금 더 커야 합니다vacuum_freeze_min_age설정은 다음과 같습니다. 사용됨(다음 이후 시작된 트랜잭션 수에 따라 더 많음진공시작됨). 그렇지 않은 경우 전체 테이블 스캔진공발행 날짜 테이블까지autovacuum_freeze_max_age도달하면 테이블에 대해 자동 진공이 곧 강제 실행됩니다.

어떤 이유로 autovacuum이 장치에서 이전 XID를 지우지 못하는 경우 테이블에서 시스템은 다음과 같은 경고 메시지를 보내기 시작합니다. 데이터베이스의 가장 오래된 XID가 다음에서 천만 트랜잭션에 도달할 때 랩어라운드 지점:

경고: 데이터베이스 "mydb"는 177009986 트랜잭션 내에서 비워져야 합니다
힌트: 데이터베이스 종료를 방지하려면 "mydb"에서 데이터베이스 전체 VACUUM을 실행하세요.

(설명서진공수정해야 합니다. 힌트에서 제안한 문제; 하지만 참고하세요.진공수퍼유저가 수행해야 합니다. 그렇지 않으면 시스템 카탈로그를 처리하지 못하여 다음 작업을 수행할 수 없습니다. 데이터베이스를 발전시킵니다.datfrozenxid.) 이러한 경고를 무시하면 시스템이 종료되고 거부됩니다. 100만 건 미만인 경우 새로운 거래를 시작하려면 랩어라운드까지 남은 거래 수:

오류: 데이터베이스가 "mydb" 데이터베이스의 랩어라운드 데이터 손실을 방지하기 위한 명령을 허용하지 않습니다.
힌트: 포스트마스터를 중지하고 "mydb"에서 VACUUM에 대한 독립형 백엔드를 사용하십시오.

1백만 거래의 안전 마진은 다음을 허용하기 위해 존재합니다. 관리자는 수동으로 실행하여 데이터 손실 없이 복구합니다. 필수의진공명령. 그러나 이후 시스템은 한 번 들어가면 명령을 실행하지 않습니다. 안전 종료 모드를 수행하는 유일한 방법은 서버를 중지하는 것입니다. 단일 사용자 백엔드를 사용하여 실행합니다.진공. 종료 모드는 다음에 의해 시행되지 않습니다. 단일 사용자 백엔드. 참조포스트그레스단일 사용자 백엔드 사용에 대한 자세한 내용은 참조 페이지.

23.1.6. 그만큼 자동 진공 데몬

PostgreSQL선택사항이 있지만 적극 권장되는 기능은자동 진공, 그 목적은 실행진공그리고분석명령. 활성화되면 autovacuum이 검사합니다. 많은 수의 삽입, 업데이트 또는 변경이 발생한 테이블의 경우 삭제된 튜플. 이러한 검사에서는 통계 수집을 사용합니다. 시설; 따라서 autovacuum은 다음을 제외하고는 사용할 수 없습니다.track_counts다음으로 설정됨참. 기본적으로 구성에서는 autovacuuming이 활성화되고 관련 구성 매개변수가 적절하게 설정되었습니다.

그"autovacuum 데몬"사실 여러 프로세스로 구성됩니다. 영구 데몬이 있습니다 프로세스라고 합니다.자동 진공 실행기, 시작을 담당하는자동 진공화 노동자모든 데이터베이스에 대한 프로세스입니다. 런처는 시간에 걸쳐 작업을 분배하고 하나의 작업자를 시작하려고 시도합니다. 각 데이터베이스 내에서 매autovacuum_naptime초. (따라서 설치가 완료된 경우)N데이터베이스, 새로운 작업자가 시작됩니다 모든autovacuum_naptime/N초.) 최대autovacuum_max_workers작업자 프로세스가 동시에 실행될 수 있습니다. 만약 있다면 이상autovacuum_max_workers데이터베이스 처리하려면 다음 데이터베이스가 즉시 처리됩니다. 첫 번째 작업자가 완료되었습니다. 각 작업자 프로세스는 각 테이블을 확인합니다. 데이터베이스 내에서 실행합니다.진공및/또는분석필요에 따라.log_autovacuum_min_duration모니터링하는 데 사용할 수 있습니다. 자동 진공 활동.

여러 개의 큰 테이블이 모두 진공 청소기로 청소할 수 있게 되면 짧은 시간 동안 모든 autovacuum 작업자가 점유될 수 있습니다. 오랫동안 그 테이블을 진공청소기로 청소하는 것 말이죠. 이로 인해 작업자가 될 때까지 다른 테이블과 데이터베이스는 비워지지 않습니다. 사용 가능. 한 회사에 근무할 수 있는 직원 수에는 제한이 없습니다. 단일 데이터베이스이지만 작업자는 반복되는 작업을 피하려고 노력합니다. 다른 작업자가 이미 수행했습니다. 참고로 실행중인 작업자는 포함되지 않습니다.max_connections또는superuser_reserved_connections한계.

다음 테이블relfrozenxid값은 다음과 같습니다 이상autovacuum_freeze_max_age오래된 거래는 항상 비워집니다. (이는 거래에도 적용됩니다. Storage를 통해 Freeze Max Age가 수정된 테이블 매개변수; 아래 참조). 그렇지 않은 경우, 튜플의 수가 마지막 이후로 사용되지 않음진공초과 그만큼"진공 임계값", 테이블은 진공청소기. 진공 임계값은 다음과 같이 정의됩니다.

진공 임계값 = 진공 기본 임계값 + 진공 배율 인수 * 튜플 수

여기서 진공 베이스 임계값은autovacuum_vacuum_threshold, 진공 스케일 팩터는 다음과 같습니다.autovacuum_vacuum_scale_factor, 튜플 수는pg_class.reltuples. 쓸모없는 튜플의 수는 다음과 같습니다. 통계 수집기에서 얻었습니다. 그것은 반정확한 계산이다 각각 업데이트됨업데이트그리고삭제작동. (반정확하기 때문에 과부하 상태에서는 일부 정보가 손실될 수 있습니다.)relfrozenxid테이블 값이 다음보다 큽니다.vacuum_freeze_table_age이전 거래, 전체 테이블을 스캔하여 오래된 튜플을 동결하고 진행합니다.relfrozenxid, 그렇지 않으면 페이지만 마지막 진공 검사 이후 수정된 항목이 검색됩니다.

분석을 위해 유사한 조건이 사용됩니다: 임계값, 정의 처럼:

임계값 분석 = 기본 임계값 분석 + 배율 인자 분석 * 튜플 수

은 삽입, 업데이트 또는 삽입된 총 튜플 수와 비교됩니다. 마지막 이후 삭제됨분석.

임시 테이블은 autovacuum으로 접근할 수 없습니다. 그러므로, 적절한 진공 및 분석 작업은 다음을 통해 수행되어야 합니다. 세션 SQL 명령.

기본 임계값 및 배율 인수는 다음에서 가져옵니다.postgresql.conf, 하지만 다음은 가능합니다. 테이블별로 재정의합니다. 보다저장 매개변수44102_44245섹션 18.10자세한 내용은 전역 설정에서.

기본 임계값 및 배율 인수 외에도 다음이 있습니다. 다음을 통해 각 테이블에 대해 설정할 수 있는 6개의 추가 autovacuum 매개변수 저장 매개변수. 첫 번째 매개변수,autovacuum_enabled, 다음으로 설정 가능거짓autovacuum 데몬에게 이를 건너뛰도록 지시합니다. 특정 테이블 전체. 이 경우 autovacuum은 트랜잭션 ID 랩어라운드를 방지하기 위해 그렇게 해야 하는 경우 테이블. 또 다른 두 개의 매개변수,autovacuum_vacuum_cost_delay그리고autovacuum_vacuum_cost_limit은 설정하는 데 사용됩니다. 비용 기반 진공 지연 기능에 대한 표별 값(참조섹션 18.4.4). autovacuum_freeze_min_age, autovacuum_freeze_max_age그리고autovacuum_freeze_table_age값을 설정하는 데 사용됩니다. 을 위한vacuum_freeze_min_age, autovacuum_freeze_max_age그리고vacuum_freeze_table_age각각.

여러 작업자가 실행 중일 때 비용 지연 매개변수는 다음과 같습니다."균형"달리는 모든 것 중에서 시스템에 대한 총 I/O 영향이 동일하도록 실제로 실행 중인 작업자 수에 관계없이. 그러나 어떤 테이블을 처리하는 작업자autovacuum_vacuum_cost_delay또는autovacuum_vacuum_cost_limit설정되지 않았습니다. 밸런싱 알고리즘에서 고려됩니다.