Mengoptimalkan, memantau, dan memecahkan masalah operasi VACUUM di PostgreSQL
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan dasar-dasar operasi VACUUM dalam database PostgreSQL. Bagian ini juga menjelaskan mekanisme untuk memantau dan menyesuaikan mesin database yang mempertahankan kondisi instance database.
PostgreSQL menggunakan protokol konkurensi berbasis snapshot yang membuat beberapa versi baris data sambil memodifikasi data. Versi baris data ini digunakan untuk membaca versi data yang terlihat menggunakan snapshot yang dihitung tanpa mendapatkan kunci baca pada baris data. PostgreSQL mempertahankan ID transaksi
(ID transaksi yang dimasukkan dan dihapus) untuk setiap baris data dan menggunakan
ID transaksi beserta snapshot yang dihitung untuk menentukan visibilitas
baris. Seiring dengan perkembangan data karena versi data lama, waktu yang dibutuhkan untuk memindai data (pemindaian tabel atau pemindaian indeks) pun meningkat. Untuk mengoptimalkan waktu respons
operasi pemindaian dan untuk menggunakan ruang secara efisien, Anda perlu mengklaim kembali
versi dan metadata (misalnya, ID transaksi) yang digunakan untuk mempertahankan
versi tersebut.
Operasi VACUUM mengklaim kembali versi yang dihapus (pembersihan sampah memori) dan ID transaksi (pembekuan ID transaksi). Operasi VACUUM beroperasi pada data dalam berbagai mode dengan tingkat ketersediaan data yang berbeda. Pembekuan ID transaksi sangat penting bagi kondisi sistem database karena sistem akan memblokir penulis setiap kali ruang ID transaksi yang digunakan memasuki ruang yang dicadangkan.
Tugas autovacuum yang Anda konfigurasi terus-menerus mencoba mengklaim kembali
ID transaksi, tetapi tugas tersebut bisa gagal. Kegagalan ini disebabkan oleh konfigurasi yang tidak memadai atau karena rasio pembuatan ID transaksi sangat tinggi sehingga tugas autovacuum tidak dapat memenuhi workload. Tujuan dari dokumen ini
adalah untuk menunjukkan cara menggunakan operasi VACUUM beserta mekanisme untuk menyesuaikan
dan memantau berbagai aspek operasi VACUUM.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 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)"]]
