Temuduga PostgreSQL: Bagaimana MVCC dan VACUUM Bekerjasama?

Prompt dan Konteks yang Berkenaan

Satu jadual orders PostgreSQL 18 mempunyai 500 juta baris hidup dan kemas kini yang berterusan. Pasukan tersebut memerhatikan empat fakta:

• n_dead_tup terus meningkat;
• pekerja autovacuum muncul secara berkala;
• pg_relation_size('orders') tidak berkurangan selepas pembersihan vakum biasa;
• satu sesi aplikasi telah berada dalam keadaan idle in transaction selama enam jam dan mendedahkan backend_xmin yang lama.

Terangkan rantaian lengkap daripada kebolehlihatan MVCC hingga pembersihan fizikal. Diagnosis insiden tersebut, pilih urutan pemulihan yang selamat, dan nyatakan bukti yang diperlukan sebelum mengisytiharkannya selesai. Angka-angka ini adalah input latihan, bukan ambang operasi sejagat.

Ini terpakai kepada temuduga backend, pangkalan data, platform, dan SRE di mana calon mesti menghubungkan semantik konkurensi dengan tingkah laku storan pengeluaran. SQL hanyalah bahasa pemeriksaan.

Perkara yang Dinilai oleh Penemuduga

Ujian pertama adalah sama ada calon memahami bahawa UPDATE ialah penciptaan versi. PostgreSQL menyimpan metadata tupel seperti ID transaksi yang memasukkan (xmin) dan ID transaksi yang memadam atau menggantikan (xmax). Satu snapshot menggabungkan sempadan transaksi dan status komit untuk menentukan versi mana yang kelihatan. Peraturannya lebih tepat daripada sekadar "pilih baris dengan xmin terbesar."

Ujian kedua adalah sama ada calon boleh menghubungkan kebolehlihatan dengan pembersihan. Versi lama tidak boleh dialih keluar selagi snapshot yang aktif mungkin masih memerlukannya. Transaksi terbuka yang lama, transaksi yang disediakan (prepared transaction), atau slot replikasi boleh menahan horizon pembersihan daripada maju. Autovacuum mungkin berjalan dengan jayanya namun melaporkan tupel yang telah mati tetapi tidak boleh dialih keluar.

Ujian ketiga ialah ketepatan operasi. VACUUM biasa kebiasaannya menjadikan ruang mati boleh digunakan semula di dalam hubungan (relation); ia biasanya tidak mengecilkan fail hubungan tersebut. VACUUM FULL menulis semula hubungan, memerlukan ruang cakera sementara tambahan, dan mengambil kunci ACCESS EXCLUSIVE. Ia merupakan operasi penyelenggaraan yang luar biasa, bukan tindak balas pertama kepada anggaran tupel mati yang meningkat.

Akhir sekali, calon mesti membezakan empat isyarat: anggaran kiraan tupel, ruang yang boleh ditebus guna, saiz hubungan, dan prestasi yang dapat dilihat oleh pengguna. Perkara-perkara ini berkaitan tetapi tidak boleh ditukar ganti. n_dead_tup yang menurun tidak membuktikan bahawa fail sistem pengendalian telah mengecil, dan saiz fail yang tidak berubah tidak membuktikan bahawa vakum telah gagal.

Soalan untuk Dijelaskan Sebelum Menjawab

