Hal-Hal Utama yang Harus Dipantau di PostgreSQL - Menganalisis Beban Kerja Anda

Hal Utama yang Harus Dipantau di PostgreSQL - Menganalisis Beban Kerja Anda

Dalam sistem komputer, pemantauan adalah proses mengumpulkan metrik, menganalisis, menghitung statistik dan menghasilkan ringkasan dan grafik mengenai kinerja atau kapasitas sistem, serta menghasilkan peringatan jika terjadi masalah atau kegagalan tak terduga yang memerlukan perhatian atau tindakan segera. Oleh karena itu, pemantauan memiliki dua kegunaan:satu untuk analisis dan presentasi data historis yang membantu kami mengidentifikasi tren jangka menengah dan panjang dalam sistem kami dan dengan demikian membantu kami merencanakan peningkatan, dan yang kedua untuk tindakan segera jika terjadi masalah.

Pemantauan membantu kami mengidentifikasi masalah dan bereaksi terhadap masalah tersebut terkait berbagai bidang seperti:

• Infrastruktur/Perangkat Keras (fisik atau virtual)
• Jaringan
• Penyimpanan
• Perangkat Lunak Sistem
• Perangkat Lunak Aplikasi
• Keamanan

Pemantauan adalah bagian utama dari pekerjaan DBA. PostgreSQL, secara tradisional, telah dikenal sebagai "pemeliharaan rendah" berkat desainnya yang canggih dan ini berarti bahwa sistem dapat hidup dengan kehadiran yang rendah jika dibandingkan dengan alternatif lain. Namun, untuk penginstalan serius di mana ketersediaan dan kinerja tinggi merupakan kunci penting, sistem database harus dipantau secara teratur.

Peran DBA PostgreSQL dapat meningkat ke tingkat yang lebih tinggi dalam hierarki perusahaan selain sangat teknis:selain pemantauan dasar dan analisis kinerja,  harus dapat menemukan perubahan dalam pola penggunaan, mengidentifikasi kemungkinan penyebabnya, memverifikasi asumsi, dan akhirnya menerjemahkan temuan dalam istilah bisnis. Sebagai contoh, DBA harus dapat mengidentifikasi beberapa perubahan mendadak dalam aktivitas tertentu yang mungkin terkait dengan kemungkinan ancaman keamanan. Jadi peran DBA PostgreSQL adalah peran kunci dalam perusahaan, dan harus bekerja sama dengan kepala departemen lain untuk mengidentifikasi dan memecahkan masalah yang muncul. Pemantauan adalah bagian besar dari tanggung jawab ini.

PostgreSQL menyediakan banyak alat luar biasa untuk membantu kami mengumpulkan dan menganalisis data. Selain itu, karena ekstensibilitasnya, ia menyediakan sarana untuk mengembangkan modul baru ke dalam sistem inti.

PostgreSQL sangat bergantung pada sistem (perangkat keras dan perangkat lunak) yang dijalankannya. Kami tidak dapat mengharapkan server PostgreSQL untuk bekerja dengan baik jika ada masalah di salah satu komponen vital di seluruh sistem. Jadi peran DBA PostgreSQL tumpang tindih dengan peran sysadmin. Di bawah, saat kami memeriksa apa yang harus diperhatikan dalam pemantauan PostgreSQL, kami akan menemukan variabel dan metrik yang bergantung pada sistem serta angka spesifik PostgreSQL.

Pemantauan tidak datang secara gratis. Investasi yang baik harus dilakukan oleh perusahaan/organisasi dengan komitmen untuk mengelola dan memelihara seluruh proses pemantauan. Itu juga menambahkan sedikit beban pada server PostgreSQL juga. Ini sedikit mengkhawatirkan jika semuanya dikonfigurasi dengan benar, tetapi kita harus ingat bahwa ini bisa menjadi cara lain untuk menyalahgunakan sistem.

Dasar-dasar Pemantauan Sistem

Variabel penting dalam pemantauan Sistem adalah:

• Penggunaan CPU
• Penggunaan Jaringan
• Ruang Disk / Pemanfaatan Disk
• Penggunaan RAM
• IOPS Disk
• Tukar penggunaan ruang
• Kesalahan Jaringan

