Saya sarankan Anda membaca transkrip laporan oleh Alexei Lesovsky dari Data Egret “Fundamentals of PostgreSQL monitoring”
Dalam laporan ini, Alexei Lesovsky akan membahas poin-poin penting dari statistik pasca-perang, apa maksudnya, dan mengapa statistik tersebut harus ada dalam pemantauan; tentang grafik apa yang harus di pantau, cara menambahkannya, dan cara menafsirkannya. Laporan ini akan berguna bagi administrator basis data, administrator sistem, dan pengembang yang tertarik dengan pemecahan masalah Postgres.
Nama saya Alexei Lesovsky, saya mewakili perusahaan Data Egret.
Beberapa kata tentang diriku. Saya sudah lama memulai sebagai administrator sistem.
Saya mengelola segala macam sistem Linux yang berbeda, mengerjakan berbagai hal yang berkaitan dengan Linux, misalnya virtualisasi, pemantauan, bekerja dengan proxy, dll. Namun pada titik tertentu saya mulai lebih banyak bekerja dengan database, PostgreSQL. Saya sangat menyukainya. Dan pada titik tertentu saya mulai mengerjakan PostgreSQL sebagian besar waktu kerja saya. Dan secara bertahap saya menjadi DBA PostgreSQL.
Dan sepanjang karir saya, saya selalu tertarik dengan topik statistik, monitoring, dan telemetri. Dan ketika saya menjadi administrator sistem, saya bekerja sangat erat dengan Zabbix. Dan saya menulis serangkaian skrip kecil seperti . Dia cukup populer pada masanya. Dan di sana dimungkinkan untuk memantau berbagai hal penting, tidak hanya Linux, tetapi juga berbagai komponen.
Sekarang saya sedang mengerjakan PostgreSQL. Saya sudah menulis hal lain yang memungkinkan Anda bekerja dengan statistik PostgreSQL. Itu disebut (artikel tentang Habré - ).
Sedikit catatan pengantar. Situasi apa yang dialami pelanggan kami, klien kami? Ada semacam kecelakaan terkait dengan database. Dan ketika database sudah dipulihkan, kepala departemen atau kepala pengembangan datang dan berkata: “Teman-teman, kita perlu memantau database, karena sesuatu yang buruk telah terjadi dan kita perlu mencegah hal ini terjadi di masa mendatang.” Dan di sini dimulailah proses menarik dalam memilih sistem pemantauan atau mengadaptasi sistem pemantauan yang ada sehingga Anda dapat memantau database Anda - PostgreSQL, MySQL atau yang lainnya. Dan rekan-rekannya mulai menyarankan: “Saya dengar ada database ini dan itu. Ayo kita gunakan." Rekan kerja mulai berdebat satu sama lain. Dan pada akhirnya ternyata kami memilih beberapa jenis database, tetapi pemantauan PostgreSQL disajikan di dalamnya dengan agak buruk dan kami harus selalu menambahkan sesuatu. Ambil beberapa repositori dari GitHub, kloning, sesuaikan skrip, dan sesuaikan. Dan pada akhirnya menjadi semacam pekerjaan manual.
Oleh karena itu, dalam pembicaraan kali ini saya akan mencoba memberi Anda sedikit pengetahuan tentang bagaimana memilih pemantauan tidak hanya untuk PostgreSQL, tetapi juga untuk database. Dan memberi Anda pengetahuan yang memungkinkan Anda menyelesaikan pemantauan untuk mendapatkan manfaat darinya, sehingga Anda dapat memantau database Anda dengan manfaat, untuk segera mencegah situasi darurat yang mungkin timbul.
Dan ide-ide yang akan ada dalam laporan ini bisa langsung diadaptasi ke database apapun, baik itu DBMS atau noSQL. Oleh karena itu, tidak hanya PostgreSQL saja, tetapi akan ada banyak resep cara melakukan ini di PostgreSQL. Akan ada contoh query, contoh entitas yang dimiliki PostgreSQL untuk pemantauan. Dan jika DBMS Anda memiliki hal yang sama yang memungkinkan Anda untuk memantaunya, Anda juga dapat menyesuaikannya, menambahkannya dan itu akan bagus.
Saya tidak akan masuk dalam laporan
berbicara tentang cara mengirimkan dan menyimpan metrik. Saya tidak akan mengatakan apa pun tentang pasca-pemrosesan data dan menyajikannya kepada pengguna. Dan saya tidak akan mengatakan apa pun tentang peringatan.
Namun seiring berjalannya cerita, saya akan menunjukkan tangkapan layar berbeda dari pemantauan yang ada dan mengkritiknya. Namun demikian, saya akan berusaha untuk tidak menyebutkan merek agar tidak menimbulkan iklan atau anti iklan untuk produk tersebut. Oleh karena itu, semua kebetulan bersifat acak dan bergantung pada imajinasi Anda.
Pertama, mari kita cari tahu apa itu pemantauan. Pengawasan merupakan hal yang sangat penting untuk dimiliki. Semua orang memahami hal ini. Namun pada saat yang sama, pemantauan tidak berhubungan dengan produk bisnis dan tidak mempengaruhi keuntungan perusahaan secara langsung, sehingga waktu selalu dialokasikan untuk pemantauan secara sisa. Kalau ada waktu, baru kita monitoring; kalau tidak ada waktu, oke, kita simpan di backlog, dan suatu saat kita akan kembali mengerjakan tugas tersebut.
Oleh karena itu, dari praktik kami, ketika kami mendatangi klien, pemantauan sering kali tidak lengkap dan tidak ada hal menarik yang dapat membantu kami melakukan pekerjaan lebih baik dengan database. Oleh karena itu, pemantauan harus selalu dilakukan.
Basis data merupakan hal kompleks yang juga perlu diawasi, karena basis data merupakan tempat penyimpanan informasi. Dan informasi sangat penting bagi perusahaan, tidak boleh hilang dalam bentuk apapun. Namun pada saat yang sama, database adalah perangkat lunak yang sangat kompleks. Mereka terdiri dari sejumlah besar komponen. Dan banyak dari komponen ini yang perlu dipantau.
Jika kita berbicara secara khusus tentang PostgreSQL, maka dapat direpresentasikan dalam bentuk skema yang terdiri dari sejumlah besar komponen. Komponen-komponen ini berinteraksi satu sama lain. Dan pada saat yang sama, PostgreSQL memiliki apa yang disebut subsistem Stats Collector, yang memungkinkan Anda mengumpulkan statistik tentang pengoperasian subsistem ini dan menyediakan semacam antarmuka kepada administrator atau pengguna sehingga dia dapat melihat statistik ini.
Statistik ini disajikan dalam bentuk sekumpulan fungsi dan tampilan tertentu. Mereka juga bisa disebut tabel. Artinya, dengan menggunakan klien psql biasa, Anda dapat terhubung ke database, memilih fungsi dan tampilan ini, dan mendapatkan beberapa nomor spesifik tentang pengoperasian subsistem PostgreSQL.
Anda dapat menambahkan angka-angka ini ke sistem pemantauan favorit Anda, menggambar grafik, menambahkan fungsi, dan mendapatkan analisis dalam jangka panjang.
Namun dalam laporan ini saya tidak akan membahas semua fungsi tersebut secara lengkap, karena bisa memakan waktu seharian penuh. Saya akan membahas dua, tiga, atau empat hal dan memberi tahu Anda bagaimana hal tersebut membantu menjadikan pemantauan lebih baik.
Dan jika kita berbicara tentang monitoring database, lalu apa saja yang perlu dimonitor? Pertama-tama, kita perlu memantau ketersediaannya, karena database adalah layanan yang menyediakan akses data kepada klien dan kita perlu memantau ketersediaannya, serta memberikan beberapa karakteristik kualitatif dan kuantitatifnya.
Kita juga perlu memonitor klien-klien yang terhubung ke database kita, karena mereka bisa berupa klien biasa maupun klien berbahaya yang dapat membahayakan database. Mereka juga perlu dipantau dan aktivitasnya dilacak.
Ketika klien terhubung ke database, jelas bahwa mereka mulai bekerja dengan data kita, jadi kita perlu memantau bagaimana klien bekerja dengan data: dengan tabel yang mana, dan pada tingkat yang lebih rendah, dengan indeks yang mana. Artinya, kita perlu mengevaluasi beban kerja yang dibuat oleh klien kita.
Namun beban kerja tentu saja juga terdiri dari permintaan. Aplikasi terhubung ke database, mengakses data menggunakan query, jadi penting untuk mengevaluasi query apa yang kita miliki di database, memantau kecukupannya, tidak ditulis secara bengkok, bahwa beberapa opsi perlu ditulis ulang dan dibuat agar bekerja lebih cepat. dan dengan kinerja yang lebih baik.
Dan karena kita berbicara tentang database, database selalu merupakan proses latar belakang. Proses latar belakang membantu menjaga kinerja database pada tingkat yang baik, sehingga memerlukan sejumlah sumber daya agar dapat beroperasi. Dan pada saat yang sama, proses tersebut dapat tumpang tindih dengan sumber daya permintaan klien, sehingga proses latar belakang yang serakah dapat secara langsung memengaruhi kinerja permintaan klien. Oleh karena itu, mereka juga perlu dipantau dan dilacak agar tidak terjadi distorsi pada proses latar belakang.
Dan semua ini dalam hal pemantauan basis data tetap berada dalam metrik sistem. Namun mengingat sebagian besar infrastruktur kami berpindah ke cloud, metrik sistem dari masing-masing host selalu memudar ke latar belakang. Namun dalam database mereka masih relevan dan, tentu saja, metrik sistem juga perlu dipantau.
Semuanya kurang lebih baik-baik saja dengan metrik sistem, semua sistem pemantauan modern sudah mendukung metrik ini, namun secara umum beberapa komponen masih belum cukup dan ada beberapa hal yang perlu ditambahkan. Saya juga akan menyentuhnya, akan ada beberapa slide tentangnya.
Poin pertama dari rencana tersebut adalah aksesibilitas. Apa itu aksesibilitas? Ketersediaan dalam pemahaman saya adalah kemampuan basis untuk melayani koneksi, yaitu basis ditinggikan, sebagai layanan, menerima koneksi dari klien. Dan aksesibilitas ini dapat dinilai berdasarkan karakteristik tertentu. Sangat mudah untuk menampilkan karakteristik ini di dasbor.
Semua orang tahu apa itu dashboard. Ini adalah saat Anda melihat layar yang berisi ringkasan informasi yang diperlukan. Dan Anda bisa langsung mengetahui apakah ada masalah pada database atau tidak.
Oleh karena itu, ketersediaan database dan karakteristik utama lainnya harus selalu ditampilkan di dashboard agar informasi ini tersedia dan selalu tersedia untuk Anda. Beberapa rincian tambahan yang sudah membantu dalam penyelidikan insiden, ketika menyelidiki beberapa situasi darurat, rincian tersebut sudah perlu ditempatkan di dasbor sekunder, atau disembunyikan di tautan penelusuran yang mengarah ke sistem pemantauan pihak ketiga.
Contoh salah satu sistem pemantauan yang terkenal. Ini adalah sistem pemantauan yang sangat keren. Dia mengumpulkan banyak data, tetapi menurut saya, dia memiliki konsep dasbor yang aneh. Ada tautan untuk "membuat dasbor". Namun saat Anda membuat dasbor, Anda membuat daftar dua kolom, daftar grafik. Dan ketika Anda perlu melihat sesuatu, Anda mulai mengklik dengan mouse, menggulir, mencari grafik yang diinginkan. Dan ini membutuhkan waktu, yaitu tidak ada dasbor seperti itu. Hanya ada daftar grafik.
Apa yang harus Anda tambahkan ke dasbor ini? Anda bisa memulai dengan karakteristik seperti waktu respons. PostgreSQL memiliki tampilan pg_stat_statements. Ini dinonaktifkan secara default, tetapi ini adalah salah satu tampilan sistem penting yang harus selalu diaktifkan dan digunakan. Ini menyimpan informasi tentang semua kueri berjalan yang telah dieksekusi dalam database.
Oleh karena itu, kita dapat memulai dari fakta bahwa kita dapat mengambil total waktu eksekusi semua permintaan dan membaginya dengan jumlah permintaan menggunakan kolom di atas. Tapi ini adalah suhu rata-rata di rumah sakit. Kita bisa memulai dari bidang lain - waktu eksekusi kueri minimum, maksimum, dan median. Dan kita bahkan dapat membuat persentil; PostgreSQL memiliki fungsi yang sesuai untuk ini. Dan kita bisa mendapatkan beberapa angka yang mencirikan waktu respons database kita untuk permintaan yang sudah selesai, yaitu. kita tidak menjalankan permintaan palsu 'pilih 1' dan melihat waktu respons, tetapi kita menganalisis waktu respons untuk permintaan yang sudah selesai dan menggambar baik gambar terpisah, atau kita membuat grafik berdasarkan gambar tersebut.
Penting juga untuk memantau jumlah kesalahan yang saat ini dihasilkan oleh sistem. Dan untuk ini Anda dapat menggunakan tampilan pg_stat_database. Kami fokus pada bidang xact_rollback. Bidang ini tidak hanya menunjukkan jumlah rollback yang terjadi dalam database, namun juga memperhitungkan jumlah kesalahan. Secara relatif, kami dapat menampilkan angka ini di dasbor kami dan melihat berapa banyak kesalahan yang kami alami saat ini. Jika terdapat banyak kesalahan, maka ini adalah alasan yang baik untuk melihat log dan melihat jenis kesalahannya dan mengapa hal itu terjadi, lalu berinvestasi dan menyelesaikannya.
Anda dapat menambahkan sesuatu seperti Tachometer. Ini adalah jumlah transaksi per detik dan jumlah permintaan per detik. Secara relatif, Anda dapat menggunakan angka-angka ini sebagai kinerja database Anda saat ini dan mengamati apakah ada puncak permintaan, puncak transaksi, atau, sebaliknya, apakah database kekurangan beban karena beberapa backend gagal. Penting untuk selalu melihat angka ini dan mengingat bahwa untuk proyek kita kinerja seperti ini normal, tetapi nilai di atas dan di bawah sudah menjadi semacam masalah dan tidak dapat dipahami, yang berarti kita perlu melihat mengapa angka-angka ini begitu tinggi.
Untuk memperkirakan jumlah transaksi, kita bisa kembali mengacu pada tampilan pg_stat_database. Kita dapat menambahkan jumlah commit dan jumlah rollback dan mendapatkan jumlah transaksi per detik.
Apakah semua orang memahami bahwa beberapa permintaan dapat ditampung dalam satu transaksi? Oleh karena itu TPS dan QPS sedikit berbeda.
Jumlah permintaan per detik dapat diperoleh dari pg_stat_statements dan cukup menghitung jumlah semua permintaan yang diselesaikan. Jelas bahwa kita membandingkan nilai saat ini dengan nilai sebelumnya, menguranginya, mendapatkan delta, dan mendapatkan kuantitasnya.
Anda dapat menambahkan metrik tambahan jika diinginkan, yang juga membantu mengevaluasi ketersediaan database kami dan memantau apakah ada waktu henti.
Salah satu metrik ini adalah waktu aktif. Namun uptime di PostgreSQL agak rumit. Saya akan memberi tahu Anda alasannya. Ketika PostgreSQL telah dimulai, uptime mulai dilaporkan. Tetapi jika suatu saat, misalnya, suatu tugas sedang berjalan di malam hari, pembunuh OOM datang dan secara paksa menghentikan proses anak PostgreSQL, maka dalam kasus ini PostgreSQL mengakhiri koneksi semua klien, mengatur ulang area memori sharded dan memulai pemulihan dari pos pemeriksaan terakhir. Dan selama pemulihan dari pos pemeriksaan ini berlangsung, database tidak menerima koneksi, yaitu situasi ini dapat dinilai sebagai waktu henti. Namun penghitung uptime tidak akan direset, karena ini memperhitungkan waktu startup postmaster sejak saat pertama. Oleh karena itu, situasi seperti itu dapat dilewati.
Anda juga harus memantau jumlah pekerja vakum. Apakah semua orang tahu apa itu autovacuum di PostgreSQL? Ini adalah subsistem yang menarik di PostgreSQL. Banyak artikel telah ditulis tentang dia, banyak laporan telah dibuat. Ada banyak diskusi tentang vakum dan cara kerjanya. Banyak yang menganggapnya sebagai kejahatan yang perlu. Tapi begitulah adanya. Ini adalah semacam analog dari pengumpul sampah yang membersihkan versi baris lama yang tidak diperlukan oleh transaksi apa pun dan mengosongkan ruang di tabel dan indeks untuk baris baru.
Mengapa Anda perlu memantaunya? Karena penyedot debu terkadang sangat menyakitkan. Ini menghabiskan banyak sumber daya dan sebagai akibatnya permintaan klien mulai terganggu.
Dan itu harus dipantau melalui tampilan pg_stat_activity, yang akan saya bicarakan di bagian selanjutnya. Tampilan ini menunjukkan aktivitas terkini dalam database. Dan melalui kegiatan ini kita dapat melacak jumlah penyedot debu yang berfungsi saat ini. Kita dapat melacak ruang hampa dan melihat bahwa jika kita telah melampaui batas, maka ini adalah alasan untuk melihat pengaturan PostgreSQL dan mengoptimalkan pengoperasian ruang hampa.
Hal lain tentang PostgreSQL adalah PostgreSQL sangat muak dengan transaksi yang panjang. Apalagi dari transaksi yang bertahan lama dan tidak menghasilkan apa-apa. Inilah yang disebut status menganggur dalam transaksi. Transaksi semacam itu mengunci dan mencegah penyedot debu bekerja. Dan akibatnya, meja-meja itu membengkak dan bertambah besar. Dan kueri yang bekerja dengan tabel ini mulai bekerja lebih lambat, karena Anda perlu menyekop semua baris versi lama dari memori ke disk dan sebaliknya. Oleh karena itu, waktu, durasi transaksi terlama, vakum permintaan terlama juga perlu dipantau. Dan jika kita melihat beberapa proses yang sudah berjalan sangat lama, sudah lebih dari 10-20-30 menit untuk load OLTP, maka kita perlu memperhatikannya dan menghentikannya secara paksa, atau mengoptimalkan aplikasi agar dapat berjalan. tidak dipanggil dan tidak digantung terlalu lama. Untuk beban kerja analitik, 10-20-30 menit adalah normal; ada juga yang lebih lama.
Selanjutnya kita memiliki opsi dengan klien yang terhubung. Ketika kita telah membuat dasbor dan memposting metrik ketersediaan kunci di dalamnya, kita juga dapat menambahkan informasi tambahan tentang klien yang terhubung di sana.
Informasi tentang klien yang terhubung penting karena, dari perspektif PostgreSQL, klien itu berbeda. Ada klien yang baik dan ada klien yang buruk.
Sebuah contoh sederhana. Oleh klien saya memahami aplikasinya. Aplikasi telah terhubung ke database dan segera mulai mengirimkan permintaannya ke sana, database memproses dan mengeksekusinya, dan mengembalikan hasilnya ke klien. Ini adalah klien yang baik dan benar.
Ada situasi ketika klien telah terhubung, ia menahan koneksi, tetapi tidak melakukan apa pun. Hal ini dalam keadaan menganggur.
Tapi ada klien yang buruk. Misalnya klien yang sama terhubung, membuka transaksi, melakukan sesuatu di database lalu memasukkan kodenya, misalnya untuk mengakses sumber eksternal atau memproses data yang diterima di sana. Namun dia tidak menutup transaksinya. Dan transaksi tersebut hang di database dan disimpan dalam kunci di telepon. Ini adalah kondisi yang buruk. Dan jika tiba-tiba sebuah aplikasi di suatu tempat di dalam dirinya gagal dengan pengecualian, maka transaksi tersebut dapat tetap terbuka untuk waktu yang sangat lama. Dan ini secara langsung mempengaruhi kinerja PostgreSQL. PostgreSQL akan lebih lambat. Oleh karena itu, penting untuk melacak klien tersebut secara tepat waktu dan menghentikan pekerjaan mereka secara paksa. Dan Anda perlu mengoptimalkan aplikasi Anda agar situasi seperti itu tidak terjadi.
Klien buruk lainnya sedang menunggu klien. Tapi mereka menjadi buruk karena keadaan. Misalnya, transaksi menganggur sederhana: dapat membuka transaksi, mengunci beberapa baris, lalu di suatu tempat dalam kode akan gagal, meninggalkan transaksi yang ditangguhkan. Klien lain akan datang dan meminta data yang sama, tetapi dia akan menemukan kunci, karena transaksi gantung tersebut sudah memegang kunci pada beberapa baris yang diperlukan. Dan transaksi kedua akan berdiam diri menunggu transaksi pertama selesai atau ditutup paksa oleh administrator. Oleh karena itu, transaksi yang tertunda dapat terakumulasi dan memenuhi batas koneksi database. Dan ketika batasnya sudah penuh, aplikasi tidak bisa lagi bekerja dengan database. Ini sudah merupakan situasi darurat untuk proyek tersebut. Oleh karena itu, klien yang buruk perlu dilacak dan ditanggapi tepat waktu.
Contoh lain dari pemantauan. Dan sudah ada dashboard yang layak di sini. Ada informasi tentang koneksi di atas. Koneksi DB – 8 buah. Dan itu saja. Kami tidak mempunyai informasi klien mana yang aktif, klien mana yang hanya menganggur, tidak melakukan apa-apa. Tidak ada informasi tentang transaksi yang tertunda dan koneksi yang tertunda, yaitu ini adalah angka yang menunjukkan jumlah koneksi dan hanya itu. Dan kemudian tebak sendiri.
Oleh karena itu, untuk menambahkan informasi ini ke pemantauan, Anda perlu mengakses tampilan sistem pg_stat_activity. Jika Anda menghabiskan banyak waktu di PostgreSQL, maka ini adalah tampilan yang sangat bagus yang harus menjadi teman Anda, karena ini menunjukkan aktivitas terkini di PostgreSQL, yaitu apa yang terjadi di dalamnya. Untuk setiap proses terdapat baris terpisah yang menampilkan informasi tentang proses ini: dari host mana koneksi dibuat, dengan pengguna apa, dengan nama apa, kapan transaksi dimulai, permintaan apa yang sedang berjalan, permintaan apa yang terakhir kali dieksekusi. Oleh karena itu, kita dapat mengevaluasi keadaan klien menggunakan bidang stat. Secara relatif, kita dapat mengelompokkan berdasarkan bidang ini dan mendapatkan statistik yang saat ini ada di database dan jumlah koneksi yang memiliki statistik ini di database. Dan kami dapat mengirimkan nomor yang sudah diterima ke pemantauan kami dan menggambar grafik berdasarkan nomor tersebut.
Penting juga untuk mengevaluasi durasi transaksi. Saya sudah mengatakan bahwa penting untuk mengevaluasi durasi kekosongan, tetapi transaksi dievaluasi dengan cara yang sama. Ada bidang xact_start dan query_start. Mereka, secara relatif, menunjukkan waktu mulai transaksi dan waktu mulai permintaan. Kita mengambil fungsi now(), yang menunjukkan stempel waktu saat ini, dan mengurangi stempel waktu transaksi dan permintaan. Dan kami mendapatkan durasi transaksi, durasi permintaan.
Jika kita melihat transaksi yang panjang, kita harus menyelesaikannya. Untuk load OLTP, lama transaksi sudah lebih dari 1-2-3 menit. Untuk beban kerja OLAP, transaksi yang panjang adalah hal yang normal, namun jika memerlukan waktu lebih dari dua jam untuk diselesaikan, maka ini juga merupakan tanda bahwa kita mempunyai suatu penyimpangan.
Setelah klien terhubung ke database, mereka mulai bekerja dengan data kami. Mereka mengakses tabel, mereka mengakses indeks untuk mendapatkan data dari tabel. Dan penting untuk mengevaluasi bagaimana klien berinteraksi dengan data ini.
Hal ini diperlukan untuk mengevaluasi beban kerja kami dan memahami secara kasar tabel mana yang “terpanas” bagi kami. Misalnya, ini diperlukan dalam situasi di mana kita ingin menempatkan tabel "panas" pada semacam penyimpanan SSD yang cepat. Misalnya, beberapa tabel arsip yang sudah lama tidak kita gunakan dapat dipindahkan ke semacam arsip "dingin", ke drive SATA dan membiarkannya tinggal di sana, mereka akan diakses sesuai kebutuhan.
Hal ini juga berguna untuk mendeteksi anomali setelah rilis dan penerapan apa pun. Katakanlah proyek tersebut telah merilis beberapa fitur baru. Misalnya, kami menambahkan fungsionalitas baru untuk bekerja dengan database. Dan jika kita memplot grafik penggunaan tabel, kita dapat dengan mudah mendeteksi anomali ini pada grafik tersebut. Misalnya, memperbarui burst atau menghapus burst. Ini akan sangat terlihat.
Anda juga dapat mendeteksi anomali dalam statistik “mengambang”. Apa artinya? PostgreSQL memiliki penjadwal kueri yang sangat kuat dan sangat bagus. Dan para pengembang mencurahkan banyak waktu untuk pengembangannya. Bagaimana cara kerjanya? Untuk membuat perencanaan yang baik, PostgreSQL mengumpulkan statistik distribusi data dalam tabel pada interval waktu tertentu dan frekuensi tertentu. Ini adalah nilai yang paling umum: jumlah nilai unik, informasi tentang NULL dalam tabel, banyak informasi.
Berdasarkan statistik ini, perencana membuat beberapa kueri, memilih yang paling optimal, dan menggunakan rencana kueri ini untuk menjalankan kueri itu sendiri dan mengembalikan data.
Dan kebetulan statistiknya “mengambang”. Data kualitas dan kuantitas berubah dalam tabel, namun statistik tidak dikumpulkan. Dan rencana yang terbentuk mungkin belum maksimal. Dan jika rencana kita ternyata kurang optimal berdasarkan pemantauan yang dikumpulkan, berdasarkan tabel, kita akan bisa melihat anomali tersebut. Misalnya, di suatu tempat data berubah secara kualitatif dan alih-alih indeks, penelusuran berurutan melalui tabel mulai digunakan, mis. jika kueri hanya perlu mengembalikan 100 baris (ada batasan 100), maka pencarian lengkap akan dilakukan untuk kueri ini. Dan ini selalu berdampak buruk pada kinerja.
Dan ini bisa kita lihat dalam pemantauan. Dan lihat kueri ini, jalankan penjelasannya, kumpulkan statistik, buat indeks tambahan baru. Dan sudah menanggapi masalah ini. Itu sebabnya ini penting.
Contoh lain dari pemantauan. Saya rasa banyak orang mengenalinya karena dia sangat populer. Siapa yang menggunakannya dalam proyek mereka ? Siapa yang menggunakan produk ini bersama dengan Prometheus? Faktanya adalah bahwa dalam repositori standar pemantauan ini terdapat dasbor untuk bekerja dengan PostgreSQL - Prometheus. Tapi ada satu detail buruk.
Ada beberapa grafik. Dan byte diindikasikan sebagai kesatuan, yaitu ada 5 grafik. Ini adalah Sisipkan data, Perbarui data, Hapus data, Ambil data, dan Kembalikan data. Satuan pengukurannya adalah byte. Tapi masalahnya adalah statistik di PostgreSQL mengembalikan data dalam tuple (baris). Dan karenanya, grafik ini adalah cara yang sangat baik untuk meremehkan beban kerja Anda beberapa kali, puluhan kali, karena tupel bukanlah satu byte, tupel adalah string, banyak byte, dan selalu memiliki panjang variabel. Artinya, menghitung beban kerja dalam byte menggunakan tupel adalah tugas yang tidak realistis atau sangat sulit. Oleh karena itu, saat Anda menggunakan dasbor atau pemantauan bawaan, penting untuk selalu memahami bahwa dasbor berfungsi dengan benar dan mengembalikan data yang dinilai dengan benar kepada Anda.
Bagaimana cara mendapatkan statistik pada tabel ini? Untuk tujuan ini, PostgreSQL memiliki kelompok pandangan tertentu. Dan tampilan utamanya adalah . User_tables - ini berarti tabel dibuat atas nama pengguna. Sebaliknya, ada tampilan sistem yang digunakan oleh PostgreSQL itu sendiri. Dan ada tabel ringkasan Alltables, yang mencakup tabel sistem dan pengguna. Anda dapat memulai dari salah satu yang paling Anda sukai.
Dengan menggunakan kolom di atas Anda dapat memperkirakan jumlah penyisipan, pembaruan, dan penghapusan. Contoh dashboard yang saya gunakan menggunakan kolom ini untuk mengevaluasi karakteristik suatu beban kerja. Oleh karena itu, kita juga dapat mengembangkannya. Namun perlu diingat bahwa ini adalah tupel, bukan byte, jadi kita tidak bisa melakukannya dalam byte saja.
Berdasarkan data ini, kita dapat membuat apa yang disebut tabel TopN. Misalnya, Top-5, Top-10. Dan Anda dapat melacak tabel panas yang lebih banyak didaur ulang daripada yang lain. Misalnya, 5 tabel "panas" untuk dimasukkan. Dan dengan menggunakan tabel TopN ini, kami mengevaluasi beban kerja dan dapat mengevaluasi lonjakan beban kerja setelah rilis, pembaruan, dan penerapan apa pun.
Penting juga untuk mengevaluasi ukuran tabel, karena terkadang pengembang meluncurkan fitur baru, dan tabel kami mulai membengkak dalam ukurannya yang besar, karena mereka memutuskan untuk menambahkan sejumlah data tambahan, namun tidak memperkirakan bagaimana hal ini akan terjadi. mempengaruhi ukuran database. Kasus-kasus seperti ini juga mengejutkan kita.
Dan sekarang sebuah pertanyaan kecil untuk Anda. Pertanyaan apa yang muncul ketika Anda melihat beban pada server database Anda? Apa pertanyaan Anda selanjutnya?
Namun nyatanya timbul pertanyaan sebagai berikut. Permintaan apa yang disebabkan oleh pemuatan? Artinya, tidak menarik untuk melihat proses yang disebabkan oleh beban tersebut. Jelas jika host memiliki database, maka database tersebut berjalan di sana dan jelas hanya database yang akan dibuang ke sana. Jika kita membuka Top, kita akan melihat daftar proses di PostgreSQL yang melakukan sesuatu. Tidak jelas dari Top apa yang mereka lakukan.
Oleh karena itu, Anda perlu menemukan kueri yang menyebabkan beban tertinggi, karena menyetel kueri, biasanya, memberikan lebih banyak keuntungan daripada menyetel PostgreSQL atau konfigurasi sistem operasi, atau bahkan menyetel perangkat keras. Menurut perkiraan saya, ini sekitar 80-85-90%. Dan ini dilakukan lebih cepat. Memperbaiki permintaan lebih cepat daripada memperbaiki konfigurasi, menjadwalkan restart, terutama jika database tidak dapat di-restart, atau menambahkan perangkat keras. Lebih mudah untuk menulis ulang kueri di suatu tempat atau menambahkan indeks untuk mendapatkan hasil yang lebih baik dari kueri ini.
Oleh karena itu, perlu untuk memantau permintaan dan kecukupannya. Mari kita ambil contoh lain dari pemantauan. Dan di sini juga, tampaknya terdapat pemantauan yang sangat baik. Ada informasi replikasi, ada informasi throughput, pemblokiran, pemanfaatan sumber daya. Semuanya baik-baik saja, tetapi tidak ada informasi tentang permintaan. Tidak jelas kueri apa yang berjalan di database kami, berapa lama kueri tersebut berjalan, berapa banyak kueri tersebut. Kami selalu perlu memiliki informasi ini dalam pemantauan kami.
Dan untuk mendapatkan informasi tersebut kita dapat menggunakan modul pg_stat_statements. Berdasarkan itu, Anda dapat membuat berbagai grafik. Misalnya, Anda bisa memperoleh informasi tentang kueri yang paling sering, yaitu kueri yang paling sering dijalankan. Ya, setelah penerapan, akan sangat berguna juga untuk melihatnya dan memahami jika ada lonjakan permintaan.
Anda dapat memantau kueri terpanjang, yaitu kueri yang membutuhkan waktu paling lama untuk diselesaikan. Mereka berjalan pada prosesor, mereka mengkonsumsi I/O. Kita juga dapat mengevaluasinya menggunakan kolom total_time, mean_time, blk_write_time, dan blk_read_time.
Kita dapat mengevaluasi dan memantau permintaan terberat dalam hal penggunaan sumber daya, permintaan yang membaca dari disk, yang bekerja dengan memori, atau, sebaliknya, membuat semacam beban penulisan.
Kami dapat mengevaluasi permintaan yang paling dermawan. Ini adalah kueri yang mengembalikan sejumlah besar baris. Misalnya, ini mungkin permintaan yang lupa menetapkan batasnya. Dan itu hanya mengembalikan seluruh isi tabel atau kueri di seluruh tabel yang dikueri.
Dan Anda juga dapat memantau kueri yang menggunakan file sementara atau tabel sementara.
Dan kami masih memiliki proses latar belakang. Proses latar belakang pada dasarnya adalah pos pemeriksaan atau disebut juga pos pemeriksaan, yaitu autovacuum dan replikasi.
Contoh lain dari pemantauan. Ada tab Pemeliharaan di sebelah kiri, buka dan berharap melihat sesuatu yang berguna. Tapi ini hanya waktu operasi vakum dan pengumpulan statistik, tidak lebih. Ini adalah informasi yang sangat buruk, jadi kami selalu perlu memiliki informasi tentang cara kerja proses latar belakang di database kami dan apakah ada masalah dalam pekerjaannya.
Saat kita melihat pos pemeriksaan, kita harus ingat bahwa pos pemeriksaan membuang halaman kotor dari area memori shard ke disk, lalu membuat pos pemeriksaan. Dan checkpoint ini kemudian dapat digunakan sebagai tempat pemulihan jika PostgreSQL tiba-tiba dihentikan dalam keadaan darurat.
Oleh karena itu, untuk membuang semua halaman "kotor" ke disk, Anda perlu melakukan sejumlah penulisan. Dan, sebagai aturan, pada sistem dengan jumlah memori yang besar, ini banyak. Dan jika kita melakukan checkpoint sangat sering dalam jangka waktu yang singkat, maka kinerja disk akan turun sangat signifikan. Dan permintaan klien akan mengalami kekurangan sumber daya. Mereka akan bersaing untuk mendapatkan sumber daya dan kekurangan produktivitas.
Oleh karena itu, melalui pg_stat_bgwriter menggunakan kolom yang ditentukan, kami dapat memantau jumlah pos pemeriksaan yang terjadi. Dan jika kita memiliki banyak pos pemeriksaan dalam jangka waktu tertentu (dalam 10-15-20 menit, dalam setengah jam), misalnya 3-4-5, maka ini sudah bisa menjadi masalah. Dan Anda sudah perlu mencari di database, melihat di konfigurasi, apa yang menyebabkan banyaknya pos pemeriksaan. Mungkin ada semacam rekaman besar yang sedang berlangsung. Kita sudah bisa mengevaluasi beban kerja, karena kita sudah menambahkan grafik beban kerja. Kami sudah dapat mengubah parameter pos pemeriksaan dan memastikan bahwa parameter tersebut tidak terlalu memengaruhi kinerja kueri.
Saya kembali ke autovacuum lagi karena seperti yang saya katakan, hal ini dapat dengan mudah menambah kinerja disk dan kueri, jadi selalu penting untuk memperkirakan jumlah autovacuum.
Jumlah pekerja autovacuum dalam database terbatas. Secara default, ada tiga di antaranya, jadi jika kita selalu memiliki tiga pekerja yang bekerja di database, ini berarti autovacuum kita tidak dikonfigurasi, kita perlu menaikkan batas, merevisi pengaturan autovacuum, dan masuk ke konfigurasi.
Penting untuk mengevaluasi pekerja vakum mana yang kita miliki. Entah diluncurkan dari pengguna, DBA datang dan secara manual meluncurkan semacam ruang hampa, dan ini menimbulkan beban. Kami punya masalah. Atau ini adalah jumlah kekosongan yang membuka tutup penghitung transaksi. Untuk beberapa versi PostgreSQL, ini adalah penyedot debu yang sangat berat. Dan mereka dapat dengan mudah menambahkan kinerja karena mereka membaca seluruh tabel, memindai semua blok di tabel itu.
Dan, tentu saja, durasi penyedotan debu. Jika kita memiliki penyedot debu yang tahan lama dan dapat digunakan dalam waktu yang sangat lama, ini berarti kita perlu memperhatikan lagi konfigurasi penyedot debu dan mungkin mempertimbangkan kembali pengaturannya. Karena situasi mungkin muncul ketika penyedot debu bekerja di atas meja untuk waktu yang lama (3-4 jam), tetapi selama penyedot debu bekerja, sejumlah besar baris mati berhasil menumpuk di meja lagi. Dan segera setelah penyedotan debu selesai, dia perlu menyedot debu meja ini lagi. Dan kita sampai pada suatu situasi - kekosongan tanpa akhir. Dan dalam hal ini, ruang hampa tidak dapat mengatasi tugasnya, dan ukuran tabel secara bertahap mulai membengkak, meskipun jumlah data yang berguna di dalamnya tetap sama. Oleh karena itu, selama masa vakum yang lama, kami selalu melihat konfigurasi dan mencoba mengoptimalkannya, namun pada saat yang sama agar kinerja permintaan klien tidak terganggu.
Saat ini praktis tidak ada instalasi PostgreSQL yang tidak memiliki replikasi streaming. Replikasi adalah proses memindahkan data dari master ke replika.
Replikasi di PostgreSQL dilakukan melalui log transaksi. Wizard menghasilkan log transaksi. Log transaksi berjalan melalui koneksi jaringan ke replika, lalu direproduksi di replika. Itu mudah.
Oleh karena itu, tampilan pg_stat_replication digunakan untuk memantau kelambatan replikasi. Tapi tidak semuanya sederhana dengannya. Pada versi 10, tampilan telah mengalami beberapa kali perubahan. Pertama, beberapa bidang telah diganti namanya. Dan beberapa bidang telah ditambahkan. Di versi 10, muncul bidang yang memungkinkan Anda memperkirakan jeda replikasi dalam hitungan detik. Sangat nyaman. Sebelum versi 10, jeda replikasi dapat diperkirakan dalam byte. Opsi ini tetap ada di versi 10, mis. Anda dapat memilih mana yang lebih nyaman bagi Anda - memperkirakan jeda dalam byte atau memperkirakan jeda dalam hitungan detik. Banyak orang melakukan keduanya.
Namun demikian, untuk mengevaluasi jeda replikasi, Anda perlu mengetahui posisi log dalam transaksi. Dan posisi log transaksi ini persis ada di tampilan pg_stat_replication. Secara relatif, kita dapat mengambil dua titik di log transaksi menggunakan fungsi pg_xlog_location_diff(). Hitung delta di antara keduanya dan dapatkan jeda replikasi dalam byte. Ini sangat nyaman dan sederhana.
Di versi 10, fungsi ini diubah namanya menjadi pg_wal_lsn_diff(). Secara umum, di semua fungsi, tampilan, dan utilitas yang muncul kata “xlog”, diganti dengan nilai “wal”. Ini berlaku untuk tampilan dan fungsi. Ini adalah suatu inovasi.
Plus, di versi 10, ditambahkan garis yang secara khusus menunjukkan kelambatan. Ini adalah lag tulis, lag flush, lag replay. Artinya, penting untuk memantau hal-hal tersebut. Jika kami melihat ada kelambatan replikasi, maka kami perlu menyelidiki mengapa hal itu muncul, dari mana asalnya, dan memperbaiki masalahnya.
Hampir semuanya baik-baik saja dengan metrik sistem. Saat pemantauan dimulai, pemantauan dimulai dengan metrik sistem. Ini adalah pembuangan prosesor, memori, swap, jaringan dan disk. Namun, banyak parameter yang tidak ada secara default.
Jika proses daur ulang semuanya beres, maka ada masalah dengan daur ulang disk. Biasanya, pengembang pemantauan menambahkan informasi tentang throughput. Bisa dalam iops atau byte. Namun mereka melupakan latensi dan pemanfaatan perangkat disk. Ini adalah parameter yang lebih penting yang memungkinkan kita mengevaluasi seberapa dimuatnya disk kita dan seberapa lambatnya. Jika kita memiliki latensi tinggi, berarti ada beberapa masalah dengan disk. Jika kita memiliki utilisasi yang tinggi, berarti disk tersebut tidak dapat mengatasinya. Ini adalah karakteristik yang lebih baik daripada throughput.
Selain itu, statistik ini juga dapat diperoleh dari sistem file /proc, seperti yang dilakukan untuk mendaur ulang prosesor. Saya tidak tahu mengapa informasi ini tidak ditambahkan ke pemantauan. Namun demikian, penting untuk memantau hal ini.
Hal yang sama berlaku untuk antarmuka jaringan. Terdapat informasi tentang throughput jaringan dalam paket, dalam byte, namun demikian tidak ada informasi tentang latensi dan tidak ada informasi tentang pemanfaatan, meskipun ini juga merupakan informasi yang berguna.
Pemantauan apa pun memiliki kekurangan. Dan apa pun jenis pemantauan yang Anda lakukan, pemantauan tersebut tidak selalu memenuhi kriteria tertentu. Namun demikian, mereka berkembang, fitur-fitur baru dan hal-hal baru ditambahkan, jadi pilihlah sesuatu dan selesaikan.
Dan untuk menyelesaikannya, Anda harus selalu memiliki gambaran tentang apa arti statistik yang diberikan dan bagaimana Anda dapat menggunakannya untuk memecahkan masalah.
Dan beberapa poin penting:
- Anda harus selalu memantau ketersediaan dan memiliki dasbor sehingga Anda dapat dengan cepat menilai apakah semuanya baik-baik saja dengan database.
- Anda selalu perlu memiliki gagasan tentang klien apa yang bekerja dengan database Anda untuk menyingkirkan klien yang buruk dan menjatuhkan mereka.
- Penting untuk mengevaluasi cara klien ini bekerja dengan data. Anda perlu memiliki gambaran tentang beban kerja Anda.
- Penting untuk mengevaluasi bagaimana beban kerja ini terbentuk, dengan bantuan kueri apa. Anda dapat mengevaluasi kueri, mengoptimalkannya, memfaktorkannya ulang, membuat indeks untuk kueri tersebut. Ini sangat penting.
- Proses latar belakang dapat berdampak negatif terhadap permintaan klien, jadi penting untuk memantau bahwa mereka tidak menggunakan terlalu banyak sumber daya.
- Metrik sistem memungkinkan Anda membuat rencana untuk menskalakan dan meningkatkan kapasitas server Anda, jadi penting untuk melacak dan mengevaluasinya juga.
Jika Anda tertarik dengan topik ini, Anda dapat mengikuti tautan ini.
- ini adalah dokumentasi resmi dari pengumpul statistik. Terdapat deskripsi semua tampilan statistik dan deskripsi semua bidang. Anda dapat membaca, memahami, dan menganalisisnya. Dan berdasarkan hal tersebut, buat grafik Anda dan tambahkan ke pemantauan Anda.
Contoh permintaan:
Ini adalah gudang perusahaan kami dan milik saya. Mereka berisi contoh pertanyaan. Tidak ada pertanyaan dari seri pilih* dari di sana. Sudah ada kueri siap pakai dengan gabungan, menggunakan fungsi menarik yang memungkinkan Anda mengubah angka mentah menjadi nilai yang mudah dibaca dan nyaman, mis. ini adalah byte, waktu. Anda dapat mengambilnya, melihatnya, menganalisisnya, menambahkannya ke pemantauan Anda, membangun pemantauan Anda berdasarkan pada mereka.
pertanyaan
Pertanyaan: Anda mengatakan bahwa Anda tidak akan mengiklankan merek, tetapi saya masih penasaran - jenis dasbor apa yang Anda gunakan dalam proyek Anda?
Jawaban: Bervariasi. Kebetulan kami mendatangi pelanggan dan dia sudah memiliki pengawasannya sendiri. Dan kami memberi saran kepada pelanggan tentang apa yang perlu ditambahkan ke pemantauan mereka. Situasi terburuk terjadi pada Zabbix. Karena tidak memiliki kemampuan untuk membangun grafik TopN. Kami sendiri yang menggunakannya , karena kami berkonsultasi dengan orang-orang ini mengenai pemantauan. Mereka memantau PostgreSQL berdasarkan spesifikasi teknis kami. Saya sedang menulis proyek kesayangan saya sendiri, yang mengumpulkan data melalui Prometheus dan menyajikannya . Tugas saya adalah membuat eksportir sendiri di Prometheus dan kemudian merender semuanya di Grafana.
Pertanyaan: Apakah ada analogi dengan laporan atau... agregasi AWR? Tahukah Anda tentang hal seperti ini?
Jawab: Ya, saya tahu apa itu AWR, itu keren. Saat ini terdapat berbagai macam sepeda yang menerapkan model kurang lebih sebagai berikut. Pada interval waktu tertentu, beberapa garis dasar ditulis ke PostgreSQL yang sama atau ke penyimpanan terpisah. Anda dapat mencarinya di Google di Internet, mereka ada di sana. Salah satu pengembang hal semacam itu sedang duduk di forum sql.ru di thread PostgreSQL. Anda bisa menangkapnya di sana. Ya, ada hal seperti itu, bisa digunakan. Ditambah lagi di dalamnya Saya juga menulis sesuatu yang memungkinkan Anda melakukan hal yang sama.
PS1 Jika Anda menggunakan postgres_exporter, dashboard apa yang Anda gunakan? Ada beberapa di antaranya. Mereka sudah ketinggalan jaman. Mungkin komunitas akan membuat template yang diperbarui?
PS2 Menghapus pganalyze karena merupakan penawaran SaaS eksklusif yang berfokus pada pemantauan kinerja dan saran penyetelan otomatis.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Pemantauan postgresql yang dihosting sendiri (dengan dasbor) manakah yang menurut Anda terbaik?
-
30,0%Zabbix + tambahan dari Alexei Lesovsky atau zabbix 4.4 atau libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze adalah SaaS berpemilik - saya tidak dapat menghapusnya1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 pengguna memilih. 26 pengguna abstain.
Sumber: www.habr.com