• Apakah tahap pengasingan (isolation levels) yang sedang digunakan? Di bawah Read Committed, setiap kenyataan biasanya mendapat snapshot baharu; Repeatable Read dan Serializable mengekalkan snapshot peringkat transaksi. Transaksi yang melahu boleh mengekalkan horizon snapshotnya walaupun tidak melakukan sebarang kerja.
• Adakah backend_xmin yang lama itu penghalang global? Wujudkan korelasi dan bukannya membuat andaian. Transaksi yang disediakan, slot replikasi logikal atau fizikal, dan sesi-sesi lain mungkin mendedahkan horizon yang lebih lama.
• Adakah statistik cukup terkini untuk membimbing insiden tersebut? n_dead_tup dan n_live_tup adalah anggaran. Baca ia bersama-sama waktu vakum terakhir, kemajuan, log, saiz hubungan, dan tingkah laku beban kerja.
• Adakah matlamatnya penggunaan semula cakera atau pengecilan fail serta-merta? Pembersihan vakum rutin menyasarkan penggunaan semula dalam keadaan mantap (steady-state). Mengembalikan sejumlah besar ruang kepada sistem pengendalian memerlukan penulisan semula atau pelan pembinaan semula dalam talian (online rebuild) yang sesuai.
• Bolehkah aplikasi menamatkan transaksi enam jam tersebut dengan selamat? Kenal pasti pemilik dan operasi perniagaan terlebih dahulu. Membatalkan atau menamatkannya akan mengundur balik (roll back) kerja terbukanya dan mungkin menjejaskan aliran pengguna.
• Apakah yang berubah dalam beban kerja? Kadar kemas kini, lajur yang diindeks, lebar baris, tetapan autovacuum, ketepuan pekerja, dan jangka hayat transaksi semuanya mempengaruhi pusing ganti versi dan kapasiti pembersihan.
• Berapa banyak impak kunci dan I/O yang dibenarkan? Pelan pemulihan mesti mengekalkan kependaman (latency), replikasi, ruang lebihan cakera (disk headroom), dan ketersediaan, bukan sekadar menyelesaikan penyelenggaraan dengan cepat.

Rangka Jawapan 30-Saat

"MVCC PostgreSQL membolehkan setiap kenyataan membaca snapshot yang konsisten sementara kemas kini mencipta versi tupel baharu. Versi lama kekal sehingga tiada snapshot aktif yang boleh melihatnya. Di sini, transaksi terbuka selama enam jam mungkin menahan backend_xmin daripada maju, jadi autovacuum boleh mengimbas jadual tetapi tidak boleh mengalih keluar versi yang masih berpotensi untuk dilihat.

Saya akan terlebih dahulu mengesahkan horizon tertua merentasi sesi, transaksi yang disediakan, dan slot replikasi; mengaitkannya dengan statistik jadual, kemajuan vakum, log, dan saiz; kemudian menamatkan penghalang yang telah disahkan melalui aplikasi pemilik. Saya akan menjalankan atau membiarkan vakum biasa menyusul di bawah had I/O yang diukur dan mengesahkan bahawa anggaran tupel mati serta tingkah laku penggunaan semula menjadi stabil. VACUUM biasa menjadikan ruang boleh digunakan semula dan biasanya tidak mengecilkan fail. VACUUM FULL menulis semula dan mengunci jadual secara eksklusif, jadi ia memerlukan keputusan penyelenggaraan yang berasingan. Akhir sekali, saya akan mengehadkan jangka hayat transaksi, melaraskan jadual kerap dikemas kini mengikut hubungan, memantau umur XID, dan mengekalkan pembekuan supaya XID lama tidak akan melintasi horizon wraparound."

Perbincangan Terperinci Langkah demi Langkah

Langkah 1: Jejaki Satu Kemas Kini Melalui MVCC

Katakan transaksi 100 memasukkan satu versi pesanan. Pengepala tupelnya merekodkan XID pemasukan dalam xmin. Kemudian, transaksi 220 mengemas kini pesanan tersebut. PostgreSQL mencipta tupel pengganti dan menandakan versi lama sebagai telah digantikan menggunakan metadata transaksi termasuk xmax; ia tidak menulis ganti bait lama di tempat asal (in place) seperti yang mungkin dicadangkan oleh model logikal.

Pembaca memeriksa snapshot dan status komit transaksinya untuk menentukan versi mana yang kelihatan. Secara ringkas, ia menolak versi yang dimasukkan oleh transaksi yang belum dikomit atau berada pada masa hadapan snapshot, dan ia mungkin mengekalkan versi yang transaksi pemadamnya belum lagi kelihatan. Peraturan kebolehlihatan sebenar juga mengendalikan transaksi semasa, transaksi yang dibatalkan, ID arahan, dan hint bits, jadi membandingkan nilai angka xmin dan xmax sahaja bukanlah pelaksanaan yang betul.

