View a markdown version of this page

Lock:tuple - Amazon Aurora

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

Lock:tuple

Peristiwa Lock:tuple terjadi saat proses backend menunggu perolehan kunci pada tuple.

Versi mesin yang didukung

Informasi peristiwa tunggu ini didukung untuk semua versi Aurora PostgreSQL.

Konteks

Peristiwa Lock:tuple menunjukkan bahwa backend menunggu untuk memperoleh kunci pada tuple, sementara backend lain memegang kunci yang bertentangan pada tuple yang sama. Tabel berikut menggambarkan skenario saat sesi membuat peristiwa Lock:tuple.

Waktu

Sesi 1

Sesi 2

Sesi 3

t1

Memulai transaksi.

t2

Memperbarui baris 1.

t3

Memperbarui baris 1. Sesi ini mendapatkan kunci eksklusif pada tuple, lalu menunggu sesi 1 untuk melepaskan kunci dengan melakukan komit atau rollback.

t4

Memperbarui baris 1. Sesi ini menunggu sesi 2 untuk melepaskan kunci eksklusif pada tuple.

Atau Anda dapat mensimulasikan peristiwa tunggu ini dengan menggunakan alat tolok ukur pgbench. Konfigurasikan jumlah sesi konkuren yang tinggi untuk memperbarui baris yang sama pada tabel dengan file SQL kustom.

Untuk mempelajari selengkapnya tentang mode kunci yang bertentangan, lihat Explicit Locking dalam dokumentasi PostgreSQL. Untuk mempelajari selengkapnya tentang pgbench, lihat pgbench dalam dokumentasi PostgreSQL.

Kemungkinan penyebab peningkatan peristiwa tunggu

Saat peristiwa ini muncul lebih dari biasanya, yang mungkin menunjukkan adanya masalah performa, berikut adalah penyebab umumnya:

  • Sejumlah besar sesi konkuren mencoba mendapatkan kunci yang bertentangan untuk tuple yang sama dengan menjalankan pernyataan UPDATE atau DELETE.

  • Beberapa sesi yang sangat konkuren menjalankan pernyataan SELECT menggunakan mode kunci FOR UPDATE atau FOR NO KEY UPDATE.

  • Berbagai faktor mendorong aplikasi atau pool koneksi untuk membuka lebih banyak sesi agar menjalankan operasi yang sama. Saat sesi baru mencoba memodifikasi baris yang sama, beban DB dapat melonjak, dan Lock:tuple dapat ditampilkan.

Untuk informasi selengkapnya, lihat Row-Level Locks dalam dokumentasi PostgreSQL.

Tindakan

Kami merekomendasikan berbagai tindakan, tergantung pada penyebab peristiwa tunggu Anda.

Selidiki logika aplikasi

Cari tahu apakah sesi pemblokir telah berada pada status idle in transaction dalam waktu yang lama. Jika demikian, coba akhiri sesi pemblokir sebagai solusi jangka pendek. Anda dapat menggunakan fungsi pg_terminate_backend. Untuk informasi selengkapnya tentang fungsi ini, lihat Server Signaling Functions dalam dokumentasi PostgreSQL.

Untuk solusi jangka panjang, lakukan hal berikut:

  • Sesuaikan logika aplikasi.

  • Gunakan parameter idle_in_transaction_session_timeout. Parameter ini mengakhiri sesi apa pun dengan transaksi terbuka yang telah idle lebih lama dari jumlah waktu yang ditentukan. Untuk informasi selengkapnya, lihat Client Connection Defaults dalam dokumentasi PostgreSQL.

  • Gunakan autocommit sebanyak mungkin. Untuk informasi selengkapnya, lihat SET AUTOCOMMIT dalam dokumentasi PostgreSQL.

Temukan sesi pemblokir

Saat peristiwa tunggu Lock:tuple terjadi, identifikasi pemblokir dan sesi yang diblokir dengan mencari tahu kunci mana yang bergantung satu sama lain. Untuk informasi selengkapnya, lihat Informasi dependensi kunci pada wiki PostgreSQL. Untuk menganalisis peristiwa Lock:tuple yang lampau, gunakan fungsi Aurora aurora_stat_backend_waits.

Contoh berikut memberikan kueri semua sesi, memfilter tuple, dan mengurutkan berdasarkan wait_time.

--AURORA_STAT_BACKEND_WAITS SELECT a.pid, a.usename, a.app_name, a.current_query, a.current_wait_type, a.current_wait_event, a.current_state, wt.type_name AS wait_type, we.event_name AS wait_event, a.waits, a.wait_time FROM (SELECT pid, usename, left(application_name,16) AS app_name, coalesce(wait_event_type,'CPU') AS current_wait_type, coalesce(wait_event,'CPU') AS current_wait_event, state AS current_state, left(query,80) as current_query, (aurora_stat_backend_waits(pid)).* FROM pg_stat_activity WHERE pid <> pg_backend_pid() AND usename<>'rdsadmin') a NATURAL JOIN aurora_stat_wait_type() wt NATURAL JOIN aurora_stat_wait_event() we WHERE we.event_name = 'tuple' ORDER BY a.wait_time; pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time -------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+----------- 32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018 11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024

Kurangi konkurensi saat tinggi

Peristiwa Lock:tuple mungkin terjadi terus-menerus, terutama pada waktu beban kerja yang sibuk. Dalam situasi ini, pertimbangkan untuk mengurangi konkurensi tinggi untuk baris yang sangat sibuk. Sering kali, hanya beberapa baris mengontrol antrean atau logika Boolean, sehingga membuat baris ini sangat sibuk.

Anda dapat mengurangi konkurensi dengan menggunakan pendekatan yang berbeda berdasarkan kebutuhan bisnis, logika aplikasi, dan jenis beban kerja. Misalnya, Anda dapat melakukan hal berikut:

  • Desain ulang tabel dan logika data Anda untuk mengurangi konkurensi tinggi.

  • Ubah logika aplikasi untuk mengurangi konkurensi tinggi di tingkat baris.

  • Manfaatkan dan desain ulang kueri dengan kunci tingkat baris.

  • Gunakan klausa NOWAIT dengan operasi percobaan ulang.

  • Pertimbangkan untuk menggunakan kontrol konkurensi logika optimistis dan kontrol konkurensi logika penguncian hibrid.

  • Pertimbangkan untuk mengubah tingkat isolasi basis data.

Pecahkan masalah bottleneck

Lock:tuple dapat terjadi dengan bottleneck seperti "CPU starvation" atau penggunaan maksimum bandwidth Amazon EBS. Untuk mengurangi bottleneck, pertimbangkan pendekatan berikut:

  • Naikkan skala jenis kelas instans Anda.

  • Optimalkan kueri sarat sumber daya.

  • Ubah logika aplikasi.

  • Arsipkan data yang jarang diakses.