Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
#
[Di PostgreSQL, menyedot debu sangat penting untuk memastikan kesehatan database karena merebut kembali penyimpanan dan mencegah masalah pembungkus ID transaksi.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Namun, ada kalanya penyedot debu dapat dicegah agar tidak beroperasi seperti yang diinginkan, yang dapat mengakibatkan penurunan kinerja, pembengkakan penyimpanan, dan bahkan memengaruhi ketersediaan instans DB Anda dengan sampul ID transaksi. Oleh karena itu, mengidentifikasi dan menyelesaikan masalah ini sangat penting untuk kinerja dan ketersediaan database yang optimal. Baca [Memahami autovacuum di Amazon RDS untuk lingkungan PostgreSQL untuk](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) mempelajari lebih lanjut tentang autovacuum.
`postgres_get_av_diag()`Fungsi ini membantu mengidentifikasi masalah yang mencegah atau menunda kemajuan vakum yang agresif. Saran disediakan, yang mungkin termasuk perintah untuk menyelesaikan masalah yang dapat diidentifikasi atau panduan untuk diagnostik lebih lanjut di mana masalah tidak dapat diidentifikasi. Penghambat vakum agresif dilaporkan ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) RDS sebesar 500 juta transaksi. IDs
**Berapa usia ID transaksi?**
`age()`Fungsi untuk transaksi IDs menghitung jumlah transaksi yang telah terjadi sejak ID transaksi yang tidak dibekukan tertua untuk database (`pg_database.datfrozenxid`) atau tabel (`pg_class.relfrozenxid`). Nilai ini menunjukkan aktivitas database sejak operasi vakum agresif terakhir dan menyoroti kemungkinan beban kerja untuk proses VACUUM yang akan datang.
**Apa itu vakum agresif?**
Operasi VACUUM yang agresif melakukan pemindaian komprehensif semua halaman dalam tabel, termasuk yang biasanya dilewati selama reguler. VACUUMs Pemindaian menyeluruh ini bertujuan untuk “membekukan” transaksi IDs mendekati usia maksimum mereka, secara efektif mencegah situasi yang dikenal sebagai [sampul ID transaksi](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
`postgres_get_av_diag()`Untuk melaporkan pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
**Topics**
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
#
`postgres_get_av_diag()`Fungsi ini saat ini tersedia dalam RDS berikut untuk PostgreSQL Aurora PostgreSQL versi :
+ 17.2 dan versi 17 yang lebih tinggi
+ 16.7 dan versi 16 yang lebih tinggi
+ 15.11 dan versi 15 yang lebih tinggi
+ 14.16 dan versi 14 yang lebih tinggi
+ 13.19 dan 13 versi yang lebih tinggi
Untuk menggunakan`postgres_get_av_diag()`, buat `rds_tools` ekstensi.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Verifikasi bahwa ekstensi diinstal.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Verifikasi bahwa fungsi tersebut dibuat.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
#
`postgres_get_av_diag()` Kueri harus dieksekusi dalam database dengan ID transaksi tertua untuk hasil yang akurat. Untuk informasi selengkapnya tentang menggunakan database dengan ID transaksi tertua, lihat [Tidak terhubung ke database dengan usia ID transaksi terlama](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
`postgres_get_av_diag()`Fungsi mengembalikan tabel dengan informasi berikut:
**pemblokir**
Menentukan kategori aktivitas database yang memblokir vakum.
+ [Pernyataan aktif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Idle pada transaksi](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaksi yang disiapkan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot replikasi logis](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Baca replika dengan slot replikasi fisik](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Baca replika dengan replikasi streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabel sementara](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**basis data**
Menentukan nama database jika berlaku dan didukung. Ini adalah database di mana aktivitas sedang berlangsung dan memblokir atau akan memblokir autovacuum. Ini adalah database yang harus Anda sambungkan dan ambil tindakan.
**blocker\$1identifier**
Menentukan pengenal aktivitas yang memblokir atau akan memblokir autovacuum. Pengidentifikasi dapat berupa ID proses bersama dengan pernyataan SQL, transaksi yang disiapkan, alamat IP replika baca, dan nama slot replikasi, baik logis atau fisik.
**wait\$1event**
Menentukan [acara tunggu acara](PostgreSQL.Tuning.md) sesi pemblokiran dan berlaku untuk blocker berikut:
+ Pernyataan aktif
+ Idle pada transaksi
**autovacum\$1lagging\$1by**
Menentukan jumlah transaksi yang autovacuum tertinggal dalam pekerjaan backlog-nya per kategori.
**saran**
Menentukan saran untuk menyelesaikan blocker. Instruksi ini mencakup nama database tempat aktivitas ada jika berlaku, ID Proses (PID) sesi jika berlaku, dan tindakan yang akan diambil.
**suggested\$1action**
Menyarankan tindakan yang perlu diambil untuk menyelesaikan pemblokir.
#
Autovacuum melakukan penyedot debu agresif dan menurunkan usia transaksi IDs hingga di bawah ambang batas yang ditentukan oleh parameter instans RDS Anda. `autovacuum_freeze_max_age` Anda dapat melacak usia ini menggunakan CloudWatch metrik Amazon`MaximumUsedTransactionIDs`.
Untuk menemukan pengaturan `autovacuum_freeze_max_age` (yang memiliki default 200 juta transaksi IDs) untuk instans Amazon RDS Anda, Anda dapat menggunakan kueri berikut:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Perhatikan bahwa `postgres_get_av_diag()` hanya memeriksa penghambat vakum agresif ketika usia melebihi ambang batas [autovacuum adaptif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) Amazon RDS sebesar 500 juta transaksi. IDs `postgres_get_av_diag()`Untuk mendeteksi pemblokir, pemblokir harus berusia setidaknya 500 juta transaksi.
`postgres_get_av_diag()`Fungsi ini mengidentifikasi jenis blocker berikut:
**Topics**
+ [Pernyataan aktif](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Idle pada transaksi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transaksi yang disiapkan](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot replikasi logis](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Replika baca](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabel sementara](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Pernyataan aktif
Dalam PostgreSQL, pernyataan aktif adalah pernyataan SQL yang saat ini sedang dijalankan oleh database. Ini termasuk kueri, transaksi, atau operasi apa pun yang sedang berlangsung. Saat memantau via`pg_stat_activity`, kolom status menunjukkan bahwa proses dengan PID yang sesuai aktif.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi pernyataan yang merupakan pernyataan aktif.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Tindakan yang disarankan**
Mengikuti panduan di `suggestion` kolom, pengguna dapat terhubung ke database di mana pernyataan aktif hadir dan, seperti yang ditentukan dalam `suggested_action` kolom, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa yang diperlukan.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Idle pada transaksi
Pernyataan transaksi yang menganggur mengacu pada setiap sesi yang telah membuka transaksi eksplisit (seperti dengan mengeluarkan `BEGIN` pernyataan), melakukan beberapa pekerjaan, dan sekarang menunggu klien untuk melewati lebih banyak pekerjaan atau memberi sinyal akhir transaksi dengan mengeluarkan`COMMIT`,`ROLLBACK`, atau `END` (yang akan menghasilkan implisit). `COMMIT`
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi `idle in transaction` pernyataan sebagai pemblokir.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Tindakan yang disarankan**
Seperti yang ditunjukkan dalam `suggestion` kolom, Anda dapat terhubung ke database tempat idle dalam sesi transaksi hadir dan mengakhiri sesi menggunakan fungsi. `pg_terminate_backend()` Pengguna dapat menjadi pengguna admin Anda (akun master RDS) atau pengguna dengan `pg_terminate_backend()` hak istimewa.
**Awas**
Sesi yang dihentikan akan membatalkan (`ROLLBACK`) perubahan yang dibuatnya. Tergantung pada kebutuhan Anda, Anda mungkin ingin menjalankan kembali pernyataan tersebut. Namun, disarankan untuk melakukannya hanya setelah proses autovacuum menyelesaikan operasi vakum agresifnya.
## Transaksi yang disiapkan
[PostgreSQL memungkinkan transaksi yang merupakan bagian dari strategi komit dua fase yang disebut transaksi siap.](https://www.postgresql.org/docs/current/sql-prepare-transaction.html) Ini diaktifkan dengan mengatur `max_prepared_transactions` parameter ke nilai bukan nol. Transaksi yang disiapkan dirancang untuk memastikan bahwa transaksi tahan lama dan tetap tersedia bahkan setelah database crash, restart, atau pemutusan klien. Seperti transaksi reguler, mereka diberi ID transaksi dan dapat memengaruhi autovacuum. Jika dibiarkan dalam keadaan siap, autovacuum tidak dapat melakukan freeezing dan dapat menyebabkan penutupan ID transaksi.
Ketika transaksi dibiarkan dipersiapkan tanpa batas waktu tanpa diselesaikan oleh manajer transaksi, mereka menjadi transaksi yang disiapkan yatim piatu. Satu-satunya cara untuk memperbaikinya adalah dengan melakukan atau mengembalikan transaksi menggunakan `ROLLBACK PREPARED` perintah `COMMIT PREPARED` atau, masing-masing.
**catatan**
Ketahuilah bahwa cadangan yang diambil selama transaksi yang disiapkan akan tetap berisi transaksi tersebut setelah restorasi. Lihat informasi berikut tentang cara menemukan dan menutup transaksi tersebut.
`postgres_get_av_diag()`Fungsi ini menampilkan output berikut ketika mengidentifikasi pemblokir yang merupakan transaksi yang disiapkan.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Tindakan yang disarankan**
Seperti disebutkan di kolom saran, sambungkan ke database tempat transaksi yang disiapkan berada. Berdasarkan `suggested_action` kolom, hati-hati meninjau apakah akan melakukan salah satu `COMMIT` atau`ROLLBACK`, dan menyetujui tindakan.
Untuk memantau transaksi yang disiapkan secara umum, PostgreSQL menawarkan tampilan katalog yang disebut. `pg_prepared_xacts` Anda dapat menggunakan kueri berikut untuk menemukan transaksi yang disiapkan.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Slot replikasi logis
Tujuan dari slot replikasi adalah untuk menahan perubahan yang tidak dikonsumsi sampai mereka direplikasi ke server target. [Untuk informasi lebih lanjut, lihat Replikasi Logis PostgreSQL.](https://www.postgresql.org/docs/current/logical-replication.html)
Ada dua jenis slot replikasi logis.
**Slot replikasi logis tidak aktif**
Ketika replikasi dihentikan, log transaksi yang tidak dikonsumsi tidak dapat dihapus, dan slot replikasi menjadi tidak aktif. Meskipun slot replikasi logis yang tidak aktif saat ini tidak digunakan oleh pelanggan, itu tetap di server, yang mengarah ke retensi file WAL dan mencegah penghapusan log transaksi lama. Ini dapat meningkatkan penggunaan disk dan secara khusus memblokir autovacuum dari membersihkan tabel katalog internal, karena sistem harus menjaga informasi LSN agar tidak ditimpa. Jika tidak ditangani, hal ini dapat mengakibatkan kembung katalog, penurunan kinerja, dan peningkatan risiko kekosongan sampul, yang berpotensi menyebabkan downtime transaksi.
**Slot replikasi logis aktif tapi lambat**
Terkadang penghapusan tupel mati katalog tertunda karena penurunan kinerja replikasi logis. Keterlambatan replikasi ini memperlambat pembaruan `catalog_xmin` dan dapat menyebabkan katalog kembung dan vakum sampul.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan slot replikasi logis sebagai pemblokir.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Tindakan yang disarankan**
Untuk mengatasi masalah ini, periksa konfigurasi replikasi untuk masalah dengan skema target atau data yang mungkin menghentikan proses penerapan. Alasan paling umum adalah sebagai berikut:
+ Kolom hilang
+ Tipe data yang tidak kompatibel
+ Ketidakcocokan data
+ Tabel hilang
Jika masalah terkait dengan masalah infrastruktur:
+ Masalah jaringan - [Bagaimana cara mengatasi masalah dengan Amazon RDS DB dalam status jaringan yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-network) .
+ Database atau instans DB tidak tersedia karena alasan berikut:
+ Instans replika kehabisan penyimpanan - Tinjau [instans Amazon RDS DB kehabisan penyimpanan](https://repost.aws/knowledge-center/rds-out-of-storage) untuk informasi tentang menambahkan penyimpanan.
+ Parameter Tidak Kompatibel - Tinjau [Bagaimana cara memperbaiki instans Amazon RDS DB yang macet dalam status parameter yang tidak kompatibel?](https://repost.aws/knowledge-center/rds-incompatible-parameters) untuk informasi lebih lanjut tentang bagaimana Anda dapat menyelesaikan masalah.
Jika instans Anda berada di luar AWS jaringan atau aktif AWS EC2, konsultasikan dengan administrator Anda tentang cara mengatasi masalah ketersediaan atau terkait infrastruktur.
**Menjatuhkan slot yang tidak aktif**
**Awas**
Perhatian: Sebelum menjatuhkan slot replikasi, pastikan dengan hati-hati bahwa ia tidak memiliki replikasi yang sedang berlangsung, tidak aktif, dan dalam keadaan tidak dapat dipulihkan. Menjatuhkan slot sebelum waktunya dapat mengganggu replikasi atau menyebabkan kehilangan data.
Setelah memastikan bahwa slot replikasi tidak lagi diperlukan, jatuhkan untuk memungkinkan autovacuum melanjutkan. Kondisi ini `active = 'f'` memastikan bahwa hanya slot yang tidak aktif yang dijatuhkan.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Replika baca
Saat `hot_standby_feedback` pengaturan diaktifkan untuk [replika baca Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), pengaturan ini mencegah autovacuum pada database utama menghapus baris mati yang mungkin masih diperlukan oleh kueri yang berjalan pada replika baca. Ini mempengaruhi semua jenis replika baca fisik termasuk yang dikelola dengan atau tanpa slot replikasi. Perilaku ini diperlukan karena kueri yang berjalan pada replika siaga mengharuskan baris tersebut tetap tersedia di primer yang mencegah [konflik dan pembatalan kueri](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT).
**Baca replika dengan slot replikasi fisik**
Slot ini memastikan database utama menyimpan file Write-Ahead Log penting sampai replika memprosesnya, menjaga konsistensi data bahkan selama gangguan jaringan.
Dimulai dengan RDS untuk PostgreSQL , semua replika menggunakan slot replikasi. Pada versi sebelumnya, hanya replika lintas wilayah yang menggunakan slot replikasi.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca dengan slot replikasi fisik sebagai pemblokir.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Baca replika dengan replikasi streaming**
Amazon RDS memungkinkan pengaturan replika baca tanpa slot replikasi fisik di versi yang lebih lama, hingga versi 13. Pendekatan ini mengurangi overhead dengan memungkinkan primer untuk mendaur ulang file WAL lebih agresif, yang menguntungkan di lingkungan dengan ruang disk terbatas dan dapat mentolerir sesekali. ReplicaLag Namun, tanpa slot, siaga harus tetap sinkron untuk menghindari file WAL yang hilang. Amazon RDS menggunakan file WAL yang diarsipkan untuk membantu replika catch up jika tertinggal, tetapi proses ini memerlukan pemantauan yang cermat dan bisa lambat.
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ini ketika menemukan replika baca streaming sebagai pemblokir.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Tindakan yang disarankan**
Seperti yang direkomendasikan di `suggested_action` kolom, tinjau opsi ini dengan cermat untuk membuka blokir autovacuum.
+ **Mengakhiri kueri** — Mengikuti panduan di kolom saran, Anda dapat terhubung ke replika baca, seperti yang ditentukan dalam kolom suggested\$1action, disarankan untuk hati-hati meninjau opsi untuk mengakhiri sesi. Jika penghentian dianggap aman, Anda dapat menggunakan `pg_terminate_backend()` fungsi ini untuk mengakhiri sesi. Tindakan ini dapat dilakukan oleh administrator (seperti akun master RDS) atau pengguna dengan hak istimewa pg\$1terminate\$1backend () yang diperlukan.
Anda dapat menjalankan perintah SQL berikut pada replika baca untuk mengakhiri kueri yang mencegah vakum pada primer membersihkan baris lama. Nilai dilaporkan dalam output fungsi: `backend_xmin`
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Nonaktifkan umpan balik siaga panas** - Pertimbangkan untuk menonaktifkan `hot_standby_feedback` parameter jika menyebabkan penundaan vakum yang signifikan.
`hot_standby_feedback`Parameter ini memungkinkan replika baca untuk menginformasikan primer tentang aktivitas kuerinya, mencegah primer menyedot debu tabel atau baris yang digunakan pada siaga. Meskipun ini memastikan stabilitas kueri pada siaga, ini dapat secara signifikan menunda penyedotan debu pada primer. Menonaktifkan fitur ini memungkinkan primer untuk melanjutkan dengan menyedot debu tanpa menunggu siaga untuk mengejar ketinggalan. Namun, ini dapat menyebabkan pembatalan kueri atau kegagalan pada siaga jika mencoba mengakses baris yang telah disedot oleh primer.
+ **Hapus replika baca jika tidak diperlukan** — Jika replika baca tidak lagi diperlukan, Anda dapat menghapusnya. Ini akan menghapus overhead replikasi terkait dan memungkinkan primer untuk mendaur ulang log transaksi tanpa ditahan oleh replika.
## Tabel sementara
[Tabel sementara](https://www.postgresql.org/docs/current/sql-createtable.html), dibuat menggunakan `TEMPORARY` kata kunci, berada dalam skema temp, misalnya pg\$1temp\$1xxx, dan hanya dapat diakses oleh sesi yang membuatnya. Tabel sementara dijatuhkan saat sesi berakhir. Namun, tabel ini tidak terlihat oleh proses autovacuum PostgreSQL, dan harus disedot secara manual oleh sesi yang membuatnya. Mencoba menyedot tabel suhu dari sesi lain tidak berpengaruh.
Dalam keadaan yang tidak biasa, tabel sementara ada tanpa sesi aktif yang memilikinya. Jika sesi kepemilikan berakhir secara tak terduga karena kecelakaan fatal, masalah jaringan, atau peristiwa serupa, tabel sementara mungkin tidak dibersihkan, meninggalkannya sebagai tabel “yatim piatu”. Ketika proses autovacuum PostgreSQL mendeteksi tabel sementara yatim piatu, ia mencatat pesan berikut:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
`postgres_get_av_diag()`Fungsi ini menampilkan output yang mirip dengan berikut ketika mengidentifikasi tabel sementara sebagai pemblokir. Agar fungsi menampilkan output yang terkait dengan tabel sementara dengan benar, itu perlu dieksekusi dalam database yang sama di mana tabel tersebut ada.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Tindakan yang disarankan**
Ikuti instruksi yang diberikan di `suggestion` kolom output untuk mengidentifikasi dan menghapus tabel sementara yang mencegah autovacuum berjalan. Gunakan perintah berikut untuk menjatuhkan tabel sementara yang dilaporkan oleh`postgres_get_av_diag()`. Ganti nama tabel berdasarkan output yang disediakan oleh `postgres_get_av_diag()` fungsi.
```
DROP TABLE my_temp_schema.my_temp_table;
```
Kueri berikut dapat digunakan untuk mengidentifikasi tabel sementara:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
#
Bagian ini mengeksplorasi alasan tambahan yang dapat mencegah penyedot debu membuat kemajuan. Masalah-masalah ini saat ini tidak dapat diidentifikasi secara langsung oleh fungsi. `postgres_get_av_diag()`
**Topics**
+ [Halaman tidak valid](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Inkonsistensi indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Tingkat transaksi yang sangat tinggi](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Halaman tidak valid
Kesalahan halaman yang tidak valid terjadi ketika PostgreSQL mendeteksi ketidakcocokan dalam checksum halaman saat mengakses halaman tersebut. Isinya tidak dapat dibaca, mencegah autovacuum membekukan tupel. Ini secara efektif menghentikan proses pembersihan. Kesalahan berikut ditulis ke dalam log PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Tentukan jenis objek**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Dari pesan kesalahan, jalur `base/16403/186752608` memberikan informasi berikut:
+ “base” adalah nama direktori di bawah direktori data PostgreSQL.
+ “16403" adalah database OID, yang dapat Anda cari di katalog sistem. `pg_database`
+ “186752608" adalah`relfilenode`, yang dapat Anda gunakan untuk mencari skema dan nama objek dalam katalog sistem. `pg_class`
Dengan memeriksa output dari query berikut dalam database yang terkena dampak, Anda dapat menentukan jenis objek. Query berikut mengambil informasi objek untuk oid: 186752608. Ganti OID dengan yang relevan dengan kesalahan yang Anda temui.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Untuk informasi selengkapnya, lihat [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html)dokumentasi PostgreSQL untuk semua jenis objek yang didukung, yang dicatat oleh kolom di. `relkind` `pg_class`
**Bimbingan**
Solusi paling efektif untuk masalah ini bergantung pada konfigurasi instans Amazon RDS spesifik Anda dan jenis data yang dipengaruhi oleh halaman yang tidak konsisten.
**Jika jenis objek adalah indeks:**
Membangun kembali indeks direkomendasikan.
+ **Menggunakan `CONCURRENTLY` opsi** — Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi `CONCURRENTLY` ini memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Meskipun `CONCURRENTLY` tidak terlalu mengganggu, itu bisa lebih lambat di meja yang sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan.
[Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL REINDEX.](https://www.postgresql.org/docs/current/sql-reindex.html)
+ **Menggunakan `INDEX_CLEANUP FALSE` opsi** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan manual sambil mengecualikan indeks. `VACUUM FREEZE` Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
**Jika jenis objek adalah tampilan terwujud:**
Jika terjadi kesalahan halaman yang tidak valid pada tampilan yang terwujud, masuk ke database yang terkena dampak dan segarkan untuk menyelesaikan halaman yang tidak valid:
Segarkan tampilan terwujud:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Jika penyegaran gagal, coba buat ulang:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Menyegarkan atau membuat ulang tampilan terwujud akan mengembalikannya tanpa memengaruhi data tabel yang mendasarinya.
**Untuk semua jenis objek lainnya:**
Untuk semua jenis objek lainnya, hubungi AWS dukungan.
## Inkonsistensi indeks
Indeks yang tidak konsisten secara logis dapat mencegah autovacuum membuat kemajuan. Kesalahan berikut atau kesalahan serupa dicatat selama fase vakum indeks atau ketika indeks diakses oleh pernyataan SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Bimbingan**
Bangun kembali indeks atau lewati indeks menggunakan manual`INDEX_CLEANUP`. `VACUUM FREEZE` Untuk informasi tentang cara membangun kembali indeks, lihat [Jika jenis objek adalah indeks](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Menggunakan opsi CONCURRENT** - Sebelum PostgreSQL versi 12, membangun kembali indeks memerlukan kunci tabel eksklusif, membatasi akses ke tabel. Dengan PostgreSQL versi 12, dan versi yang lebih baru, opsi CONCURRENT memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintah:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Sementara CONCURRENT kurang mengganggu, itu bisa lebih lambat pada tabel sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan. Untuk informasi selengkapnya, lihat [REINDEX dalam dokumentasi](https://www.postgresql.org/docs/current/sql-reindex.html) *PostgreSQL*.
+ **Menggunakan opsi INDEX\$1CLEANUP FALSE** — Jika indeksnya besar dan diperkirakan membutuhkan banyak waktu untuk menyelesaikannya, Anda dapat membuka blokir autovacuum dengan menjalankan VACUUM FREEZE manual sambil mengecualikan indeks. Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.
Melewati indeks akan memungkinkan Anda untuk melewati proses vakum dari indeks yang tidak konsisten dan mengurangi masalah sampul. Namun, ini tidak akan menyelesaikan masalah halaman tidak valid yang mendasarinya. Untuk sepenuhnya mengatasi dan menyelesaikan masalah halaman yang tidak valid, Anda masih perlu membangun kembali indeks.
## Tingkat transaksi yang sangat tinggi
Di PostgreSQL, tingkat transaksi yang tinggi dapat secara signifikan memengaruhi kinerja autovacuum, yang mengarah pada pembersihan tupel mati yang lebih lambat dan peningkatan risiko sampul ID transaksi. Anda dapat memantau tingkat transaksi dengan mengukur perbedaan `max(age(datfrozenxid))` antara dua periode waktu, biasanya per detik. Selain itu, Anda dapat menggunakan metrik penghitung berikut dari RDS Performance Insights untuk mengukur tingkat transaksi (jumlah xact\$1commit dan xact\$1rollback) yang merupakan jumlah total transaksi.
| Penghitung | Jenis | Unit | Metrik |
| --- | --- | --- | --- |
| xact\$1commit | Transaksi | Commit per detik | db.Transactions.xact\$1commit |
| xact\$1rollback | Transaksi | Pemulihan per detik | db.Transactions.xact\$1rollback |
Peningkatan yang cepat menunjukkan beban transaksi yang tinggi, yang dapat membanjiri autovacuum, menyebabkan kembung, perselisihan kunci, dan potensi masalah kinerja. Hal ini dapat berdampak negatif pada proses autovacuum dalam beberapa cara:
+ **Aktivitas Tabel:** Tabel spesifik yang disedot dapat mengalami volume transaksi yang tinggi, menyebabkan penundaan.
+ **Sistem Sumber Daya** Sistem secara keseluruhan mungkin kelebihan beban, sehingga sulit bagi autovacuum untuk mengakses sumber daya yang diperlukan agar berfungsi secara efisien.
Pertimbangkan strategi berikut untuk memungkinkan autovacuum beroperasi lebih efektif dan mengikuti tugasnya:
1. Kurangi tingkat transaksi jika memungkinkan. Pertimbangkan untuk mengelompokkan atau mengelompokkan transaksi serupa jika memungkinkan.
1. Targetkan tabel yang sering diperbarui dengan `VACUUM FREEZE` operasi manual setiap malam, mingguan, atau dua mingguan selama jam sibuk.
1. Pertimbangkan untuk meningkatkan kelas instans Anda untuk mengalokasikan lebih banyak sumber daya sistem untuk menangani volume transaksi dan autovacuum yang tinggi.
#
Bagian ini membahas faktor-faktor yang sering berkontribusi pada kinerja vakum yang lebih lambat dan bagaimana mengatasi masalah ini.
**Topics**
+ [Vakum indeks besar](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Terlalu banyak tabel atau database untuk vakum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Vakum agresif (untuk mencegah pembungkus) sedang berjalan](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vakum indeks besar
VACUUM beroperasi melalui fase berurutan: inisialisasi, pemindaian tumpukan, penyedot debu indeks dan tumpukan, pembersihan indeks, pemotongan tumpukan, dan pembersihan akhir. Selama pemindaian tumpukan, proses memangkas halaman, mendefragmen, dan membekukannya. Setelah menyelesaikan pemindaian heap, VACUUM membersihkan indeks, mengembalikan halaman kosong ke sistem operasi, dan melakukan tugas pembersihan akhir seperti menyedot debu peta ruang kosong dan memperbarui statistik.
Penyedot debu indeks mungkin memerlukan beberapa lintasan ketika `maintenance_work_mem` (atau`autovacuum_work_mem`) tidak cukup untuk memproses indeks. Di PostgreSQL 16 dan sebelumnya, batas memori 1 GB untuk menyimpan IDs tupel mati sering memaksa beberapa pass pada indeks besar. PostgreSQL 17 `TidStore` memperkenalkan, yang secara dinamis mengalokasikan memori alih-alih menggunakan array alokasi tunggal. Ini menghilangkan batasan 1 GB, menggunakan memori lebih efisien, dan mengurangi kebutuhan untuk beberapa pemindaian indeks per setiap indeks.
Indeks besar mungkin masih memerlukan beberapa pass di PostgreSQL 17 jika memori yang tersedia tidak dapat mengakomodasi seluruh pemrosesan indeks sekaligus. Biasanya, indeks yang lebih besar mengandung lebih banyak tupel mati yang membutuhkan banyak lintasan.
**Mendeteksi operasi vakum yang lambat**
`postgres_get_av_diag()`Fungsi ini dapat mendeteksi ketika operasi vakum berjalan lambat karena memori yang tidak mencukupi. Untuk informasi lebih lanjut tentang fungsi ini, lihat[](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
`postgres_get_av_diag()`Fungsi mengeluarkan pemberitahuan berikut ketika memori yang tersedia tidak cukup untuk menyelesaikan penyedot debu indeks dalam satu lintasan.
**`rds_tools`1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools`1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**catatan**
`postgres_get_av_diag()`Fungsi ini bergantung pada `pg_stat_all_tables.n_dead_tup` untuk memperkirakan jumlah memori yang diperlukan untuk penyedot debu indeks.
Ketika `postgres_get_av_diag()` fungsi mengidentifikasi operasi vakum lambat yang memerlukan beberapa pemindaian indeks karena tidak mencukupi`autovacuum_work_mem`, itu akan menghasilkan pesan berikut:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Bimbingan**
Anda dapat menerapkan solusi berikut menggunakan manual `VACUUM FREEZE` untuk mempercepat pembekuan tabel.
**Tingkatkan memori untuk menyedot debu**
Seperti yang disarankan oleh `postgres_get_av_diag()` fungsi, disarankan untuk meningkatkan `autovacuum_work_mem` parameter untuk mengatasi kendala memori potensial pada tingkat instance. Meskipun `autovacuum_work_mem` merupakan parameter dinamis, penting untuk dicatat bahwa agar pengaturan memori baru diterapkan, daemon autovacuum perlu me-restart pekerjanya. Untuk mencapai ini:
1. Konfirmasikan bahwa pengaturan baru sudah ada.
1. Hentikan proses yang saat ini menjalankan autovacuum.
Pendekatan ini memastikan bahwa alokasi memori yang disesuaikan diterapkan pada operasi autovacuum baru.
Untuk hasil yang lebih cepat, pertimbangkan untuk melakukan `VACUUM FREEZE` operasi secara manual dengan `maintenance_work_mem` pengaturan yang ditingkatkan dalam sesi Anda:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Jika Anda menggunakan Amazon RDS dan menemukan bahwa Anda memerlukan memori tambahan untuk mendukung nilai yang lebih tinggi untuk `maintenance_work_mem` atau`autovacuum_work_mem`, pertimbangkan untuk meningkatkan ke kelas instans dengan lebih banyak memori. Ini dapat menyediakan sumber daya yang diperlukan untuk meningkatkan operasi vakum manual dan otomatis, yang mengarah pada peningkatan kinerja vakum dan basis data secara keseluruhan.
**Nonaktifkan INDEX\$1CLEANUP**
Manual `VACUUM` di PostgreSQL versi 12 dan yang lebih baru memungkinkan melewatkan fase pembersihan indeks, sementara autovacuum darurat di PostgreSQL versi 14 dan yang lebih baru melakukan ini secara otomatis berdasarkan parameter. [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE)
**Awas**
Melewatkan pembersihan indeks dapat menyebabkan indeks kembung dan berdampak negatif pada kinerja kueri. Untuk mengurangi ini, pertimbangkan untuk mengindeks ulang atau menyedot debu indeks yang terpengaruh selama jendela pemeliharaan.
Untuk panduan tambahan tentang penanganan indeks besar, lihat dokumentasi di[Mengelola autovacuum dengan indeks berukuran besar](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Penyedot debu indeks paralel**
Dimulai dengan PostgreSQL 13, indeks dapat disedot dan dibersihkan secara paralel secara default menggunakan `VACUUM` manual, dengan satu proses vacuum worker ditetapkan untuk setiap indeks. Namun, untuk PostgreSQL untuk menentukan apakah operasi vakum memenuhi syarat untuk eksekusi paralel, kriteria khusus harus dipenuhi:
+ Setidaknya harus ada dua indeks.
+ `max_parallel_maintenance_workers`Parameter harus diatur ke setidaknya 2.
+ Ukuran indeks harus melebihi `min_parallel_index_scan_size` batas, yang defaultnya 512KB.
Anda dapat menyesuaikan `max_parallel_maintenance_workers` pengaturan berdasarkan jumlah v yang CPUs tersedia di instans Amazon RDS Anda dan jumlah indeks di atas meja untuk mengoptimalkan waktu penyelesaian vakum.
Untuk informasi selengkapnya, lihat [Penyedot debu paralel di Amazon RDS untuk PostgreSQL dan Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Terlalu banyak tabel atau database untuk vakum
Seperti disebutkan dalam dokumentasi [The Autovacuum Daemon PostgreSQL, daemon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') beroperasi melalui beberapa proses. Ini termasuk peluncur autovacuum persisten yang bertanggung jawab untuk memulai proses pekerja autovacuum untuk setiap database dalam sistem. Peluncur menjadwalkan pekerja ini untuk memulai kira-kira setiap `autovacuum_naptime` detik per database.
Dengan database 'N', pekerja baru memulai kira-kira setiap [`autovacuum_naptime`/N detik]. Namun, jumlah total pekerja bersamaan dibatasi oleh `autovacuum_max_workers` pengaturan. Jika jumlah database atau tabel yang membutuhkan penyedot debu melebihi batas ini, database atau tabel berikutnya akan diproses segera setelah pekerja tersedia.
Ketika banyak tabel besar atau database memerlukan penyedot debu secara bersamaan, semua pekerja autovacuum yang tersedia dapat menjadi sibuk untuk durasi yang lama, menunda pemeliharaan pada tabel dan database lain. Di lingkungan dengan tingkat transaksi tinggi, kemacetan ini dapat dengan cepat meningkat dan berpotensi menyebabkan masalah vakum sampul dalam instans Amazon RDS Anda.
Ketika `postgres_get_av_diag()` mendeteksi sejumlah besar tabel atau database, ia memberikan rekomendasi berikut:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Bimbingan**
**Tingkatkan autovacuum\$1max\$1workers**
Untuk mempercepat penyedotan debu, kami sarankan untuk menyesuaikan `autovacuum_max_workers` parameter untuk memungkinkan lebih banyak pekerja autovacuum bersamaan. Jika kemacetan kinerja tetap ada, pertimbangkan untuk meningkatkan instans Amazon RDS Anda ke kelas dengan lebih banyak v, yang selanjutnya dapat meningkatkan kemampuan pemrosesan CPUs paralel.
## Vakum agresif (untuk mencegah pembungkus) sedang berjalan
Usia database (MaximumUsedTransactionIDs) di PostgreSQL hanya berkurang ketika vakum agresif (untuk mencegah sampul) berhasil diselesaikan. Sampai kekosongan ini selesai, usia akan terus meningkat tergantung pada tingkat transaksi.
`postgres_get_av_diag()`Fungsi ini menghasilkan yang berikut `NOTICE` ketika mendeteksi vakum yang agresif. Namun, itu hanya memicu output ini setelah vakum telah aktif setidaknya selama dua menit.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Untuk informasi lebih lanjut tentang vakum agresif, lihat [Saat vakum agresif sudah berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Anda dapat memverifikasi apakah vakum agresif sedang berlangsung dengan kueri berikut:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Anda dapat menentukan apakah itu vakum agresif (untuk mencegah sampul) dengan memeriksa kolom kueri di output. Ungkapan “untuk mencegah sampul” menunjukkan bahwa itu adalah kekosongan yang agresif.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Misalnya, Anda memiliki pemblokir pada usia transaksi 1 miliar dan tabel yang membutuhkan vakum agresif untuk mencegah pemblokiran pada usia transaksi yang sama. Selain itu, ada pemblokir lain pada usia transaksi 750 juta. Setelah menyelesaikan pemblokir pada usia transaksi 1 miliar, usia transaksi tidak akan langsung turun menjadi 750 juta. Ini akan tetap tinggi sampai tabel yang membutuhkan vakum agresif atau transaksi apa pun dengan usia di atas 750 juta selesai. Selama periode ini, usia transaksi klaster PostgreSQL Anda akan terus meningkat. Setelah proses vakum selesai, usia transaksi akan turun menjadi 750 juta tetapi akan mulai meningkat lagi hingga penyedotan lebih lanjut selesai. Siklus ini akan berlanjut selama kondisi ini tetap ada, hingga usia transaksi akhirnya turun ke level yang dikonfigurasi untuk instans Amazon RDS Anda, yang ditentukan oleh. `autovacuum_freeze_max_age`
#
`postgres_get_av_diag()`Fungsi ini menyediakan pesan PEMBERITAHUAN berikut:
**Ketika usia belum mencapai ambang pemantauan**
Ambang batas pemantauan `postgres_get_av_diag()` untuk mengidentifikasi pemblokir adalah 500 juta transaksi secara default. Jika `postgres_get_av_diag()` menghasilkan PEMBERITAHUAN berikut, ini menunjukkan bahwa usia transaksi belum mencapai ambang batas ini.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Tidak terhubung ke database dengan usia ID transaksi tertua**
`postgres_get_av_diag()`Fungsi ini memberikan output paling akurat saat terhubung ke database dengan usia ID transaksi tertua. Database dengan usia ID transaksi tertua yang dilaporkan oleh `postgres_get_av_diag()` akan berbeda dari “my\$1database” dalam kasus Anda. Jika Anda tidak terhubung ke database yang benar, PEMBERITAHUAN berikut akan dibuat:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Menghubungkan ke database dengan usia transaksi tertua penting karena alasan berikut:
+ **Mengidentifikasi pemblokir tabel sementara:** Karena metadata untuk tabel sementara khusus untuk setiap database, mereka biasanya ditemukan dalam database tempat mereka dibuat. Namun, jika tabel sementara kebetulan menjadi pemblokir teratas dan berada di database dengan transaksi tertua, ini bisa menyesatkan. Menghubungkan ke database yang benar memastikan identifikasi akurat dari pemblokir tabel sementara.
+ **Mendiagnosis vakum lambat:** Metadata indeks dan informasi jumlah tabel bersifat spesifik basis data dan diperlukan untuk mendiagnosis masalah vakum lambat.
**Database dengan transaksi tertua berdasarkan usia ada pada database rdsadmin atau template0**
Dalam kasus tertentu, `rdsadmin` atau `template0` database dapat diidentifikasi sebagai database dengan usia ID transaksi tertua. Jika ini terjadi, `postgres_get_av_diag()` akan mengeluarkan PEMBERITAHUAN berikut:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Verifikasi bahwa pemblokir yang terdaftar tidak berasal dari salah satu dari dua database ini. Jika pemblokir dilaporkan ada di salah satu `rdsadmin` atau`template0`, hubungi dukungan karena basis data ini tidak dapat diakses pengguna dan memerlukan intervensi.
Sangat tidak mungkin bagi `template0` database `rdsadmin` atau untuk berisi pemblokir teratas.
**Saat vakum agresif sudah berjalan**
`postgres_get_av_diag()`Fungsi ini dirancang untuk melaporkan ketika proses vakum agresif berjalan, tetapi hanya memicu keluaran ini setelah vakum aktif setidaknya selama 1 menit. Penundaan yang disengaja ini membantu mengurangi kemungkinan positif palsu. Dengan menunggu, fungsi memastikan bahwa hanya penyedot debu yang efektif dan signifikan yang dilaporkan, yang mengarah pada pemantauan aktivitas vakum yang lebih akurat dan andal.
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika mendeteksi satu atau lebih vakum agresif yang sedang berlangsung.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Sebagaimana ditunjukkan dalam PEMBERITAHUAN, terus memantau kinerja vakum. Untuk informasi lebih lanjut tentang vakum agresif lihat [Vakum agresif (untuk mencegah pembungkus) sedang berjalan](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Saat autovacuum dimatikan**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut jika autovacuum dinonaktifkan pada instance database Anda:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum adalah fitur penting dari RDS Anda untuk PostgreSQL PostgreSQL PostgreSQL DB instance yang memastikan kelancaran operasi database. Ini secara otomatis menghapus versi baris lama, merebut kembali ruang penyimpanan, dan mencegah kembung tabel, membantu menjaga tabel dan indeks tetap efisien untuk kinerja optimal. Selain itu, ini melindungi terhadap sampul ID transaksi, yang dapat menghentikan transaksi di instans Amazon RDS Anda. Menonaktifkan autovacuum dapat menyebabkan penurunan jangka panjang dalam kinerja dan stabilitas database. Kami menyarankan Anda untuk tetap menggunakannya setiap saat.
Mematikan autovacuum tidak menghentikan penyedot debu agresif. Ini masih akan terjadi setelah tabel Anda mencapai `autovacuum_freeze_max_age` ambang batas.
**Jumlah transaksi yang tersisa sangat rendah**
`postgres_get_av_diag()`Fungsi ini menghasilkan PEMBERITAHUAN berikut ketika vakum sampul sudah dekat. PEMBERITAHUAN ini dikeluarkan ketika instans Amazon RDS Anda berjarak 100 juta transaksi dari kemungkinan menolak transaksi baru.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Tindakan segera Anda diperlukan untuk menghindari downtime database. Anda harus memonitor operasi penyedot debu Anda dan mempertimbangkan secara manual memulai database yang `VACUUM FREEZE` terpengaruh untuk mencegah kegagalan transaksi.