Model ini mengurangkan konflik kunci baca/tulis: pembaca biasa tidak menyekat penulis, dan penulis tidak menyekat pembaca biasa. Ini tidak bermakna penulis tidak pernah menyekat satu sama lain. Dua transaksi yang mengemas kini baris logikal yang sama masih boleh menunggu atau berkonflik, dan tahap pengasingan yang lebih tinggi boleh membatalkan transaksi untuk mengekalkan jaminannya.

Langkah 2: Terbitkan Horizon Pembersihan

Selepas transaksi 220 dikomit, tupel lama menjadi lapuk untuk snapshot baharu. Ia tidak boleh dialih keluar serta-merta jika snapshot yang bermula lebih awal masih boleh melihatnya. Vakum memilih titik henti (cutoff) berdasarkan horizon berkaitan yang tertua. Versi yang lebih baharu daripada sempadan keselamatan tersebut mungkin "mati baru-baru ini" (recently dead): lapuk secara logikal kepada kerja semasa tetapi belum selamat untuk dialih keluar.

Sesi idle in transaction selama enam jam adalah berbahaya kerana klien telah meninggalkan transaksi yang terbuka. backend_xmin miliknya boleh mengekalkan snapshot lama walaupun pelayan sedang menunggu arahan klien seterusnya. Siasatan yang sama mesti merangkumi:

• pg_prepared_xacts, kerana transaksi yang disediakan boleh mengekalkan XID lama;
• pg_replication_slots, kerana xmin atau catalog_xmin boleh mengekalkan baris atau katalog yang diperlukan;
• baris pg_stat_activity lain dengan backend_xid atau backend_xmin yang lama;
• maklum balas replika dan konfigurasi penyahkodan logikal, kerana keperluan replikasi boleh mempengaruhi pembersihan.

Oleh itu, rantaian sebab-akibatnya ialah: horizon jangka panjang → versi lama kekal berpotensi untuk dilihat → vakum tidak dapat menebus gunanya → kerja heap dan indeks terkumpul → kecekapan cache dan kos imbasan boleh merosot. Rantaian tersebut mesti ditunjukkan dengan cap masa dan horizon yang sejajar, bukan disimpulkan daripada satu nama sesi yang melahu.

Langkah 3: Diagnosis dengan Anggaran, Kemajuan, dan Saiz Secara Berasingan

Mulakan dengan snapshot baca sahaja bagi aktiviti dan statistik hubungan:

SELECT pid,
       usename,
       application_name,
       state,
       xact_start,
       age(backend_xid) AS xid_age,
       age(backend_xmin) AS xmin_age,
       wait_event_type,
       wait_event,
       left(query, 120) AS query_sample
FROM pg_stat_activity
WHERE backend_xid IS NOT NULL OR backend_xmin IS NOT NULL
ORDER BY GREATEST(
  COALESCE(age(backend_xid), 0),
  COALESCE(age(backend_xmin), 0)
) DESC;

SELECT relid::regclass AS relation,
       n_live_tup,
       n_dead_tup,
       n_tup_upd,
       n_tup_hot_upd,
       last_vacuum,
       last_autovacuum,
       vacuum_count,
       autovacuum_count
FROM pg_stat_user_tables
WHERE relid = 'orders'::regclass;

SELECT pg_size_pretty(pg_relation_size('orders')) AS heap_size,
       pg_size_pretty(pg_indexes_size('orders')) AS index_size,
       pg_size_pretty(pg_total_relation_size('orders')) AS total_size;

n_dead_tup ialah anggaran, bukan ukuran kembung yang tepat. last_autovacuum membuktikan bahawa seorang pekerja telah selesai, bukan bahawa ia telah mengalih keluar setiap versi lapuk. Hubungan yang besar boleh menjadi sihat jika halaman yang dikosongkan digunakan semula pada kadar ketibaan versi baharu. Sebaliknya, saiz hubungan yang stabil boleh menyembunyikan kependaman yang meningkat atau pusing ganti indeks.

