Metrik apa dari penerapan PostgreSQL Anda yang harus Anda pantau? Serangkaian entri blog ini bertujuan untuk menyediakan serangkaian tindakan pemantauan penting awal yang harus Anda terapkan untuk memastikan kesehatan dan stabilitas server Postgres Anda.
Ini adalah bagian kedua dari seri blog, dan mencakup parameter tingkat basis data. Yang pertama mencakup parameter tingkat klaster.
Bagian 2:Tingkat Basis Data
Di bagian ini, kita melihat metrik dan informasi yang harus dipantau untuk setiap database penting yang Anda gunakan.
Sebagian besar kueri SQL yang tercantum di bawah ini harus dijalankan saat terhubung ke database yang bersangkutan.
1. Klien Terhubung
Klien yang terhubung menggunakan OS dan sumber daya sistem. Postgres memiliki arsitektur proses-per-klien, dan terlalu banyak klien dapat memperlambat waktu respons kueri untuk semua orang. Pertimbangkan untuk menggunakan PgBouncer orpgpool untuk mengurangi jumlah koneksi yang harus dilayani oleh server Postgres.
Awasi perubahan baseline setelah pembaruan aplikasi dan lonjakan koneksi karena peningkatan lalu lintas.
Tindakan:Pantau jumlah maksimum klien yang terhubung setiap hari/minggu, selidiki perubahan tren.
Cara:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Ukuran
Ukuran disk aktual yang digunakan oleh database harus dipantau. Dalam kebanyakan kasus, ukuran database terus bertambah, sehingga tingkat pertumbuhannya yang lebih menarik. Sekali lagi, waspadalah terhadap peningkatan tingkat pertumbuhan setelah rilis aplikasi baru.
Tindakan:Pantau pertumbuhan ukuran basis data setiap minggu/bulan, selidiki tren, penyediaan ulang.
Cara:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Tabel Mengasapi di Semua Tabel
Karena arsitektur MVCC Postgres, versi baris yang lebih lama terletak di sekitar file data fisik untuk setiap tabel, dan disebut mengembang . Operasi untuk menghapus versi baris usang disebut vakum . Postgres menjalankan proses latar belakang yang disebut autovacuum , yang mengambil tabel kandidat (berdasarkan parameter yang dapat dikonfigurasi) dan mengosongkannya untuk Anda.
Bloat memperlambat operasi tabel dan membuang-buang ruang disk, dan dapat kabur bahkan dengan autovacuum. Pemantauan bloat, sebagai jumlah mutlak byte serta persentase (data mati terhadap data total), diperlukan. Ini dapat dilakukan pada tingkat basis data sebagai total di semua tabel, dengan kemungkinan untuk menelusuri “tabel yang paling membengkak”.
Tindakan:Terus pantau total bloat sebagai byte dan persentase, beri tahu jika nilainya melebihi ambang batas yang ditetapkan.
Cara:
Gunakan check_postgres orpgmetrics untuk mendapatkan perkiraan mengasapi. Lihat wiki untuk info lebih lanjut.
4. Penggembungan Indeks di Semua Indeks
Indeks yang membengkak dapat memperlambat penyisipan dan mengurangi kinerja pencarian. Pantau peningkatan indeks baik sebagai nilai absolut (jumlah byte) dan sebagai persentase. Indeks harus dibuat ulang jika terlalu membengkak.
Tindakan:Terus pantau total bloat sebagai byte dan persentase, beri tahu jika nilainya melebihi ambang batas yang ditetapkan.
Cara:
Gunakan check_postgres orpgmetrics untuk mendapatkan perkiraan mengasapi. Lihat wiki untuk info lebih lanjut.
5. Transaksi Jangka Panjang
Transaksi yang dibuka terlalu lama bukanlah kabar baik bagi PostgreSQL. Transaksi yang berjalan lama dapat menyebabkan penyimpanan file WAL, dapat mengunci dan mencegah vakum. Aplikasi harus dirancang untuk menjaga durasi transaksi serendah mungkin.
Backend yang menjalankan transaksi yang berjalan lama dapat dihentikan dengan pg_cancel_backend() dan pg_terminate_backend() fungsi.
Tindakan:Pantau terus jumlah transaksi yang telah berjalan selama lebih dari durasi waktu yang ditentukan, beri tahu jika nilainya melebihi ambang batas yang ditetapkan.
Cara:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Kebuntuan
Di PostgreSQL, backend menempatkan kunci pada baris dan tabel secara implisit saat menjalankan kueri yang memodifikasi baris. Kueri juga dapat menempatkan kunci eksplisit (seperti SELECT .. FOR UPDATE ). Sama seperti dalam pemrograman multi-utas, dua transaksi yang menempatkan kunci, baik secara implisit maupun eksplisit, dalam urutan yang berlawanan dapat mengakibatkan kebuntuan.
PostgreSQL akan mendeteksi kebuntuan dan akan mengembalikan salah satu transaksi yang terlibat (Semua kunci yang dipegang oleh suatu transaksi dilepaskan ketika dilakukan atau dibatalkan). Detail akan dicatat di tujuan pencatatan PostgreSQL.
Aplikasi harus dirancang untuk menghindari kemungkinan kebuntuan. Mereka juga dapat memilih untuk mencoba kembali transaksi jika terjadi kebuntuan.
Tindakan:Pantau jumlah deadlock setiap hari/minggu, rancang ulang aplikasi untuk mengurangi jumlah, selidiki perubahan.
Cara:
Terjadinya kebuntuan, bersama dengan informasi tambahan, dicatat dalam file log PostgreSQL. Gunakan pgmetrics, pgbadger, atau alat pemrosesan log khusus PostgreSQL lainnya untuk mengekstrak informasi ini.
7. Vakum Terlama
Menyedot debu meja secara teratur, baik dengan vakum otomatis, atau dengan pekerjaan terjadwal, atau secara manual adalah suatu keharusan untuk menjaga operasi meja tetap cepat. Penyedot debu dapat gagal karena berbagai alasan, termasuk transaksi yang berjalan lama, slot replikasi yang tidak aktif, dll.
Karena penyedotan debu meja secara teratur cukup penting di dunia Postgres, yang terbaik adalah memeriksa secara teratur apakah semua meja telah dikosongkan setidaknya sekali dalam interval yang ditentukan.
Dan meskipun mereka cenderung tidak terlihat dan tidak terpikirkan, tabel katalog sistem juga harus dikosongkan.
Tindakan:Terus periksa apakah ada meja yang belum dikosongkan dalam jumlah jam/hari yang ditetapkan terakhir, waspada jika ada.
Cara:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Analisis Terlama
Untuk menjalankan kueri SELECT Anda, perencana kueri menyiapkanrencana eksekusi yang menjelaskan indeks dan tabel mana yang harus dibaca, dan bagaimana caranya. Untuk menghasilkan rencana eksekusi yang efisien, perencana perlu memiliki statistik tentang distribusi nilai, ukuran tupel, dan sebagainya. Informasi statistik seperti itu tentang data dalam tabel dikumpulkan dan dipelihara oleh analisis operasi. Tabel dengan statistik terkini menghasilkan kueri yang lebih cepat dan I/O yang lebih rendah.
Proses autovacuum yang disebutkan di atas biasanya juga menjalankan ANALYZE di atas meja itu vakum untuk menjaga informasi ini diperbarui. Namun, ini saja mungkin tidak memberikan cakupan analisis yang memadai untuk tabel Anda. Anda akan ingin melengkapi dengan menjalankan ANALYZE sebagai tugas terjadwal atau setelah mutasi tabel yang signifikan.
Demi kinerja kueri, yang terbaik adalah terus memeriksa apakah semua tabel telah dianalisis setidaknya sekali dalam interval yang ditetapkan.
Tindakan:Terus periksa apakah ada tabel yang belum dianalisis dalam jumlah jam/hari yang ditetapkan terakhir, waspada jika ada.
Cara:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Mengumpulkan Metrik Ini
Bagian di atas menyediakan pernyataan SQL untuk mengekstrak metrik yang diperlukan dari server Postgres yang sedang berjalan. Jika Anda lebih suka tidak menulis skrip sendiri, lihat pgmetrics alat sumber terbuka. Itu dapat mengumpulkan metrik di atas, dan banyak lagi, dan melaporkannya dalam format teks dan JSON.
Anda dapat langsung mengirim laporan pgmetrics ke penawaran komersial kami, pgDash, yang menyimpan dan memproses laporan ini untuk menampilkan grafik dan melakukan peringatan.
Selanjutnya
Bagian selanjutnya dalam seri ini akan mencakup metrik tingkat tabel, tingkat indeks, dan tingkat sistem. Tetap disini!
