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 ketiga dan terakhir dari seri blog, dan mencakup metrik tingkat tabel, indeks, dan sistem. Yang pertama mencakup metrik tingkat klaster dan yang kedua mencakup metrik tingkat basis data.
Tingkat Tabel
Biasanya, data dalam database mengikuti aturan 80-20. 20% tabel berisi sebagian besar data dan paling banyak diakses atau dimutasi. Menyiapkan pemantauan ekstra hanya untuk tabel ini dapat memberikan wawasan yang penting namun bervolume rendah.
Berikut adalah beberapa metrik tingkat tabel yang layak untuk dilihat:
1. Ukuran Tabel
Ukuran disk aktual yang digunakan oleh tabel harus dipantau. Dalam kebanyakan kasus, tabel terus bertambah, jadi tingkat pertumbuhannya yang lebih menarik.
Sering terjadi bahwa tingkat pertumbuhan berubah setelah peluncuran versi baru aplikasi, atau perubahan dasar dalam pola lalu lintas/beban/masukan dari aplikasi itu sendiri. Perubahan tersebut harus diselidiki, setidaknya untuk memverifikasi bahwa tarif baru dapat dipertahankan oleh perangkat keras yang disediakan.
Tindakan:Pantau peningkatan ukuran tabel setiap minggu/bulan, selidiki perubahan mendadak.
Cara:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Tabel Mengasapi
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.
Metrik ini dapat dipantau baik di tingkat tabel individual, atau sebagai gabungan di seluruh tabel yang dipilih, atau di tingkat database.
Tindakan:Terus pantau tabel bloat sebagai byte dan persentase, beri tahu jika nilai melebihi ambang batas yang ditetapkan, VACUUM seperlunya.
Cara:
Gunakan check_postgres orpgmetrics untuk mendapatkan perkiraan mengasapi. Lihat wiki untuk info lebih lanjut.
3. Pemindaian Berurutan
Ketika kueri dieksekusi yang tidak menggunakan indeks yang tersedia secara optimal, atau jika informasi statistik yang terkait dengan tabel terlalu usang, Postgres mungkin harus melalui setiap baris tabel. Ini disebut pemindaian berurutan , dan sangat tidak diinginkan dalam kasus umum. Apa yang lebih baik untuk dimiliki adalah pemindaian indeks , di mana baris tabel diakses secara tidak langsung melalui pencarian indeks.
PostgreSQL dapat memberi tahu Anda berapa kali tabel dipindai secara berurutan, dan berapa kali indeks digunakan. Anda dapat menggunakan ini untuk memantau jumlah pemindaian berurutan (jika Anda ingin menghindarinya sama sekali) atau sebagai persentase dari total pemindaian.
Tindakan:Pantau terus seq. jumlah atau persentase pemindaian, peringatan jika nilai melebihi ambang batas yang ditetapkan.
Cara:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Tingkat Indeks
1. Ukuran Indeks
Indeks dapat mengambil ruang disk yang cukup besar. Setiap indeks tabel itu sendiri berpotensi memiliki jejak disk sebanyak tabel itu sendiri. Berguna untuk mengawasi ukuran total indeks dalam database, atau indeks tabel penting, terutama dalam penerapan di mana indeks dapat dibuat melalui proses otomatis.
Indeks besar yang tidak masuk akal bisa jadi karena mengasapi, atau hanya indeks yang dirancang dengan buruk. Dalam kedua kasus tersebut, memperbaiki penyebabnya (baik dengan membangun kembali indeks atau dengan memfaktorkan ulang kueri/indeks) dapat menghasilkan waktu kueri yang lebih cepat, jadi ada baiknya menyelidiki indeks besar.
Tindakan:Pantau ukuran total indeks yang menarik selama setiap minggu/bulan, selidiki jika terlalu besar.
Cara:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Indeks Kembung
Indeks juga bisa membengkak. Ada terlalu banyak faktor, termasuk tableworkload, tipe indeks, versi Postgres, dan lainnya, yang menentukan seberapa besar anindex menjadi. 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:Pantau terus indeks bloat sebagai byte dan persentase, beri tahu jika nilai melebihi ambang batas yang ditetapkan.
Cara:
Gunakan check_postgres orpgmetrics untuk mendapatkan perkiraan mengasapi. Lihat wiki untuk info lebih lanjut.
3. Rasio Cache Hit
PostgreSQL menyimpan cache wilayah indeks (dan juga tabel) yang sering diakses. Jika Anda telah menyetel kueri Anda untuk tidak menyentuh tabel kecuali untuk mengambil baris, langkah selanjutnya adalah memastikan penyimpanan cache maksimum untuk indeks penting yang benar-benar mempercepat kueri Anda.
Penggunaan cache suatu indeks dapat diukur dengan rasio hit cache, yang merupakan persentase blok indeks yang dibaca dari cache ke jumlah total blok yang dibaca.
Tindakan:Pantau terus persentase rasio hit cache, beri tahu jika nilai turun di bawah ambang batas yang ditetapkan. Selidiki nilai rendah untuk indeks penting.
Cara:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Tingkat Sistem
Terlepas dari metrik PostgreSQL, penting untuk melacak beberapa metrik mesin atau VM tempat Anda menjalankan Postgres. Anda dapat menggunakan solusi pemantauan populer untuk ini, atau bahkan mengambil dan melacaknya sendiri.
1. Memori yang Digunakan
Sistem Linux modern memiliki akuntansi memori yang kompleks. Sebaiknya pantau “memori bekas”, yaitu memori yang tersisa setelah memperhitungkan memori yang ditandai sebagaibebas , sebagai penyangga , sebagai cache , dan sebagai lempengan . Buffer dan cache akan menyerah di bawah tekanan, dan begitu juga sebagian besar (biasanya lebih dari 95%) slab.
Memori yang digunakan, bagaimanapun, harus diukur selama periode yang sesuai. Jika Anda memiliki pekerjaan batch, laporan, ETL, dll. yang dijalankan pada akhir pekan, maka periodenya adalah satu minggu. Metrik sebenarnya yang perlu Anda pantau adalah memori maksimum yang digunakan selama periode ini.
Biasanya, saat ukuran database Anda bertambah, nilai ini cenderung naik. Anda harus memastikan penggunaan memori maksimum berada dalam batas yang nyaman dari memori yang tersedia, seperti misalnya 60-80%. Mengabaikan hal ini akan menyebabkan beban kerja analytics/OLAP Anda gagal karena kekurangan memori.
Tindakan:Pantau memori maksimum yang digunakan selama seminggu/dua malam, beri tahu jika melebihi ambang batas yang ditetapkan, reprovision.
Cara :
Memori yang digunakan diberikan oleh MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , di mana Mem* kolom berasal dari /proc/meminfo . Untuk informasi lebih lanjut, lihat artikel RedHat ini.
2. Muat Rata-Rata
Nilai rata-rata beban sederhana masih merupakan cara termudah dan tercepat untuk memperkirakan beban di server. Hal ini terutama berlaku untuk server Postgres, karena setiap backend adalah proses OS yang terpisah, dan memiliki lebih banyak dari mereka dalam status yang dapat dijalankan akan meningkatkan nilai rata-rata beban.
Untuk server Postgres tertentu, rata-rata pemuatan harus tetap dalam kisaran yang wajar selama siklus bisnis (seperti satu minggu, termasuk pekerjaan batch yang dijalankan).
Tindakan:Pantau rata-rata pemuatan maksimum setiap hari/minggu, selidiki tren yang meningkat.
Cara :
Rata-rata pemuatan 1 menit, 5 menit, dan 15 menit adalah 3 bidang pertama dari baris pertama dalam file /proc/loadavg .
3. Ruang Disk Kosong
Item terakhir dalam daftar kami adalah item yang paling jelas untuk dipantau:jumlah ruang disk kosong di setiap sistem file yang digunakan oleh server PostgreSQL Anda, termasuk tablespace, direktori file WAL, direktori cadangan, dan file log server. Jika terlalu banyak (100 juta) file dibuat dalam satu sistem file, pastikan bahwa jumlah inode gratis juga dipantau. Kurangnya inode juga dilaporkan sebagai ruang disk yang rendah.
Tindakan:Pantau terus ruang disk kosong dan penggunaan inode pada semua sistem file yang relevan, beri tahu jika nilainya berada di bawah ambang batas yang ditetapkan.
Cara :
Ruang disk kosong dalam sistem file tidak dapat diambil secara langsung dengan membaca file apa pun di /proc . Anda dapat menggunakan stat -f /path/to/mount atau bahkan df untuk mengetahui ruang disk yang digunakan, kosong, dan dicadangkan untuk sistem file tertentu yang dipasang.
Referensi Cepat
Berikut adalah daftar lengkap dari semua metrik yang telah kita diskusikan sejauh ini dalam seri ini. Ingatlah bahwa ini hanyalah kumpulan metrik minimal, paling penting, yang harus Anda pantau untuk mendeteksi ketika ada hal yang tidak beres dengan penerapan PostgreSQL Anda.
Tingkat Klaster
- Rentang ID Transaksi
- Jumlah Backend
- Slot Replikasi Tidak Aktif
- Backend Menunggu di Kunci
- Backend Idling dalam Transaksi
- Keterlambatan Replikasi untuk Koneksi Aktif
- Keterlambatan Replikasi untuk Slot Replikasi
- Jumlah Berkas WAL
- Jumlah file WAL yang siap diarsipkan
Tingkat Basis Data
- Klien Terhubung
- Ukuran
- Meja Mengamuk di Semua Tabel
- Penggembungan Indeks di Semua Indeks
- Transaksi Jangka Panjang
- Kebuntuan
- Vacuum Tertua
- Analisis Terlama
Tingkat Tabel
- Ukuran Tabel
- Penggembungan Tabel
- Pemindaian Berurutan
Tingkat Indeks
- Ukuran Indeks
- Indeks Kembung
- Rasio Hit Cache
Tingkat Sistem
- Memori yang Digunakan
- Muat Rata-rata
- Ruang Disk Kosong
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.