Semasa vakum aktif, periksa pg_stat_progress_vacuum untuk fasanya dan blok heap yang diimbas. Gunakan log autovacuum atau output VACUUM (VERBOSE) untuk mengetahui bilangan tupel yang dialih keluar, bilangan yang kekal tidak boleh dialih keluar, dan sama ada pembekuan telah maju. Periksa pg_stat_all_tables, sejarah saiz hubungan, kependaman pertanyaan, tekanan penimbal dan I/O, kadar WAL, kelengahan replikasi (replication lag), dan ruang lebihan cakera pada garis masa yang sama.

Langkah 4: Pulihkan Mengikut Urutan Paling Selamat

Mula-mula kenal pasti pemilik dan tujuan transaksi tertua. Jika ia ditinggalkan, tutupnya melalui aplikasi atau pemilik sambungan. Jika ia adalah kerja perniagaan yang aktif, tentukan sama ada pengunduran balik boleh diterima sebelum pembatalan. PostgreSQL mendedahkan pg_cancel_backend dan pg_terminate_backend, tetapi akses kepada fungsi bukanlah kebenaran untuk mengganggu pengeluaran.

Seterusnya selesaikan sebarang transaksi yang disediakan yang lebih lama atau slot replikasi lapuk melalui sistem pemiliknya. Menggugurkan slot yang aktif boleh memerlukan pembinaan semula replika atau kehilangan kedudukan penyahkodan yang dijangkakan, jadi ini adalah keputusan pemulihan yang eksplisit.

Selepas horizon maju, benarkan autovacuum menyusul atau jalankan VACUUM (VERBOSE, ANALYZE) orders biasa yang disasarkan semasa tetingkap yang diukur. Perhatikan kependaman, I/O, WAL, kelengahan replikasi, kemajuan vakum, dan baki ruang lebihan cakera. Jangan lancarkan pelbagai kerja penyelenggaraan yang bersaing semata-mata kerana kerja pertama mengambil masa.

Kemudian sahkan hasil:

• backend_xmin atau horizon slot tertua yang berkaitan telah maju;
• vakum melaporkan bahawa versi mati yang disimpan sebelum ini kini boleh dialih keluar dan telah dialih keluar;
• n_dead_tup menunjukkan trend menurun selepas penyegaran statistik;
• kemas kini baharu menggunakan semula ruang yang tersedia dan pertumbuhan hubungan kembali kepada keadaan mantap yang dijangkakan;
• kependaman permintaan, kos imbasan indeks, WAL, dan kelengahan replika kekal dalam had yang dipersetujui;
• age(relfrozenxid) dan umur XID pangkalan data mempunyai ruang lebihan yang selamat.

Hanya selepas bukti ini barulah pasukan perlu menilai pemadatan fizikal. VACUUM FULL orders mencipta salinan padat baharu, memerlukan cakera tambahan semasa penulisan semula, dan memegang kunci ACCESS EXCLUSIVE. Jadual dengan 500 juta baris mungkin memerlukan strategi pembinaan semula dalam talian atau penggantian partisyen yang dirancang. Pilihan yang tepat bergantung pada masa henti (downtime), cakera bebas, replikasi, kunci asing, penumpuan penulisan, dan pengunduran balik—bukan keinginan untuk mengecilkan satu metrik saiz semata-mata.

Langkah 5: Terangkan Autovacuum Tanpa Keajaiban

Autovacuum bertindak balas terhadap statistik kumulatif. Untuk kemas kini dan pemadaman, PostgreSQL 18 menggunakan pencetus berbentuk:

vacuum threshold = min(
  autovacuum_vacuum_max_threshold,
  autovacuum_vacuum_threshold
    + autovacuum_vacuum_scale_factor * pg_class.reltuples
)

Pembersihan vakum yang didorong oleh pemasukan mempunyai ambang berasingan berdasarkan tupel yang dimasukkan dan pecahan halaman yang belum dibekukan. Pembersihan vakum anti-wraparound juga dipaksa oleh umur XID walaupun autovacuum biasa telah dilumpuhkan untuk sesuatu jadual.

