View a markdown version of this page

Menyelesaikan penghambat vakum yang tidak dapat diidentifikasi di RDS for PostgreSQL - Amazon Relational Database Service

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menyelesaikan penghambat vakum yang tidak dapat diidentifikasi di RDS for PostgreSQL

Bagian ini mengeksplorasi alasan tambahan yang dapat mencegah penyedot debu membuat kemajuan. Masalah ini saat ini tidak dapat diidentifikasi secara langsung oleh postgres_get_av_diag() fungsi.

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 autopacuum 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 tipe 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 menyediakan informasi berikut:

  • “base” adalah nama direktori di bawah direktori data PostgreSQL.

  • “16403" adalah database OID, yang dapat Anda cari di katalog pg_database sistem.

  • “186752608" adalahrelfilenode, yang dapat Anda gunakan untuk mencari skema dan nama objek dalam katalog sistem. pg_class

Dengan memeriksa output dari kueri berikut di database yang terkena dampak, Anda dapat menentukan jenis objek. Kueri 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 dokumentasi PostgreSQL pg_class untuk semua jenis objek yang didukung, dicatat oleh relkind kolom di. pg_class

Bimbingan

Solusi paling efektif untuk masalah ini bergantung pada konfigurasi instans Amazon RDS spesifik Anda dan jenis data yang terkena dampak halaman yang tidak konsisten.

Jika tipe objek adalah indeks:

Direkomendasikan untuk membangun kembali indeks.

  • 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, CONCURRENTLY opsi ini memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintahnya:

    REINDEX INDEX ix_name CONCURRENTLY;

    Meskipun CONCURRENTLY kurang mengganggu, itu bisa lebih lambat di meja sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan.

    Untuk informasi selengkapnya, lihat dokumentasi PostgreSQL RE INDEX.

  • Menggunakan INDEX_CLEANUP FALSE opsi — Jika indeks besar dan diperkirakan membutuhkan waktu yang signifikan untuk menyelesaikannya, Anda dapat membuka blokir autopacuum dengan menjalankan manual VACUUM FREEZE sambil mengecualikan indeks. Fungsi ini tersedia di PostgreSQL versi 12 dan versi yang lebih baru.

    Melewati indeks akan memungkinkan Anda untuk melewatkan proses vakum dari indeks yang tidak konsisten dan mengurangi masalah pembungkus. 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 tipe objek adalah tampilan yang terwujud:

Jika kesalahan halaman tidak valid terjadi pada tampilan yang terwujud, masuk ke database yang terkena dampak dan segarkan untuk menyelesaikan halaman yang tidak valid:

Segarkan tampilan yang 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 yang terwujud 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 autocacuum 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 INDEX_CLEANUP manualVACUUM FREEZE. Untuk informasi tentang cara membangun kembali indeks, lihat Jika tipe objek adalah indeks.

  • Menggunakan opsi CONCURENT LY — 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 CONCURENTLY memungkinkan penguncian tingkat baris, secara signifikan meningkatkan ketersediaan tabel. Berikut ini adalah perintahnya:

    REINDEX INDEX ix_name CONCURRENTLY;

    Sementara CONCURENTLY kurang mengganggu, itu bisa lebih lambat di meja sibuk. Pertimbangkan untuk membangun indeks selama periode lalu lintas rendah jika memungkinkan. Untuk informasi selengkapnya, lihat REINDEX dalam dokumentasi PostgreSQL.

  • Menggunakan opsi INDEX_CLEANUP FALSE — Jika indeks besar dan diperkirakan membutuhkan waktu yang signifikan untuk menyelesaikannya, Anda dapat membuka blokir autopacuum 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 melewatkan proses vakum dari indeks yang tidak konsisten dan mengurangi masalah pembungkus. 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 mempengaruhi kinerja autopacuum, yang menyebabkan pembersihan tupel mati yang lebih lambat dan peningkatan risiko pembungkus 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 database berikut, yang diekspos melalui Performance Insights API, untuk mengukur tingkat transaksi (jumlah xact_commit dan xact_rollback) yang merupakan jumlah total transaksi.

Penghitung Jenis Unit Metrik

xact_commit

Transaksi

Commit per detik

db. Transactions.xact_komit

xact_rollback

Transaksi

Pemulihan per detik

db. Transactions.xact_kembalikan

Peningkatan yang cepat menunjukkan beban transaksi yang tinggi, yang dapat membanjiri autocacuum, menyebabkan kembung, perselisihan kunci, dan potensi masalah kinerja. Ini dapat berdampak negatif pada proses autopacuum dalam beberapa cara:

  • Aktivitas Tabel: Tabel tertentu yang sedang disedot bisa mengalami volume transaksi yang tinggi, menyebabkan penundaan.

  • Sumber Daya Sistem Keseluruhan sistem mungkin kelebihan beban, sehingga sulit bagi autopacuum untuk mengakses sumber daya yang diperlukan agar berfungsi secara efisien.

Pertimbangkan strategi berikut untuk memungkinkan autopacuum beroperasi lebih efektif dan mengikuti tugasnya:

  1. Kurangi tingkat transaksi jika memungkinkan. Pertimbangkan untuk melakukan batch atau mengelompokkan transaksi serupa jika memungkinkan.

  2. Targetkan tabel yang sering diperbarui dengan VACUUM FREEZE operasi manual setiap malam, mingguan, atau dua mingguan selama jam di luar jam sibuk.

  3. Pertimbangkan untuk meningkatkan kelas instance Anda untuk mengalokasikan lebih banyak sumber daya sistem untuk menangani volume transaksi tinggi dan autopacuum.