Berikut adalah contoh ClusterControl yang menampilkan grafik untuk beberapa variabel PostgreSQL kritis yang berasal dari pg_stat_database dan pg_stat_bgwriter (yang akan kita bahas dalam paragraf berikut) saat menjalankan pgbench -c 64 -t 1000 pgbench dua kali:

Kami melihat bahwa kami memiliki puncak pada pembacaan blok pada proses pertama, tetapi kami mendekati nol selama proses kedua karena semua blok ditemukan di shared_buffers.

Variabel lain yang menarik adalah aktivitas paging, interupsi, sakelar konteks, dan lainnya. Ada banyak alat untuk digunakan di Linux/BSD dan sistem unix atau mirip unix. Beberapa di antaranya adalah:

• ps:untuk daftar proses yang sedang berjalan

• top/htop/systat:untuk pemantauan penggunaan sistem (CPU / memori)

• vmstat:untuk pemantauan aktivitas sistem umum (termasuk memori virtual)

• iostat/iotop/top -mio:untuk pemantauan IO

• ntop:untuk pemantauan jaringan

Berikut adalah contoh vmstat pada kotak FreeBSD selama kueri yang memerlukan beberapa pembacaan disk dan juga beberapa perhitungan:

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

Mengulangi kueri, kami tidak akan melihat adanya ledakan baru dalam aktivitas disk karena blok disk tersebut sudah ada di cache OS. Meskipun, DBA PostgreSQL harus dapat sepenuhnya memahami apa yang terjadi di infrastruktur dasar tempat basis data berjalan, pemantauan sistem yang lebih kompleks biasanya merupakan tugas sysadmin, karena ini adalah topik besar tersendiri.

Di linux, pintasan yang sangat berguna untuk atas utilitas menekan "C", yang matikan menunjukkan baris perintah dari proses. PostgreSQL secara default menulis ulang baris perintah backend dengan aktivitas SQL aktual yang mereka jalankan saat ini dan juga pengguna.

Dasar-dasar Pemantauan PostgreSQL

Variabel penting dalam pemantauan PostgreSQL adalah:

• Kinerja cache buffer (hasil cache vs pembacaan disk)
• Jumlah komit
• Jumlah koneksi
• Jumlah sesi
• Pos pemeriksaan dan statistik bgwriter
• Vacuum
• Kunci
• Replikasi
• Dan yang tak kalah pentingnya, pertanyaan

Umumnya ada dua cara dalam pengaturan pemantauan untuk melakukan pengumpulan data:

• Untuk memperoleh data melalui Log
• Untuk memperoleh data dengan menanyakan sistem PostgreSQL

Akuisisi data berbasis file log bergantung pada log PostgreSQL (yang dikonfigurasi dengan benar). Kita dapat menggunakan jenis pencatatan ini untuk pemrosesan data “off-line”. Pemantauan berbasis file log paling cocok ketika overhead minimal ke server PostgreSQL diperlukan dan ketika kita tidak peduli dengan data langsung atau tentang mendapatkan peringatan langsung (walaupun pemantauan langsung menggunakan data file log dapat dimungkinkan dengan misalnya mengarahkan log postgresql ke syslog dan kemudian streaming syslog ke server lain yang didedikasikan untuk pemrosesan log).

Pengumpul Statistik PostgreSQL

PostgreSQL menyediakan serangkaian tampilan dan fungsi yang kaya yang tersedia melalui subsistem Kolektor Statistik. Sekali lagi data tersebut dibagi dalam dua kategori:

• Informasi dinamis tentang apa yang sedang dilakukan sistem saat ini.
• Statistik terakumulasi sejak subsistem pengumpul statistik terakhir kali disetel ulang.

Tampilan statistik dinamis memberikan info tentang aktivitas saat ini per proses (pg_stat_activity), status replikasi fisik (pg_stat_replication), status siaga fisik (pg_stat_wal_receiver) atau logis (pg_stat_subscription), ssl (pg_stat_ssl) dan vakum (pg_stat_progress_vacuum).

Tampilan statistik yang dikumpulkan memberikan info tentang proses latar belakang penting seperti pengarsip wal, bgwriter, dan objek database:tabel pengguna atau sistem, indeks, urutan dan fungsi serta database itu sendiri.

Seharusnya cukup jelas sekarang bahwa ada beberapa cara untuk mengkategorikan data yang terkait dengan pemantauan:

• Menurut sumber:
  • Alat sistem (ps, atas, iotop, dll)
  • File Log PgSQL
  • Basis Data
    • Dinamis
    • Dikumpulkan