Pada hubungan yang sangat besar dan padat dengan kemas kini, faktor skala global boleh menyebabkan ia menunggu terlalu banyak perubahan atau mencipta kerja yang bertimbun secara mendadak. Laraskan parameter storan jadual berdasarkan pengeluaran versi yang diukur dan kapasiti vakum. Periksa juga ketersediaan pekerja dan kelewatan kos (cost delay): pencetus yang betul tidak menjamin bahawa pekerja bermula serta-merta atau selesai lebih cepat daripada sampah yang dicipta oleh beban kerja.

Pencegahan juga harus dilakukan pada laluan penulisan. Pastikan transaksi pendek dan elakkan panggilan rangkaian atau masa berfikir pengguna (user think time) di dalamnya. Gunakan idle_in_transaction_session_timeout secara selektif kepada peranan aplikasi yang sesuai, kerana kolam sambungan dan kerja sah yang panjang memerlukan pengendalian yang serasi. Kemas kini lajur yang perlu sahaja. Apabila tiada lajur yang diindeks berubah dan tupel baharu muat pada halaman heap yang sama, kemas kini HOT boleh mengelakkan entri indeks baharu; fillfactor mungkin meningkatkan peluang tersebut dengan kos membiarkan lebih banyak ruang halaman tidak digunakan pada mulanya.

Langkah 6: Hubungkan Pembekuan dengan XID Wraparound

ID transaksi biasa adalah 32-bit dan dibandingkan dalam ruang membulat (circular space). Satu XID biasa mempunyai kira-kira dua bilion ID yang dianggap lebih lama dan dua bilion dianggap lebih baharu. Jika sesuatu tupel mengekalkan XID pemasukan biasa selama-lamanya, lama-kelamaan nilai yang sangat lama boleh kelihatan seperti berada pada masa hadapan.

Vakum menghalang perkara ini dengan membekukan versi tupel yang telah dikomit dan cukup lama. PostgreSQL moden mewakili pembekuan dengan status tupel sambil mengekalkan xmin asal untuk kebolehlihatan forensik; versi yang dibekukan dianggap lebih tua daripada setiap transaksi biasa. Penanda XID beku jadual dan pangkalan data merekodkan sejauh mana kerja ini telah berkembang.

Ini ialah keperluan ketepatan (correctness), bukan sekadar pengemasan kembung pilihan. Pantau age(pg_class.relfrozenxid) dan age(pg_database.datfrozenxid), siasat vakum anti-wraparound, dan kekalkan kapasiti yang mencukupi untuk ia selesai. Meningkatkan had pembekuan hanyalah menangguhkan kerja dan mengurangkan tetingkap keselamatan; ia tidak menghapuskan kekangan XID membulat.

Contoh Jawapan yang Mantap

"Saya akan memodelkan insiden ini sebagai pengeluaran versi berbanding penebusgunaan yang selamat. MVCC PostgreSQL memberikan setiap kenyataan atau transaksi satu snapshot. Kemas kini mencipta tupel pengganti dan menandakan versi lama melalui metadata transaksi. Pembaca menilai xmin, xmax, status komit, dan snapshotnya untuk memilih versi yang kelihatan. Ini membolehkan operasi membaca dan menulis biasa diteruskan tanpa konflik kunci baca, manakala penulis pada baris yang sama masih boleh disekat atau dibatalkan.

Versi lama tidak boleh dialih keluar sehingga tiada snapshot berkaitan yang boleh melihatnya. Saya akan memeriksa semua sesi untuk backend_xid dan backend_xmin yang lama, kemudian transaksi yang disediakan dan slot replikasi. Transaksi melahu selama enam jam adalah suspek utama kerana transaksi terbuka boleh mengekalkan horizon snapshotnya, tetapi saya akan membuktikan bahawa ia adalah penghalang tertua sebelum menamatkannya.

