Sedikit perawatan dan perawatan dari penerapan PostgreSQL Anda akan sangat menjamin kinerja, menghindari penemuan yang tidak menyenangkan dan membangun prediktabilitas yang percaya diri. Berikut adalah 7 hal yang harus Anda perhatikan.
Penggembungan Tabel
PostgreSQL mengimplementasikan transaksi menggunakan teknik yang disebut MVCC.MVCC terlalu panjang dan melibatkan topik untuk dibahas secara mendetail, tetapi adatiga hal-hal yang harus tahu tentang itu:
- Menghapus baris hanya akan menandainya sebagai "tidak terlihat" untuk transaksi mendatang.
- Memperbarui baris akan membuat versi baru dari baris tersebut. Versi lama ditandai sebagai tidak terlihat oleh transaksi mendatang, dan versi baru ditandai sebagai terlihat.
- Secara berkala, seseorang perlu melihat semua transaksi yang sedang berjalan dan berkata:Oke, transaksi tertua di sini adalah #42, jadi setiap versi baris yang tidak terlihat di #42 dapat dihapus secara fisik tanpa merusak konsistensi data.
Begitulah cara kerja MVCC (pada dasarnya), dan implikasinya adalah pembaruan akan meningkatkan jejak penyimpanan basis data fisik Anda, dan menghapus tidak akan menguranginya. MVCC terdengar seperti cara malas untuk melakukan sesuatu, tetapi ini populer karena memberikan konsistensi dan kinerja.
Versi baris usang yang tidak diinginkan dalam tabel disebut mengembang (atau deadrows ). Proses yang dapat menghilangkan kembung disebut vakum . PostgreSQLmemiliki proses vakum yang dipicu secara otomatis dengan ambang yang dapat disetel yang disebut autovacuum, dan tentu saja perintah VACUUM.
Secara umum, bloat juga dapat memperlambat kueri karena peta visibilitas yang tidak akurat dan I/O disk yang terbuang.
Karena itu, Anda harus secara teratur:
- memantau jumlah bloat dalam database
- jalankan vakum secara teratur
- pantau apakah vakum dijalankan secara teratur untuk semua tabel
Ada beberapa kueri SQL untuk memberikan perkiraan mengasapi per tabel. Toolpgmetrics open source memberikan perkiraan bloat serta waktu berjalan terakhir dari vakum manual dan otomatis.
Index Kembung
Indeks juga bisa membengkak. Meskipun struktur internal indeks tidak jelas bagi pengguna SQL dan bervariasi menurut jenis indeks (BTree, hash, GIN, GIST, dll.), gagasan umumnya tetap bahwa ketika baris yang dirujuk oleh indeks dihapus, ruang yang ditempati oleh informasi terkait di dalam indeks hanya dihapus secara logis dan tidak dilepaskan kembali ke sistem file. Ruang yang dihapus secara logis dapat digunakan kembali oleh indeks nanti.
Ada dua cara untuk membuat Postgres mengecilkan ukuran fisik indeks:
- versi LENGKAP dari perintah VACUUM
- REINDEX
Index bloat harus dipantau, sehingga Anda setidaknya mengetahui jumlah ruang yang tersisa yang tidak digunakan. Dalam tabel dengan churn baris tinggi, tidak jarang menyiapkan tugas membangun kembali indeks reguler.
Indeks mengasapi juga dapat diperoleh dengan kueri yang sama seperti sebelumnya, dan juga melalui pgmetrics.
Transaksi Jangka Panjang
Transaksi harus dibuat sesingkat mungkin, terutama dalam sistem MVCC.
Bayangkan bahwa transaksi dimulai kemarin dan ada kekosongan setelah itu. Sekarang selama transaksi ini terbuka, vakum lebih lanjut tidak berguna, karena menurut definisi transaksi kita perlu melihat semua baris semua tabel seperti saat transaksi kita dimulai kemarin. Meskipun transaksi kita hanya-baca, hal ini tetap terjadi.
Akibatnya, transaksi yang berjalan lama membuat kembung. Mereka juga bergantung pada sumber daya sistem, menahan kunci yang tidak dilepaskan, dan meningkatkan kemungkinan kebuntuan.
Cara terbaik untuk mengawasi transaksi yang berjalan lama adalah dengan mengatur peringatan untuk jumlah transaksi yang telah berjalan lebih dari durasi tertentu. Anda bisa mendapatkannya dari tampilan statistikpg_stat_activity , seperti ini:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Keterlambatan Replikasi
Saat replikasi streaming digunakan untuk mereplikasi semua perubahan dari server PostgreSQL utama ke siaga panas (alias replika baca), biasanya ada sedikit penundaan antara saat pembaruan baris terjadi di server utama dan saat perubahan terlihat oleh aplikasi yang terhubung ke siaga .
Namun, ada beberapa kasus di mana kelambatan ini dapat meningkat:
- sistem siaga tidak dapat menerima dan menerapkan perubahan dari sistem utama dengan cukup cepat untuk mengikutinya, biasanya karena beban tinggi atau kekurangan penyediaan
- jaringan atau disk yang rusak
- konflik kueri
Siaga dengan jeda replikasi yang tinggi atau bahkan lebih buruk lagi dapat mengakibatkan pertanyaan pada siaga yang mengembalikan data basi, dan siaga yang tidak layak untuk failover.
Jika Anda memiliki penyiapan replikasi streaming, pemantauan kelambatan replikasi antara setiap pasangan siaga primer sangat penting, dan Anda perlu menyetel peringatan untuk memeriksa apakah kelambatan replikasi melebihi satu menit, atau ambang batas apa pun yang masuk akal untuk penyiapan Anda.
Postingan ini berisi lebih banyak tentang cara mengukur dan memantau jeda replikasi dari ujung primer dan siaga.
Slot Replikasi Tidak Aktif
Penggunaan slot replikasi, yang diperkenalkan di PostgreSQL 9.4, membuat replikasi streaming lebih kuat dan efisien. Pada dasarnya, standby melaporkan kemajuan replikasinya ke primer, yang menyimpan informasi ini di “slot replikasi”.
Karena itu, primer sekarang tahu setiap saat seberapa jauh di belakang standbyis. Hal ini memungkinkan primer untuk mempertahankan simpanan file WAL yang cukup (yang diperlukan untuk melanjutkan replikasi) saat siaga offline. Jadi ketika standby kembali, bahkan setelah waktu yang lama, primer masih dapat menjamin bahwa replikasi dapat dilanjutkan.
Sebelum slot replikasi, yang utama dapat membersihkan file WAL lama, karena tidak tahu apakah standby membutuhkannya atau tidak. Jika file WAL yang dibutuhkan oleh siaga dihapus, tidak ada cara untuk melanjutkan replikasi; itu harus disetup lagi dari awal.
Namun, perilaku utama dalam menyimpan file WAL tanpa batas waktu menyebabkan masalah lain. Jika standby dihentikan dan slot replikasi terkait tidak dihapus, file WAL akan disimpan selamanya. File WAL yang disimpan karena alasan ini tidak tunduk pada batasan yang ditetapkan oleh max_wal_size dan opsi konfigurasi lainnya.
Situasi ini akan tetap ada hingga file WAL menghabiskan seluruh ruang disk, bahkan tanpa peringatan di file log PostgreSQL.
Tak perlu dikatakan, slot replikasi yang tidak aktif harus ditangani saat terdeteksi. Temukan slot replikasi tidak aktif Anda menggunakan:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analisis Status
ANALYZE dijalankan pada tabel untuk mengumpulkan dan memperbarui informasi statistik tentang isi tabel. Informasi ini digunakan oleh perencana kueri untuk menyiapkan rencana eksekusi untuk setiap kueri SQL. Statistik terkini tentang isi tabel menghasilkan rencana eksekusi yang lebih baik, yang pada gilirannya menghasilkan kueri yang lebih cepat.
Daemon autovacuum biasanya menjalankan ANALYZE setelah VACUUM. Namun ini mungkin tidak cukup sering untuk ANALISIS. Jika distribusi data dalam tabel sering berubah, Anda harus menjalankan ANALYZE lebih sering.
Biasanya ANALYZE berperilaku cukup baik - hanya perlu membaca kunci, tidak menggunakan terlalu banyak sumber daya apa pun dan selesai dalam waktu yang wajar. Lebih aman untuk menjalankannya lebih sering daripada tidak.
Mengawasi tabel yang sudah lama tidak DIANALISIS adalah ide yang bagus. Cari tahu kapan terakhir kali tabel Anda (otomatis) dianalisis dengan kueri:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Penggunaan Sumber Daya
Memantau beban CPU, memori, dan penggunaan disk sangat membantu dalam memastikan Anda memiliki kapasitas yang cukup untuk memenuhi kebutuhan aplikasi yang berkembang menggunakan database Anda.
PostgreSQL memunculkan satu proses untuk menangani satu koneksi. Meskipun ini mungkin bukan arsitektur yang paling terukur saat ini, arsitektur ini berkontribusi banyak di bidang stabilitas. Itu juga membuat rata-rata beban OS lebih bermakna. Seperti biasanya PostgreSQLboxes hanya menjalankan PostgreSQL, rata-rata beban katakanlah 3 biasanya berarti ada 3koneksi yang menunggu inti CPU tersedia untuk dijadwalkan. Memantau rata-rata beban maksimum Anda selama hari atau minggu tertentu dapat memberikan perkiraan seberapa over- atau under-provisioned kotak Anda di bagian depan CPU.
Memori dan ruang disk kosong tentu saja merupakan hal standar untuk dipantau. Lebih banyak koneksi dan transaksi yang berjalan lebih lama menempatkan tuntutan yang lebih tinggi pada memori. Dan saat memantau ruang kosong disk, ingatlah untuk melacaknya per tablespace.
