Pengenalan filosofis
Seperti yang Anda ketahui, hanya ada dua metode untuk menyelesaikan masalah:
- Metode analisis atau metode deduksi, atau dari umum ke khusus.
- Metode sintesis atau metode induksi, atau dari khusus ke umum.
Untuk mengatasi masalah “meningkatkan kinerja database”, mungkin terlihat seperti ini.
analisis — kami menganalisis masalah menjadi beberapa bagian dan, dengan menyelesaikannya, kami mencoba meningkatkan kinerja database secara keseluruhan.
Dalam praktiknya, analisisnya terlihat seperti ini:
- Terjadi masalah (insiden kinerja)
- Mengumpulkan informasi statistik tentang keadaan database
- Mencari kemacetan
- Kami memecahkan masalah dari kemacetan
Kemacetan basis data — infrastruktur (CPU, Memori, Disk, Jaringan, OS), pengaturan (postgresql.conf), pertanyaan:
Infrastruktur: Kemungkinan pengaruh dan perubahan bagi seorang insinyur hampir nol.
Pengaturan Basis Data: kemungkinan perubahannya sedikit lebih besar dibandingkan kasus sebelumnya, namun secara umum masih cukup sulit, terutama di awan.
Pertanyaan ke basis data: satu-satunya area untuk bermanuver.
Sintesis — kami meningkatkan kinerja masing-masing bagian, dengan harapan bahwa kinerja database akan meningkat sebagai hasilnya.
Pengantar liris atau mengapa semua ini perlu
Bagaimana proses penyelesaian insiden kinerja jika kinerja database tidak dipantau:
Pelanggan - “semuanya buruk bagi kami, butuh waktu terlalu lama, lakukan sesuatu yang baik untuk kami”
Insinyur - “seberapa buruknya?”
Pelanggan – “begitulah keadaannya sekarang (satu jam yang lalu, kemarin, terakhir kali), pelan-pelan”
Insinyur - “kapan kondisinya bagus?”
Pelanggan – “seminggu (dua minggu) yang lalu lumayan. “(Ini beruntung)
Pelanggan - “Saya tidak ingat kapan dulu bagus, tapi sekarang jelek” (Jawaban biasa)
Hasilnya adalah gambaran klasik:
Siapa yang harus disalahkan dan apa yang harus dilakukan?
Bagian pertama dari pertanyaan ini adalah yang paling mudah dijawab - insinyur DBA selalu disalahkan.
Bagian kedua juga tidak terlalu sulit untuk dijawab - Anda perlu mengimplementasikan sistem pemantauan kinerja database.
Pertanyaan pertama muncul - apa yang harus dipantau?
Jalur 1. Kami akan memantau SEMUANYA
Beban CPU, jumlah operasi baca/tulis disk, ukuran memori yang dialokasikan, dan megaton penghitung berbeda lainnya yang dapat disediakan oleh sistem pemantauan yang kurang lebih berfungsi.
Hasilnya adalah sekumpulan grafik, tabel ringkasan, dan pemberitahuan email berkelanjutan dan 100% insinyur sibuk memecahkan sekumpulan tiket yang identik, namun, biasanya, dengan kata-kata standar - “Masalah sementara. Tidak perlu tindakan apa pun.” Tapi semua orang sibuk, dan selalu ada sesuatu untuk ditunjukkan kepada pelanggan - pekerjaan sedang berjalan lancar.
Cara 2. Pantau saja yang diperlukan saja, dan yang tidak diperlukan tidak perlu dipantau
Anda dapat memantau, dengan sedikit berbeda, hanya entitas dan peristiwa:
- Insinyur DBA Mana yang Dapat Mempengaruhi
- Yang mana terdapat algoritma tindakan ketika suatu peristiwa terjadi atau suatu entitas berubah.
Berdasarkan asumsi ini dan mengingat "Pengenalan filosofis"untuk menghindari pengulangan yang teratur"Pengantar liris atau mengapa semua ini perlu“Disarankan untuk memantau kinerja masing-masing kueri untuk pengoptimalan dan analisis, yang pada akhirnya akan mengarah pada peningkatan kinerja seluruh database.
Namun untuk meningkatkan kueri berat yang memengaruhi kinerja database secara keseluruhan, Anda harus menemukannya terlebih dahulu.
Jadi, muncul dua pertanyaan yang saling terkait:
- permintaan mana yang dianggap sulit
- cara mencari pertanyaan yang sulit.
Jelas sekali, kueri berat adalah kueri yang menggunakan banyak sumber daya OS untuk mendapatkan hasilnya.
Mari beralih ke pertanyaan kedua - bagaimana cara mencari dan memantau kueri berat?
Kemampuan pemantauan kueri apa yang dimiliki PostgreSQL?
Dibandingkan dengan Oracle, kemungkinannya kecil, tapi masih ada yang bisa dilakukan.
PG_STAT_STATEMENTS
Ekstensi standar pg_stat_statements dirancang untuk mencari dan memantau kueri berat di PostgreSQL.
Setelah menginstal ekstensi, tampilan dengan nama yang sama muncul di database target, yang harus digunakan untuk tujuan pemantauan.
Targetkan kolom pg_stat_statements untuk membangun sistem pemantauan:
- id kueri Kode hash internal dihitung dari pohon parse operator
- waktu_maks Waktu maksimum yang dihabiskan untuk sebuah pernyataan, dalam milidetik
Dengan mengumpulkan dan menggunakan statistik pada dua kolom ini, Anda dapat membangun sistem pemantauan.
Bagaimana pg_stat_statements digunakan untuk memantau kinerja PostgreSQL
Untuk memantau kinerja kueri, gunakan:
Di sisi database target - tampilan pg_stat_statements
Dari samping server dan memantau basis data - serangkaian skrip bash dan tabel layanan.
Tahap 1 - pengumpulan data statistik
Pada host pemantauan cron, sebuah skrip diluncurkan secara berkala yang menyalin konten tampilan pg_stat_statements dari database target ke tabel pg_stat_history di database pemantauan.
Ini menciptakan riwayat eksekusi kueri individual yang dapat digunakan untuk menghasilkan laporan kinerja dan mengonfigurasi metrik.
Tahap 2 - menyiapkan metrik kinerja
Berdasarkan data yang dikumpulkan, kami memilih kueri yang eksekusinya paling kritis/penting untuk klien (aplikasi). Sesuai dengan pelanggan, kami menetapkan nilai metrik kinerja menggunakan bidang queryid dan max_time.
Hasilnya adalah dimulainya pemantauan kinerja
- Skrip pemantauan, ketika dijalankan, memeriksa metrik kinerja yang dikonfigurasi dengan membandingkan nilai max_time metrik dengan nilai dari tampilan pg_stat_statements di database target.
- Jika nilai di database target melebihi nilai metrik, maka akan dihasilkan peringatan (insiden di sistem tiket)
Opsi tambahan 1
Riwayat rencana kueri
Untuk membantu menyelesaikan insiden kinerja di kemudian hari, ada baiknya Anda memiliki riwayat perubahan rencana eksekusi kueri.
Tabel layanan log_query digunakan untuk menyimpan riwayat. Tabel diisi saat menganalisis file log PostgreSQL yang dimuat. Karena file log, tidak seperti tampilan pg_stat_statements, berisi teks lengkap dengan nilai parameter eksekusi, dan bukan teks yang dinormalisasi, dimungkinkan untuk mencatat tidak hanya waktu dan durasi permintaan, tetapi juga menyimpan rencana eksekusi pada saat ini waktu.
Opsi tambahan 2
Proses peningkatan kinerja berkelanjutan
Pemantauan kueri individual secara umum tidak dimaksudkan untuk memecahkan masalah peningkatan kinerja database secara keseluruhan secara terus-menerus, karena pemantauan dan penyelesaian masalah kinerja hanya untuk kueri individual. Namun, Anda dapat memperluas metode ini dan mengonfigurasi kueri pemantauan untuk semua database.
Untuk melakukan ini, Anda perlu memasukkan metrik kinerja tambahan:
- Untuk hari-hari terakhir
- Untuk periode dasar
Skrip memilih kueri dari tampilan pg_stat_statements di database target dan membandingkan nilai max_time dengan nilai rata-rata max_time, dalam kasus pertama untuk hari-hari terakhir atau untuk periode waktu yang dipilih (baseline), dalam kasus kedua.
Jadi, jika terjadi penurunan kinerja untuk permintaan apa pun, peringatan akan dihasilkan secara otomatis, tanpa analisis laporan secara manual.
Apa hubungannya sintesis dengan itu?
Dalam pendekatan yang dijelaskan, seperti yang disarankan oleh metode sintesis, dengan memperbaiki bagian-bagian individual dari sistem, kita meningkatkan sistem secara keseluruhan.
- Kueri yang dieksekusi oleh database – abstrak
- Permintaan yang dimodifikasi adalah antitesis
- Mengubah keadaan sistem - sintesis
Pengembangan sistem
- Ekstensi statistik yang dikumpulkan dengan menambahkan riwayat untuk tampilan sistem pg_stat_activity
- Memperluas statistik yang dikumpulkan dengan menambahkan riwayat statistik masing-masing tabel yang berpartisipasi dalam kueri
- Integrasi dengan sistem pemantauan cloud AWS
- Namun, Anda dapat menemukan sesuatu...
Sumber: www.habr.com