• Dengan operasi database tertentu:
  • Tembolok penyangga
  • Berkomitmen
  • Permintaan
  • Sesi
  • Pos pemeriksaan
  • Dll

Setelah membaca artikel ini dan bereksperimen dengan pengertian, konsep, dan istilah yang disajikan, Anda seharusnya dapat membuat matriks 2D dengan semua kemungkinan kombinasi. Sebagai contoh, aktivitas PostgreSQL tertentu (perintah SQL) dapat ditemukan menggunakan:ps atau top (utilitas sistem), file log PostgreSQL, pg_stat_activity (tampilan dinamis), tetapi juga menggunakan pg_stat_statements, ekstensi yang ditemukan di contrib (tampilan statistik yang dikumpulkan) . Demikian juga, informasi tentang kunci dapat ditemukan di file log PostgreSQL, pg_locks dan pg_stat_activity (disajikan tepat di bawah) menggunakan wait_event dan wait_event_type . Karena itu, sulit untuk mencakup area pemantauan yang luas secara linier uni-dimensi, dan penulis berisiko menimbulkan kebingungan bagi pembaca karena hal ini. Untuk menghindari hal ini, kami akan membahas pemantauan secara kasar dengan mengikuti jalannya dokumentasi resmi, dan menambahkan informasi terkait sesuai kebutuhan.

Tampilan Statistik Dinamis

Menggunakan pg_stat_activity kita dapat melihat apa aktivitas saat ini oleh berbagai proses backend. Misalnya jika kita menjalankan kueri berikut pada bagian tabel dengan sekitar 3 juta baris:

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

Dan mari kita jalankan kueri berikut, yang membutuhkan beberapa detik untuk diselesaikan:

testdb=# select avg(age(date_added)) FROM parts;

Dengan membuka terminal baru dan menjalankan kueri berikut, sementara yang sebelumnya masih berjalan, kita mendapatkan:

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

Tampilan pg_stat_activity memberi kami info tentang proses backend, pengguna, klien, transaksi, kueri, status, serta info lengkap tentang status menunggu kueri.

Tapi kenapa 3 baris? Dalam versi>=9.6, jika kueri dapat dijalankan secara paralel, atau sebagian kueri dapat dijalankan secara paralel, dan pengoptimal menganggap bahwa eksekusi paralel adalah strategi tercepat, maka ia akan membuat Gather atau Kumpulkan Gabung node, lalu meminta paling banyak max_parallel_workers_per_gather proses pekerja latar belakang, yang secara default adalah 2, maka 3 baris yang kita lihat pada output di atas. Kami dapat membedakan proses backend klien dari pekerja latar belakang dengan menggunakan backend_type kolom. Agar tampilan pg_stat_activity diaktifkan, Anda harus memastikan bahwa parameter konfigurasi sistem track_activities aktif. pg_stat_activity menyediakan informasi yang kaya untuk menentukan kueri yang diblokir dengan menggunakan kolom wait_event_type dan wait_event.

Cara yang lebih halus untuk memantau pernyataan adalah melalui pg_stat_statements ekstensi contrib, yang disebutkan sebelumnya. Pada sistem Linux terbaru (Ubuntu 17.10, PostgreSQL 9.6), ini dapat diinstal dengan cukup mudah:

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Mari buat tabel dengan 100000 baris, lalu reset pg_stat_statements, restart server PostgreSQL, lakukan seleksi pada tabel ini pada sistem (masih dingin), dan kemudian lihat isi pg_stat_statements untuk memilih:

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Sekarang mari kita lakukan pemilihan * sekali lagi dan kemudian lihat lagi isi pg_stat_statements untuk kueri ini:

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Jadi, kedua kalinya pernyataan pilih menemukan semua blok yang diperlukan dalam buffer bersama PostgreSQL, dan pg_stat_statements melaporkannya melalui shared_blks_hit . pg_stat_statements memberikan info tentang jumlah panggilan pernyataan, total_time, min_time, max_time dan mean_time, yang dapat sangat membantu ketika mencoba menganalisis beban kerja sistem Anda. Permintaan lambat yang dijalankan sangat sering harus memerlukan perhatian segera. Demikian pula, hit rate yang rendah secara konsisten dapat menandakan kebutuhan untuk meninjau shared_buffers pengaturan.

