이 문서에서는 PostgreSQL 데이터베이스에서 VACUUM 작업의 기초에 대해 설명합니다. 또한 데이터베이스 인스턴스 상태를 유지관리하는 데이터베이스 엔진을 모니터링하고 조정하는 메커니즘에 대해서도 설명합니다.
PostgreSQL에서는 데이터를 수정하면서 데이터 행의 여러 버전을 만드는 스냅샷 기반 동시성 프로토콜이 사용됩니다. 이러한 데이터 행 버전은 데이터 행에 대한 읽기 잠금을 획득하지 않고 계산된 스냅샷을 사용하여 데이터의 표시 가능한 버전을 읽기 위해 사용됩니다. PostgreSQL은 모든 데이터 행에 대해 트랜잭션 ID(삽입된 및 삭제된 트랜잭션 ID)를 유지관리하고 계산된 스냅샷과 함께 트랜잭션 ID를 사용하여 행의 가시성을 확인합니다. 오래된 데이터 버전으로 인해 데이터가 계속 증가하므로, 데이터 스캔에 걸리는 시간(테이블 스캔 또는 색인 스캔)이 늘어납니다. 스캔 작업의 응답 시간을 최적화하고 공간을 효율적으로 사용하기 위해서는 버전 유지관리에 사용된 메타데이터(예: 트랜잭션 ID)와 버전을 회수해야 합니다.
VACUUM 작업은 삭제된 버전(가비지 컬렉션) 및 트랜잭션 ID(트랜잭션 ID 고정)를 확보합니다. VACUUM 작업은 데이터 가용성이 서로 다른 상이한 모드의 데이터를 대상으로 작동합니다. 사용된 트랜잭션 ID 공간이 예약된 공간에 들어갈 때마다 시스템이 작성자를 차단하므로 트랜잭션 ID 고정은 데이터베이스 시스템의 상태에 매우 중요합니다.
구성한 autovacuum 작업이 트랜잭션 ID를 회수하기 위해 계속 시도하지만, 실패할 수 있습니다. 이러한 실패는 구성이 충분하지 않거나 트랜잭션 ID의 생성 속도가 너무 높아서 autovacuum 작업이 그러한 워크로드를 따라잡기 힘들기 때문입니다. 이 문서의 목적은 이러한 메커니즘과 함께 VACUUM 작업을 사용하여 VACUUM 작업의 여러 특성을 조정하고 모니터링하는 방법을 보여주기 위한 것입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Optimizing, monitoring, and troubleshooting VACUUM operations in PostgreSQL\n\nThis document describes the fundamentals of the `VACUUM` operation in\n[PostgreSQL](https://www.postgresql.org/)\ndatabases. It also describes the mechanisms to monitor and tune the database\nengine that maintains the health of database instances.\n\nPostgreSQL uses a snapshot-based concurrency protocol that creates multiple\nversions of data rows while modifying the data. These data row versions are used\nto read a visible version of the data using a computed snapshot without\nacquiring read-lock on the data row. PostgreSQL maintains transaction IDs\n(inserted and deleted transaction IDs) for every row of data and uses the\ntransaction IDs along with the computed snapshot to determine the visibility of\nthe row. As the data keeps growing due to old versions of data, the time taken\nto scan the data (table scan or index scan) increases. To optimize the response\ntime of the scan operation and to use space efficiently, you need to reclaim the\nversions and the metadata (for example, transaction ID) that is used to maintain\nthe versions.\n\nThe `VACUUM` operation reclaims the deleted versions (garbage collection) and\ntransaction IDs (freeze transaction ID). The `VACUUM` operation operates on data\nin different modes with different levels of data availability. Freezing\ntransaction IDs is crucial to the health of the database system because the\nsystem blocks writers whenever the used transaction ID space enters reserved\nspace.\n\nThe `autovacuum` jobs that you configure constantly try to reclaim the\ntransaction ID, but they can fail. This failure is either due to insufficient\nconfiguration or because the creation rate for transaction IDs is so high that\nthe `autovacuum` job cannot catch up with workload. The purpose of this document\nis to show how to use the `VACUUM` operations along with the mechanisms to tune\nand monitor different aspects of `VACUUM` operations.\n\nOverview\n--------\n\nThis document covers the following:\n\n- Freezing transaction IDs.\n- Monitoring transaction IDs.\n- Reclaiming storage space.\n- Configuring automated Cloud Monitoring alerts.\n\nTo read the full white paper, click the button:\n\n[Download the PDF](/static/solutions/optimizing-monitoring-troubleshooting-vacuum-operations-postgresql.pdf)"]]