Saya akan mengaitkan horizon tersebut dengan pg_stat_user_tables, pg_stat_progress_vacuum, log autovacuum, saiz heap dan indeks, pertumbuhan hubungan, kependaman, I/O, WAL, dan kelengahan replikasi. n_dead_tup ialah anggaran, dan cap masa autovacuum hanya membuktikan larian telah berlaku. Jika pemilik mengesahkan transaksi tersebut telah ditinggalkan, saya akan menutupnya, menyelesaikan sebarang horizon yang lebih lama, dan membiarkan vakum biasa yang disasarkan menyusul di bawah beban yang diukur.

VACUUM biasa mengalih keluar versi yang selamat untuk dialih keluar dan menjadikan ruangnya boleh digunakan semula. Ia biasanya mengekalkan fail hubungan pada saiz yang sama. VACUUM FULL menulis semula hubungan, memerlukan cakera sementara, dan mengunci jadual secara eksklusif, jadi saya hanya akan mempertimbangkannya di bawah keputusan pemadatan yang dirancang dengan strategi masa henti atau pembinaan semula dalam talian.

Untuk pencegahan, saya akan mengehadkan jangka hayat transaksi, menetapkan tamat masa transaksi melahu yang bersesuaian dengan peranan, memantau horizon tertua dan umur XID, melaraskan autovacuum bagi setiap jadual kerap dikemas kini berdasarkan pusing ganti yang diukur, dan menggalakkan kemas kini HOT di mana skema dan beban kerja membenarkannya. Vakum juga membekukan versi terkomit yang cukup lama supaya XID mereka sentiasa dianggap sebagai masa lalu, menghalang wraparound. Kejayaan bermakna horizon penghalang telah maju, tupel yang boleh dialih keluar dibersihkan, penggunaan semula ruang menstabilkan pertumbuhan, SLO perkhidmatan kekal sihat, dan umur XID beku mengekalkan ruang lebihan yang selamat."

Kesilapan Biasa dan Penambahbaikan

• Menyatakan bahawa UPDATE mengubah suai satu baris di tempat asal → PostgreSQL biasanya mencipta versi tupel heap baharu → jejaki pendahulu dan pengganti melalui metadata MVCC.
• Mengurangkan kebolehlihatan kepada xmin < current_xid → status komit, sempadan snapshot, transaksi aktif, xmax, dan peraturan arahan adalah penting → terangkan keputusan snapshot tanpa mereka-reka jalan pintas angka.
• Mendakwa bahawa pembaca dan penulis tidak pernah menyekat satu sama lain → MVCC menghapuskan konflik kunci baca/tulis biasa, manakala penulis pada baris yang sama dan kunci eksplisit masih berkonflik → nyatakan jaminan yang lebih tepat.
• Menganggap autovacuum yang selesai telah mengalih keluar setiap tupel mati → horizon lama boleh menyebabkan versi tidak boleh dialih keluar → periksa tupel yang disimpan, horizon penghalang, log, dan kemajuan.
• Menganggap n_dead_tup sebagai bait kembung yang tepat → ia adalah anggaran kiraan baris → ukur heap, indeks, pertumbuhan, penggunaan semula, dan prestasi secara berasingan.
• Memanggil saiz fail yang tidak berubah sebagai kegagalan vakum → vakum biasa biasanya menyimpan ruang yang dikosongkan di dalam hubungan untuk digunakan semula → nilai penggunaan semula keadaan mantap sebelum menuntut pemadatan.
• Menjalankan VACUUM FULL serta-merta → penulisan semula memerlukan cakera tambahan dan kunci eksklusif → buang penghalang dan susul dengan vakum biasa sebelum membuat pelan pemadatan.
• Hanya melaraskan faktor skala global → jadual kerap dikemas kini dan kapasiti pekerja adalah berbeza → gunakan tetapan bagi setiap jadual yang disokong oleh kadar versi, masa penyiapan, dan bukti SLO.
• Menamatkan PID tertua tanpa pemeriksaan pemilikan → transaksinya akan diundur balik dan aliran klien mungkin gagal → sahkan tujuan, impak, dan laluan pemulihan terlebih dahulu.
• Menganggap pembekuan sebagai pengoptimuman storan → pembekuan melindungi ketepatan merentasi perbandingan XID membulat → pantau umur XID beku dan kerja anti-wraparound sebagai kawalan keselamatan.