pg_stat_replication memberikan info tentang status replikasi saat ini untuk setiap wal_sender. Misalkan kita telah menyiapkan topologi replikasi sederhana dengan primer dan satu siaga panas, maka kita dapat meminta pg_stat_replication pada primer (melakukan hal yang sama pada siaga tidak akan memberikan hasil kecuali kita telah menyiapkan replikasi berjenjang dan siaga khusus ini berfungsi sebagai upstream ke siaga hilir lainnya) untuk melihat status replikasi saat ini:

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

4 kolom sent_lsn , tulis_lsn , flush_lsn , replay_lsn beri tahu kami posisi WAL yang tepat pada setiap tahap proses replikasi di siaga jarak jauh. Kemudian kami membuat lalu lintas yang padat di primer dengan perintah seperti:

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

Dan lihat pg_stat_replication lagi:

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Sekarang kita melihat bahwa kita memiliki penundaan antara primer dan siaga yang digambarkan dalam sent_lsn , tulis_lsn , flush_lsn , replay_lsn nilai-nilai. Sejak PgSQL 10.0, pg_stat_replication juga menunjukkan jeda antara WAL yang baru-baru ini dihapus secara lokal dan waktu yang diperlukan untuk menulis, menghapus, dan memutar ulang dari jarak jauh. Melihat nol di 3 kolom itu berarti kolom utama dan siaga sinkron.

Setara dengan pg_stat_replication di sisi siaga disebut:pg_stat_wal_receiver:

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Ketika tidak ada aktivitas, dan standby telah memutar ulang semuanya maka latest_end_lsn harus sama dengan sent_lsn pada nomor urut utama (dan semua log perantara).

Sama halnya dengan replikasi fisik, dalam kasus replikasi logis, di mana peran utama diambil oleh penerbit, dan peran siaga diambil oleh pelanggan, tentu saja peran pg_stat_wal_receiver diambil oleh pg_stat_subscription . Kami dapat menanyakan pg_stat_subscription sebagai berikut:

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

Perhatikan bahwa di sisi penerbit, tampilan yang sesuai sama seperti dalam kasus replikasi fisik:pg_stat_replication .

Tampilan Statistik yang Dikumpulkan

pg_stat_archiver view memiliki satu baris yang memberikan info tentang pengarsip wal. Menyimpan snapshot baris ini secara berkala memungkinkan Anda menghitung ukuran lalu lintas WAL di antara interval tersebut. Juga memberikan info tentang kegagalan saat mengarsipkan file WAL.

pg_stat_bgwriter view memberikan informasi yang sangat penting tentang perilaku:

• Poin pemeriksaan
• Penulis latar
• Backend (penayangan klien)

Karena tampilan ini memberikan data akumulatif sejak reset terakhir, Sangat berguna untuk membuat tabel stempel waktu lain dengan snapshot berkala pg_stat_bgwriter , sehingga akan mudah untuk mendapatkan perspektif tambahan antara dua snapshot. Tuning adalah ilmu (atau keajaiban), dan memerlukan pencatatan dan pemantauan yang ekstensif serta pemahaman yang jelas tentang konsep yang mendasari dan internal PostgreSQL untuk mendapatkan hasil yang baik, dan pandangan ini adalah tempat untuk memulai, mencari hal-hal seperti:

• Apakah checkpoints_timed sebagian besar dari total pos pemeriksaan? Jika tidak, maka tindakan harus diambil, hasil diukur, dan ulangi seluruh proses sampai tidak ada perbaikan yang ditemukan.
• Apakah buffers_checkpoint mayoritas yang baik dibandingkan dua jenis lainnya (buffers_clean tapi yang paling penting buffers_backend ) ? Jika buffers_backend tinggi, sekali lagi, parameter konfigurasi tertentu harus diubah, pengukuran baru harus diambil dan dinilai ulang.

Pg_stat_[user|sys|all]_tables

Penggunaan paling dasar dari pandangan tersebut adalah untuk memverifikasi bahwa strategi vakum kami berfungsi seperti yang diharapkan. Nilai besar tupel mati relatif terhadap tupel hidup menandakan penghisapan yang tidak efisien. Tampilan tersebut juga memberikan info tentang pemindaian dan pengambilan seq vs indeks, info tentang jumlah baris yang dimasukkan, diperbarui, dihapus, serta pembaruan PANAS. Anda harus mencoba untuk menjaga jumlah pembaruan PANAS setinggi mungkin untuk meningkatkan kinerja.

