Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# LWLock:MultiXact
Peristiwa tunggu `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU`, dan `LWLock:MultiXactOffsetSLRU` menunjukkan bahwa sesi sedang menunggu pengambilan daftar transaksi yang memodifikasi baris yang sama pada tabel tertentu.
+ `LWLock:MultiXactMemberBuffer` – Suatu proses sedang menunggu I/O pada buffer simple least-recently used (SLRU) untuk anggota multixact.
+ `LWLock:MultiXactMemberSLRU` – Suatu proses sedang menunggu akses cache simple least-recently used (SLRU) untuk anggota multixact.
+ `LWLock:MultiXactOffsetBuffer` – Suatu proses sedang menunggu I/O pada buffer simple least-recently used (SLRU) untuk offset multixact.
+ `LWLock:MultiXactOffsetSLRU` – Suatu proses sedang menunggu akses cache simple least-recently used (SLRU) untuk offset multixact.
**Topics**
+ [
## Versi mesin yang didukung
](#apg-waits.xactsync.context.supported)
+ [
## Konteks
](#apg-waits.lwlockmultixact.context)
+ [
## Kemungkinan penyebab peningkatan peristiwa tunggu
](#apg-waits.lwlockmultixact.causes)
+ [
## Tindakan
](#apg-waits.lwlockmultixact.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.
## Konteks
*Multixact* adalah struktur data yang menyimpan daftar transaksi IDs (XIDs) yang memodifikasi baris tabel yang sama. Saat satu transaksi merujuk suatu baris dalam tabel, ID transaksi disimpan pada baris header tabel. Ketika beberapa transaksi mereferensikan baris yang sama dalam tabel, daftar transaksi IDs disimpan dalam struktur data multixact. Peristiwa tunggu multixact menunjukkan bahwa sesi mengambil dari struktur data daftar transaksi yang merujuk ke baris tertentu dalam tabel.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Tiga penyebab umum penggunaan multixact adalah sebagai berikut:
+ **Subtransaksi dari titik simpan eksplisit** – Secara eksplisit membuat titik simpan pada transaksi Anda yang memunculkan transaksi baru untuk baris yang sama. Misalnya, menggunakan `SELECT FOR UPDATE`, lalu `SAVEPOINT`, dan `UPDATE`.
Beberapa driver, pemetaan relasional objek (ORMs), dan lapisan abstraksi memiliki opsi konfigurasi untuk secara otomatis membungkus semua operasi dengan savepoint. Hal ini dapat membuat banyak peristiwa tunggu multixact di beberapa beban kerja. Opsi `autosave` Driver JDBC PostgreSQL adalah contohnya. Untuk informasi selengkapnya, lihat [pgJDBC](https://jdbc.postgresql.org/) pada dokumentasi JDBC PostgreSQL. Contoh lainnya adalah driver ODBC PostgreSQL dan opsi `protocol`. Untuk informasi selengkapnya, lihat [Opsi Konfigurasi psqlODBC](https://odbc.postgresql.org/docs/config.html) pada dokumentasi driver ODBC PostgreSQL.
+ **Subtransaksi dari klausa PL/pgSQL EXCEPTION** – Setiap klausa `EXCEPTION` yang Anda tulis dalam fungsi atau prosedur PL/pgSQL membuat `SAVEPOINT` secara internal.
+ **Kunci asing** – Beberapa transaksi memperoleh kunci bersama pada catatan induk.
Ketika baris tertentu disertakan dalam operasi transaksi ganda, memproses baris memerlukan pengambilan transaksi IDs dari `multixact` daftar. Jika pencarian tidak mendapatkan multixact dari cache memori, struktur data harus dibaca dari lapisan penyimpanan Aurora. I/O dari penyimpanan ini berarti kueri SQL dapat memerlukan waktu lebih lama. Kesalahan cache memori dapat mulai terjadi dengan penggunaan yang berat karena jumlah transaksi ganda yang besar. Semua faktor ini berkontribusi pada peningkatan peristiwa tunggu ini.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda. Beberapa tindakan ini dapat membantu untuk segera mengurangi peristiwa tunggu. Namun, yang lainnya mungkin memerlukan penyelidikan dan koreksi untuk menskalakan beban kerja Anda.
**Topics**
+ [
### Lakukan pembekuan vakum di atas tabel dengan peristiwa tunggu ini
](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [
### Tingkatkan frekuensi autovacuum pada tabel dengan peristiwa tunggu ini
](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [
### Meningkatkan parameter memori
](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [
### Mengurangi transaksi jangka panjang
](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [
### Tindakan jangka panjang
](#apg-waits.lwlockmultixact.actions.longactions)
### Lakukan pembekuan vakum di atas tabel dengan peristiwa tunggu ini
Jika peristiwa tunggu ini melonjak mendadak dan memengaruhi lingkungan produksi, Anda dapat menggunakan salah satu metode sementara berikut untuk mengurangi penghitungannya.
+ Gunakan *VACUUM FREEZE* pada tabel atau partisi tabel yang terpengaruh untuk segera menyelesaikan masalah. Untuk informasi selengkapnya, lihat [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Gunakan klausa VACUUM (FREEZE, INDEX\$1CLEANUP FALSE) untuk melakukan vakum cepat dengan melewati indeks. Untuk informasi selengkapnya, lihat [Memvakum tabel secepat mungkin](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Tingkatkan frekuensi autovacuum pada tabel dengan peristiwa tunggu ini
Setelah memindai semua tabel di semua basis data, VACUUM akan menghapus multixact, dan nilai multixact tertua akan dimajukan. Untuk informasi selengkapnya, lihat [Multixact dan Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Untuk menjaga LWLock: MultiXact tunggu acara seminimal mungkin, Anda harus menjalankan VACUUM sesering yang diperlukan. Untuk melakukannya, pastikan bahwa VACUUM di klaster DB Aurora PostgreSQL Anda dikonfigurasi secara optimal.
Jika menggunakan VACUUM FREEZE pada tabel atau partisi tabel yang terpengaruh menyelesaikan masalah peristiwa tunggu, sebaiknya gunakan penjadwal, seperti `pg_cron`, untuk melakukan VACUUM daripada menyesuaikan autovacuum pada tingkat instans.
Agar autovacuum terjadi lebih sering, Anda dapat mengurangi nilai parameter penyimpanan `autovacuum_multixact_freeze_max_age` pada tabel yang terpengaruh. Untuk informasi selengkapnya, lihat [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Meningkatkan parameter memori
Anda dapat mengoptimalkan penggunaan memori untuk cache multixact dengan menyesuaikan parameter berikut. Pengaturan ini mengontrol berapa banyak memori yang disediakan untuk cache ini, yang dapat membantu mengurangi peristiwa menunggu multixact di beban kerja Anda. Kami merekomendasikan memulai dengan nilai-nilai berikut:
Untuk Aurora PostgreSQL 17 dan yang lebih baru:
+ `multixact_offset_buffers`= 128
+ `multixact_member_buffers`= 256
Untuk Aurora PostgreSQL 16 dan sebelumnya:
+ `multixact_offsets_cache_size`= 128
+ `multixact_members_cache_size`= 256
**catatan**
Di Aurora PostgreSQL 17, nama parameter diubah dari `multixact_offsets_cache_size` ke `multixact_offset_buffers` dan dari menjadi selaras dengan komunitas PostgreSQL 17. `multixact_members_cache_size` `multixact_member_buffers`
Anda dapat mengatur parameter ini di tingkat cluster sehingga semua instance di cluster Anda tetap konsisten. Kami menyarankan Anda untuk menguji dan menyesuaikan nilai agar sesuai dengan persyaratan beban kerja spesifik dan kelas instance Anda. Anda harus me-reboot instance writer agar perubahan parameter diterapkan.
Parameter dinyatakan dalam hal entri cache multixact. Setiap entri cache menggunakan `8 KB` memori. Untuk menghitung total memori yang dicadangkan, kalikan setiap nilai parameter dengan`8 KB`. Misalnya, jika Anda menyetel parameter ke 128, total memori cadangan akan menjadi`128 * 8 KB = 1 MB`.
### Mengurangi transaksi jangka panjang
Transaksi jangka panjang menyebabkan vakum mempertahankan informasinya hingga transaksi tersebut dilakukan atau hingga transaksi hanya dibaca ditutup. Kami merekomendasikan Anda untuk secara proaktif memantau dan mengelola transaksi jangka panjang. Untuk informasi selengkapnya, lihat [Basis data telah lama berjalan idle dalam koneksi transaksi](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Cobalah untuk memodifikasi aplikasi Anda untuk menghindari atau meminimalkan penggunaan transaksi jangka panjang Anda.
### Tindakan jangka panjang
Periksa beban kerja Anda untuk menemukan penyebab limpahan multixact. Anda harus memperbaiki masalah tersebut untuk menskalakan beban kerja Anda dan mengurangi peristiwa tunggu.
+ Anda harus menganalisis DDL (data definition language) yang digunakan untuk membuat tabel Anda. Pastikan bahwa struktur dan indeks tabel dirancang dengan baik.
+ Saat tabel yang terpengaruh memiliki kunci asing, tentukan apakah diperlukan atau jika ada cara lain untuk memberlakukan integritas referensial.
+ Saat sebuah tabel memiliki indeks besar yang tidak digunakan, hal tersebut dapat menyebabkan autovacuum tidak sesuai dengan beban kerja Anda dan mungkin memblokirnya agar tidak berjalan. Untuk menghindari hal ini, periksa indeks yang tidak digunakan dan hapus sepenuhnya. Untuk informasi selengkapnya, lihat [Mengelola autovacuum dengan indeks besar](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Kurangi penggunaan titik simpan dalam transaksi Anda.