Soalan Susulan

Soalan Susulan 1: Mengapa Jadual Boleh Kekal pada Saiz yang Sama Selepas VACUUM yang Berjaya?

Vakum biasa menandakan ruang tupel mati sebagai boleh digunakan semula di dalam hubungan yang sama. Ia boleh mengembalikan halaman yang benar-benar kosong pada bahagian akhir fizikal dalam keadaan yang terhad, tetapi tingkah laku rutin adalah penggunaan semula secara dalaman. Mengecilkan ruang bebas yang rawak memerlukan penulisan semula atau penyusunan semula hubungan. Oleh itu, saiz yang stabil ditambah dengan kependaman yang stabil dan penggunaan semula yang berterusan boleh dianggap sihat.

Soalan Susulan 2: Mengapa Autovacuum Berjalan tetapi Meninggalkan Banyak Versi Mati?

Ia mungkin masih kelihatan kepada snapshot lama, disimpan oleh transaksi yang disediakan atau horizon replikasi, atau dijana lebih cepat daripada keupayaan pekerja untuk membersihkannya. Pekerja juga mungkin tertangguh atau terganggu oleh beban kerja dan kunci. Gunakan log verbose, kemajuan, horizon tertua, ketepuan pekerja, dan kadar pengeluaran versi untuk membezakan kes-kes ini.

Soalan Susulan 3: Apakah Perbezaan Antara VACUUM dan ANALYZE?

Vakum menebus guna ruang yang boleh digunakan semula, menyelenggara indeks dan peta kebolehlihatan (visibility map), serta membekukan metadata transaksi lama. Analyze mengambil sampel data untuk mengemas kini statistik perancang (planner statistics). VACUUM (ANALYZE) melakukan kedua-duanya, tetapi satu operasi tidak menggantikan yang lain: statistik yang tepat tidak mengalih keluar tupel mati, dan ruang yang ditebus guna tidak menjamin model taburan data yang tepat.

Soalan Susulan 4: Bagaimana Kemas Kini HOT Mengurangkan Tekanan Vakum?

Apabila kemas kini tidak mengubah sebarang lajur yang diindeks dan pengganti muat pada halaman heap yang sama, PostgreSQL boleh mengelak daripada menambah entri indeks baharu. Versi perantaraan dalam rantaian HOT juga boleh dipangkas semasa akses halaman biasa. HOT tidak menghapuskan keperluan MVCC atau vakum, tetapi ia mengurangkan pusing ganti indeks dan kerja pembersihan. Pantau n_tup_hot_upd berbanding jumlah kemas kini dan uji sebarang perubahan fillfactor terhadap kos ruang dan cache.

Soalan Susulan 5: Bolehkah Anda Melumpuhkan Autovacuum dan Menjalankan Kerja Setiap Malam Sebagai Gantinya?

Tindakan itu berisiko untuk beban kerja yang berubah-ubah dan tidak melumpuhkan penyelenggaraan anti-wraparound. Peningkatan mendadak pada waktu siang boleh mencipta lebih banyak versi lapuk daripada apa yang boleh ditebus guna oleh tetingkap malam, manakala jadual statik masih memerlukan pembekuan pada akhirnya. Biarkan autovacuum didayakan, laraskannya daripada pusing ganti jadual yang diperhatikan, dan lengkapkannya dengan penyelenggaraan terkawal hanya apabila beban kerja mewajarkan pilihan tersebut.

Soalan Susulan 6: Adang Perlindungan (Guardrail) Mana yang Membantu Menangani Transaksi Melahu?

idle_in_transaction_session_timeout boleh menamatkan sesi yang menunggu terlalu lama di dalam transaksi terbuka. Gunakannya pada peranan yang serasi dan uji tingkah laku kolam sambungan, percubaan semula, dan kerja yang sah. Baiki juga sempadan aplikasi: mulakan transaksi sejurus sebelum kerja pangkalan data, komit atau undur balik dengan segera, dan jangan sekali-kali menunggu input pengguna atau perkhidmatan jauh semasa membiarkannya terbuka.