Pg_stat_[user|sys|all]_indexes

Di sini sistem menyimpan dan menampilkan info tentang penggunaan indeks individual. Satu hal yang perlu diingat adalah bahwa idx_tup_read lebih akurat daripada idx_tup_fetch. Non PK/ Indeks non unik dengan idx_scan rendah harus dipertimbangkan untuk dihapus, karena hanya menghalangi pembaruan PANAS. Seperti disebutkan di blog sebelumnya, pengindeksan berlebihan harus dihindari, pengindeksan memerlukan biaya.

Pg_statio_[user|sys|all]_tables

Dalam tampilan tersebut, kami dapat menemukan info tentang kinerja cache terkait pembacaan tumpukan tabel, pembacaan indeks, dan pembacaan TOAST. Kueri sederhana untuk menghitung persentase klik, dan distribusi klik di seluruh tabel adalah:

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Ini memberi tahu kita bahwa setidaknya 50% tabel memiliki rasio hit lebih besar dari 96,93%, dan 83,5% tabel memiliki rasio hit lebih baik dari 59,4%

Pg_statio_[user|sys|all]_indexes

Tampilan ini berisi informasi baca/klik blok untuk indeks.

Pg_stat_database

Tampilan ini berisi satu baris per database. Ini menunjukkan beberapa info dari tampilan sebelumnya yang dikumpulkan ke seluruh basis data (blok baca, blok hit, info tentang tups), beberapa informasi yang relevan dengan keseluruhan basis data (total xactions, file temp, konflik, deadclock, waktu baca/tulis) , dan terakhir jumlah backend saat ini.

Hal yang perlu diperhatikan disini adalah rasio blks_hit/(blks_hit + blks_read) :semakin tinggi nilainya semakin baik untuk I/O sistem. Namun kesalahan tidak perlu diperhitungkan untuk pembacaan disk karena mungkin telah dilayani dengan sangat baik oleh cache filesys OS.

Sama halnya dengan tampilan statistik yang dikumpulkan lainnya yang disebutkan di atas, seseorang harus membuat versi pg_stat_database yang diberi cap waktu. melihat dan melihat perbedaan antara dua snapshot berturut-turut:

• Apakah jumlah rollback meningkat?
• Atau jumlah tindakan yang dilakukan?
• Apakah kita mendapatkan lebih banyak konflik daripada kemarin (ini berlaku untuk standby)?
• Apakah jumlah deadlock kita sangat tinggi?

Semua itu adalah data yang sangat penting. Dua yang pertama mungkin berarti beberapa perubahan dalam beberapa pola penggunaan, yang harus dijelaskan. Jumlah konflik yang tinggi mungkin berarti replikasi memerlukan penyesuaian. Jumlah kebuntuan yang tinggi buruk karena berbagai alasan. Tidak hanya kinerjanya rendah karena transaksi dibatalkan, tetapi juga jika aplikasi mengalami kebuntuan dalam topologi master tunggal, masalahnya hanya akan bertambah besar jika kita pindah ke multi-master. Dalam hal ini, departemen rekayasa perangkat lunak harus menulis ulang potongan kode yang menyebabkan kebuntuan.

Kunci

Mengunci adalah topik yang sangat penting di PostgreSQL dan layak mendapatkan blognya sendiri. Namun demikian, pemantauan kunci dasar harus dilakukan dengan cara yang sama seperti aspek pemantauan lainnya yang disajikan di atas. pg_locks tampilan memberikan informasi waktu nyata tentang kunci saat ini dalam sistem. Kami dapat menangkap kunci menunggu lama dengan menyetel log_lock_waits , maka informasi tentang menunggu lama akan dicatat di log PgSQL. Jika kita melihat penguncian tinggi yang tidak biasa yang mengakibatkan menunggu lama sekali lagi, seperti dalam kasus dengan kebuntuan yang disebutkan di atas, insinyur perangkat lunak harus meninjau setiap potongan kode yang mungkin menyebabkan penguncian lama, mis. penguncian eksplisit dalam aplikasi (LOCK TABLE atau SELECT … FOR UPDATE).

Sama halnya dengan kasus kebuntuan, sistem dengan kunci pendek akan lebih mudah dipindahkan ke pengaturan multi-master.