Saya sarankan Anda membaca transkrip laporan Nikolai Samokhvalov βPendekatan industri untuk menyetel PostgreSQL: eksperimen pada databaseβ
Shared_buffers = 25% β banyak atau sedikit? Atau tepat? Bagaimana Anda tahu apakah rekomendasi ini - yang agak ketinggalan jaman - cocok untuk kasus Anda?
Saatnya untuk mendekati masalah pemilihan parameter postgresql.conf "seperti orang dewasa". Bukan dengan bantuan "auto tuner" yang buta atau saran kuno dari artikel dan blog, tetapi berdasarkan:
- eksperimen yang diverifikasi secara ketat pada basis data, dilakukan secara otomatis, dalam jumlah besar dan dalam kondisi yang sedekat mungkin dengan kondisi βpertempuranβ,
- pemahaman mendalam tentang fitur DBMS dan OS.
Menggunakan Nancy CLI (), kita akan melihat contoh spesifik - shared_buffers yang terkenal - dalam situasi yang berbeda, dalam proyek yang berbeda dan mencoba mencari cara untuk memilih pengaturan optimal untuk infrastruktur, database, dan beban kita.
Kami akan berbicara tentang eksperimen dengan database. Ini adalah cerita yang berlangsung kurang lebih enam bulan.
Sedikit tentang saya. Pengalaman dengan Postgres selama lebih dari 14 tahun. Sejumlah perusahaan jejaring sosial telah didirikan. Postgres dulu dan digunakan di mana-mana.
Juga grup RuPostgres di Meetup, peringkat 2 dunia. Kami perlahan mendekati 2 orang. RuPostgres.org.
Dan di PC dari berbagai konferensi, termasuk Highload, saya bertanggung jawab atas database, khususnya Postgres sejak awal.
Dan dalam beberapa tahun terakhir, saya telah memulai kembali praktik konsultasi Postgres saya 11 zona waktu dari sini.
Dan ketika saya melakukan ini beberapa tahun yang lalu, saya sempat berhenti dalam pekerjaan manual aktif dengan Postgres, mungkin sejak 2010. Saya terkejut betapa sedikitnya perubahan rutinitas kerja seorang DBA, dan betapa banyak tenaga kerja manual yang masih perlu digunakan. Dan saya langsung berpikir ada yang tidak beres di sini, saya perlu lebih banyak mengotomatiskan semuanya.
Dan karena semuanya jarak jauh, sebagian besar klien berada di awan. Dan tentu saja banyak yang telah diotomatisasi. Lebih lanjut tentang ini nanti. Artinya, semua ini menghasilkan gagasan bahwa harus ada sejumlah alat, yaitu semacam platform yang akan mengotomatiskan hampir semua tindakan DBA sehingga sejumlah besar database dapat dikelola.
Laporan ini tidak akan mencakup:
- βPeluru perakβ dan pernyataan seperti - tetapkan 8 GB atau 25% shared_buffers dan Anda akan baik-baik saja. Tidak banyak yang bisa dibicarakan tentang shared_buffers.
- "jeroan" yang keras.
Dan apa yang akan terjadi?
- Akan ada prinsip optimasi yang kami terapkan dan kembangkan. Akan ada berbagai macam ide yang muncul dalam perjalanannya dan berbagai tools yang kita buat sebagian besar di Open Source yaitu kita jadikan dasar di Open Source. Apalagi kami punya tiket, semua komunikasi bisa dibilang Open Source. Anda dapat melihat apa yang kami lakukan sekarang, apa yang akan terjadi pada rilis berikutnya, dll.
- Akan ada pula pengalaman dalam menggunakan prinsip-prinsip ini, alat-alat ini di sejumlah perusahaan: dari perusahaan rintisan kecil hingga perusahaan besar.
Bagaimana perkembangannya?
Pertama, tugas utama DBA, selain memastikan pembuatan instance, penerapan cadangan, dll., adalah menemukan hambatan dan mengoptimalkan kinerja.
Sekarang sudah diatur seperti ini. Kami melihat pemantauan, kami melihat sesuatu, tapi kami kehilangan beberapa detail. Kami mulai menggali lebih hati-hati, biasanya dengan tangan kami, dan memahami apa yang harus dilakukan dengannya.
Dan ada dua pendekatan. Pg_stat_statements adalah solusi default untuk mengidentifikasi kueri yang lambat. Dan analisis log Postgres menggunakan pgBadger.
Setiap pendekatan mempunyai kelemahan yang serius. Pada pendekatan pertama, kami telah membuang semua parameter. Dan jika kita melihat tabel grup SELECT * FROM yang kolomnya sama dengan "?" atau β$β sejak Postgres 10. Kami tidak tahu apakah ini pemindaian indeks atau pemindaian seq. Itu sangat tergantung pada parameternya. Jika Anda mengganti nilai yang jarang ditemui di sana, itu akan menjadi pemindaian indeks. Jika Anda mengganti nilai yang menempati 90% tabel di sana, pemindaian seq akan terlihat jelas, karena Postgres mengetahui statistiknya. Dan ini adalah kelemahan besar pg_stat_statements, meskipun beberapa pekerjaan sedang dilakukan.
Kerugian terbesar dari analisis log adalah Anda tidak mampu membeli "log_min_duration_statement = 0" sebagai aturan. Dan kita akan membicarakan hal ini juga. Oleh karena itu, Anda tidak melihat gambaran keseluruhannya. Dan beberapa kueri, yang sangat cepat, mungkin menghabiskan banyak sumber daya, namun Anda tidak akan melihatnya karena berada di bawah ambang batas Anda.
Bagaimana DBA memecahkan masalah yang mereka temukan?
Misalnya, kami menemukan beberapa masalah. Apa yang biasanya dilakukan? Jika Anda seorang pengembang, maka Anda akan melakukan sesuatu pada beberapa contoh yang ukurannya tidak sama. Jika Anda seorang DBA, maka Anda memiliki pementasan. Dan hanya ada satu. Dan dia terlambat enam bulan. Dan Anda berpikir bahwa Anda akan pergi ke produksi. Dan bahkan DBA berpengalaman kemudian memeriksa produksi, pada replikanya. Dan kebetulan mereka membuat indeks sementara, memastikannya membantu, membuangnya dan memberikannya kepada pengembang sehingga mereka dapat memasukkannya ke dalam file migrasi. Ini adalah omong kosong yang terjadi sekarang. Dan ini adalah sebuah masalah.
- Konfigurasi penyetelan.
- Optimalkan kumpulan indeks.
- Ubah kueri SQL itu sendiri (ini adalah cara tersulit).
- Tambahkan kapasitas (cara termudah dalam banyak kasus).
Ada banyak hal yang terjadi dengan hal-hal ini. Ada banyak pegangan di Postgres. Ada banyak hal yang perlu diketahui. Ada banyak indeks di Postgres, terima kasih juga kepada penyelenggara konferensi ini. Dan semua itu perlu diketahui, dan inilah yang membuat non-DBA merasa seperti DBA sedang mempraktikkan ilmu hitam. Artinya, Anda perlu belajar selama 10 tahun untuk mulai memahami semua ini secara normal.
Dan saya adalah pejuang melawan ilmu hitam ini. Saya ingin melakukan segalanya agar ada teknologi, dan tidak ada intuisi dalam semua ini.
Contoh kehidupan
Saya mengamati ini setidaknya di dua proyek, termasuk proyek saya sendiri. Postingan blog lain memberi tahu kita bahwa nilai 1 untuk default_statistict_target adalah bagus. Oke, mari kita coba dalam produksi.
Dan di sinilah kita, dengan menggunakan alat kita dua tahun kemudian, dengan bantuan percobaan pada database yang kita bicarakan hari ini, kita dapat membandingkan apa yang dulu dan apa yang sudah terjadi.
Dan untuk ini kita perlu membuat eksperimen. Ini terdiri dari empat bagian.
- Yang pertama adalah lingkungan. Kami membutuhkan perangkat keras. Dan ketika saya datang ke suatu perusahaan dan menandatangani kontrak, saya meminta mereka untuk memberi saya perangkat keras yang sama seperti di produksi. Untuk setiap Master Anda, saya memerlukan setidaknya satu perangkat keras seperti ini. Entah ini contoh mesin virtual di Amazon atau Google, atau saya memerlukan perangkat keras yang persis sama. Artinya, saya ingin menciptakan kembali lingkungan. Dan dalam konsep lingkungan kami menyertakan versi utama Postgres.
- Bagian kedua adalah objek penelitian kami. Ini adalah basis data. Itu dapat dibuat dengan beberapa cara. Saya akan menunjukkan caranya.
- Bagian ketiga adalah beban. Ini adalah momen tersulit.
- Dan bagian keempat adalah apa yang kita periksa, yaitu apa yang akan kita bandingkan dengan apa. Katakanlah kita dapat mengubah satu atau lebih parameter di konfigurasi, atau kita dapat membuat indeks, dll.
Kami meluncurkan eksperimen. Ini pg_stat_statements. Di sebelah kiri adalah apa yang terjadi. Di sebelah kanan - apa yang terjadi.
Di sebelah kiri default_statistics_target = 100, di sebelah kanan = 1. Kami melihat bahwa ini membantu kami. Secara keseluruhan, semuanya menjadi lebih baik sebesar 000%.
Namun jika kita gulir ke bawah, akan ada grup permintaan dari pgBadger atau dari pg_stat_statements. Ada dua pilihan. Kita akan melihat bahwa beberapa permintaan telah turun sebesar 88%. Dan inilah pendekatan rekayasa. Kita dapat menggali lebih jauh ke dalam karena kita bertanya-tanya mengapa ia tenggelam. Anda perlu memahami apa yang terjadi dengan statistik. Mengapa lebih banyak kelompok dalam statistik menghasilkan hasil yang lebih buruk.
Atau kita tidak bisa menggali, tapi lakukan βALTER TABLEβ¦ ALTER COLUMNβ dan kembalikan 100 ember ke statistik kolom ini. Dan dengan eksperimen lain kami dapat memastikan bahwa patch ini membantu. Semua. Ini adalah pendekatan teknik yang membantu kita melihat gambaran besarnya dan mengambil keputusan berdasarkan data, bukan berdasarkan intuisi.
Beberapa contoh dari daerah lain. Ada tes CI dalam pengujian selama bertahun-tahun. Dan tidak ada proyek waras yang dapat bertahan tanpa pengujian otomatis.
Di industri lain: di bidang penerbangan, di industri otomotif, ketika kita menguji aerodinamika, kita juga mempunyai kesempatan untuk melakukan eksperimen. Kami tidak akan meluncurkan sesuatu dari gambar langsung ke luar angkasa, atau kami tidak akan segera membawa mobil ke lintasan. Misalnya saja ada terowongan angin.
Kita dapat menarik kesimpulan dari pengamatan terhadap industri lain.
Pertama, kami memiliki lingkungan khusus. Ini dekat dengan produksi, tetapi tidak dekat. Fitur utamanya adalah murah, dapat diulang, dan seotomatis mungkin. Dan juga harus ada alat khusus untuk melakukan analisis secara detail.
Kemungkinan besar, saat kita meluncurkan pesawat dan terbang, kita memiliki lebih sedikit kesempatan untuk mempelajari setiap milimeter permukaan sayap dibandingkan di terowongan angin. Kami memiliki lebih banyak alat diagnostik. Kita mampu membawa lebih banyak barang berat yang tidak mampu kita bawa ke pesawat. Sama dengan Postgres. Dalam beberapa kasus, kami mungkin mengaktifkan pencatatan kueri penuh selama eksperimen. Dan kami tidak ingin melakukan ini dalam produksi. Kami bahkan mungkin berencana untuk mengaktifkannya menggunakan auto_explain.
Dan seperti yang saya katakan, otomatisasi tingkat tinggi berarti kita menekan tombol dan mengulanginya. Seharusnya begitu, agar banyak eksperimen, agar berjalan lancar.
Nancy CLI - fondasi βlaboratorium basis dataβ
Jadi kami melakukan hal ini. Artinya, saya membicarakan ide-ide ini pada bulan Juni, hampir setahun yang lalu. Dan kami sudah memiliki apa yang disebut Nancy CLI di Open Source. Hal inilah yang menjadi landasan dalam membangun laboratorium database.
β Ada di Open Source, di Gitlab. Anda bisa mengatakannya, Anda bisa mencobanya. Saya memberikan tautan di slide. Anda dapat mengkliknya dan itu akan ada di sana dalam segala hal.
Tentu saja masih banyak yang masih dalam pengembangan. Ada banyak ide di sana. Tapi ini adalah sesuatu yang kami gunakan hampir setiap hari. Dan ketika kita mempunyai ide - mengapa ketika kita menghapus 40 baris, semuanya tergantung pada IO, maka kita dapat melakukan percobaan dan melihat lebih detail untuk memahami apa yang terjadi dan kemudian mencoba memperbaikinya dengan cepat. Artinya, kami sedang melakukan percobaan. Misalnya, kita mengubah sesuatu dan melihat apa yang terjadi pada akhirnya. Dan kami tidak melakukan ini dalam produksi. Inilah inti dari ide tersebut.
Di mana ini bisa berhasil? Ini dapat bekerja secara lokal, yaitu Anda dapat melakukannya di mana saja, Anda bahkan dapat menjalankannya di MacBook. Kita membutuhkan buruh pelabuhan, ayo pergi. Itu saja. Anda dapat menjalankannya di perangkat keras, atau di mesin virtual, di mana saja.
Dan ada juga peluang untuk menjalankan Amazon dari jarak jauh dalam Instans EC2, di beberapa tempat. Dan ini adalah kesempatan yang sangat keren. Misalnya, kemarin kami melakukan lebih dari 500 eksperimen pada instance i3, dimulai dengan yang termuda dan diakhiri dengan i3-16-xlarge. Dan 500 eksperimen berharga $64. Masing-masing berlangsung selama 15 menit. Artinya, karena tempat yang digunakan di sana, harganya sangat murah - diskon 70%, tagihan per detik Amazon. Anda dapat melakukan banyak hal. Anda dapat melakukan penelitian nyata.
Dan tiga versi utama Postgres didukung. Tidak terlalu sulit untuk menyelesaikan beberapa versi lama dan juga versi ke-12 yang baru.
Kita dapat mendefinisikan suatu objek dalam tiga cara. Ini:
- File buang/sql.
- Cara utamanya adalah dengan mengkloning direktori PGDATA. Biasanya, ini diambil dari server cadangan. Jika Anda memiliki cadangan biner normal, Anda dapat membuat klon dari sana. Jika Anda memiliki cloud, maka kantor cloud seperti Amazon dan Google akan melakukannya untuk Anda. Ini adalah cara paling penting untuk mengkloning produksi nyata. Beginilah cara kami mengungkapnya.
- Dan metode terakhir cocok untuk penelitian ketika Anda ingin memahami cara kerja sesuatu di Postgres. Ini adalah pgbench. Anda dapat menghasilkan menggunakan pgbench. Itu hanya satu opsi "db-pgbench". Anda memberi tahu dia skalanya. Dan semuanya akan dihasilkan di cloud, seperti yang dinyatakan.
Dan memuat:
- Kita dapat mengeksekusi beban dalam satu thread SQL. Ini adalah cara yang paling primitif.
- Dan kita bisa meniru beban tersebut. Dan pertama-tama kita bisa menirunya dengan cara berikut. Kita perlu mengumpulkan semua log. Dan itu menyakitkan. Saya akan menunjukkan alasannya. Dan menggunakan pgreplay kami bermain, yang ada di dalam Nancy.
- Atau pilihan lain. Yang disebut beban kerajinan, yang kita lakukan dengan sejumlah usaha. Menganalisis beban kami saat ini pada sistem pertarungan, kami mengeluarkan kelompok permintaan teratas. Dan dengan menggunakan pgbench kita bisa meniru beban ini di laboratorium.
- Entah kita harus melakukan semacam SQL, yaitu kita memeriksa semacam migrasi, membuat indeks di sana, menjalankan ANALAZE di sana. Dan kita lihat apa yang terjadi sebelum vakum dan setelah vakum. Secara umum, SQL apa pun.
- Entah kita mengubah satu atau lebih parameter di konfigurasi. Kami dapat meminta kami untuk memeriksa, misalnya, 100 nilai di Amazon untuk database terabyte kami. Dan dalam beberapa jam Anda akan mendapatkan hasilnya. Biasanya, Anda memerlukan waktu beberapa jam untuk menyebarkan database terabyte. Tetapi ada patch yang sedang dikembangkan, kami memiliki serangkaian kemungkinan, yaitu Anda dapat secara konsisten menggunakan pgdata yang sama di server yang sama dan memeriksanya. Postgres akan dimulai ulang dan cache akan diatur ulang. Dan Anda dapat mengemudikan beban.
- Sebuah direktori hadir dengan banyak file berbeda, mulai dari snapshot pgStat***. Dan yang paling menarik ada pg_stat_statements, pg_stat_kcacke. Ini adalah dua ekstensi yang menganalisis permintaan. Dan pg_stat_bgwriter tidak hanya berisi statistik pgwriter, tetapi juga pos pemeriksaan dan bagaimana backend itu sendiri menggantikan buffer kotor. Dan semuanya menarik untuk dilihat. Misalnya, saat kita menyiapkan shared_buffers, sangat menarik untuk melihat berapa banyak yang diganti.
- Log Postgres juga tiba. Dua log β log persiapan dan log pemutaran beban.
- Fitur yang relatif baru adalah FlameGraphs.
- Selain itu, jika Anda menggunakan opsi pgreplay atau pgbench untuk memutar beban, maka keluarannya akan asli. Dan Anda akan melihat latensi dan TPS. Adalah mungkin untuk memahami bagaimana mereka melihatnya.
- Sistem Informasi.
- Pemeriksaan CPU dan IO dasar. Ini lebih untuk instans EC2 di Amazon, ketika Anda ingin meluncurkan 100 instans identik dalam sebuah thread dan menjalankan 100 proses berbeda di sana, maka Anda akan memiliki 10 eksperimen. Dan Anda perlu memastikan bahwa Anda tidak menemukan contoh cacat yang telah ditindas oleh seseorang. Yang lain aktif pada perangkat keras ini dan Anda hanya memiliki sedikit sumber daya tersisa. Lebih baik membuang hasil seperti itu. Dan dengan bantuan sysbench dari Alexei Kopytov, kami melakukan beberapa pemeriksaan singkat yang akan datang dan dapat dibandingkan dengan yang lain, yaitu Anda akan memahami bagaimana perilaku CPU dan bagaimana perilaku IO.
Apa kesulitan teknis berdasarkan contoh dari berbagai perusahaan?
Katakanlah kita ingin mengulangi beban sebenarnya menggunakan log. Ide yang bagus jika ditulis pada pgreplay Open Source. Kami menggunakannya. Namun agar dapat berfungsi dengan baik, Anda harus mengaktifkan pencatatan kueri lengkap dengan parameter dan waktu.
Ada beberapa komplikasi terkait durasi dan stempel waktu. Kami akan mengosongkan seluruh dapur ini. Pertanyaan utamanya adalah apakah Anda mampu membelinya atau tidak?
Masalahnya adalah hal itu mungkin tidak tersedia. Pertama-tama, Anda harus memahami aliran apa yang akan ditulis ke log. Jika Anda memiliki pg_stat_statements, Anda dapat menggunakan kueri ini (tautannya akan tersedia di slide) untuk memahami kira-kira berapa byte yang akan ditulis per detik.
Kami melihat panjang permintaannya. Kami mengabaikan fakta bahwa tidak ada parameter, namun kami mengetahui durasi permintaan dan mengetahui berapa kali permintaan dieksekusi per detik. Dengan cara ini kita dapat memperkirakan kira-kira berapa byte per detik. Kita mungkin melakukan kesalahan dua kali lipat, tapi kita pasti akan memahami urutannya dengan cara ini.
Kita dapat melihat bahwa 802 kali per detik permintaan ini dieksekusi. Dan kita melihat bahwa bytes_per sec β 300 kB/s akan ditulis plus atau minus. Dan, sebagai suatu peraturan, kita mampu melakukan aliran seperti itu.
Tetapi! Faktanya adalah ada sistem logging yang berbeda. Dan default orang biasanya adalah "syslog".
Dan jika Anda memiliki syslog, Anda mungkin memiliki gambar seperti ini. Kami akan menggunakan pgbench, mengaktifkan pencatatan kueri dan melihat apa yang terjadi.
Tanpa logging - ini adalah kolom di sebelah kiri. Kami mendapat 161 TPS. Dengan syslog - ini di Ubuntu 000 di Amazon, kami mendapatkan 16.04 TPS. Dan jika kita mengubah ke dua metode logging lainnya, maka situasinya jauh lebih baik. Artinya, kami memperkirakan akan turun, namun tidak pada tingkat yang sama.
Dan di CentOS 7, di mana journald juga berpartisipasi, mengubah log menjadi format biner untuk memudahkan pencarian, dll., maka itu adalah mimpi buruk di sana, kami turun 44 kali di TPS.
Dan inilah yang dijalani orang-orang. Dan seringkali di perusahaan, terutama perusahaan besar, hal ini sangat sulit diubah. Jika Anda bisa keluar dari syslog, silakan menjauh darinya.
- Evaluasi IOPS dan tulis alur.
- Periksa sistem pencatatan Anda.
- Jika beban yang diproyeksikan terlalu besar, pertimbangkan pengambilan sampel.
Kami memiliki pg_stat_statements. Seperti yang saya katakan, itu pasti ada. Dan kita dapat mengambil dan mendeskripsikan setiap kelompok permintaan dengan cara khusus dalam sebuah file. Dan kemudian kita dapat menggunakan fitur yang sangat berguna di pgbench - ini adalah kemampuan untuk memasukkan beberapa file menggunakan opsi "-f".
Ia memahami banyak "-f". Dan Anda dapat mengetahui dengan bantuan β@β di akhir pembagian apa yang harus dimiliki setiap file. Artinya, kita dapat mengatakan bahwa lakukan ini pada 10% kasus, dan ini pada 20%. Dan ini akan membawa kita lebih dekat dengan apa yang kita lihat dalam produksi.
Bagaimana kita memahami apa yang kita miliki dalam produksi? Bagian apa dan bagaimana caranya? Ini sedikit tambahan. Kami memiliki satu produk lagi . Juga basis di Open Source. Dan kami sekarang secara aktif mengembangkannya.
Ia dilahirkan karena alasan yang sedikit berbeda. Karena alasan bahwa pemantauan saja tidak cukup. Artinya, Anda datang, lihat dasarnya, lihat permasalahan yang ada. Dan, sebagai aturan, Anda melakukan health_check. Jika Anda seorang DBA berpengalaman, maka Anda melakukan health_check. Kami melihat penggunaan indeks, dll. Jika Anda memiliki OKmeter, maka bagus. Ini adalah pemantauan keren untuk Postgres. OKmeter.io β silakan instal, semuanya dilakukan dengan sangat baik di sana. Itu berbayar.
Jika Anda tidak memilikinya, biasanya Anda tidak punya banyak. Dalam monitoring biasanya ada CPU, IO, lalu dengan reservasi, itu saja. Dan kami membutuhkan lebih banyak lagi. Kita perlu melihat cara kerja autovacuum, cara kerja checkpoint, di io kita perlu memisahkan checkpoint dari bgwriter dan dari backend, dll.
Masalahnya adalah ketika Anda membantu perusahaan besar, mereka tidak dapat mengimplementasikan sesuatu dengan cepat. Mereka tidak dapat dengan cepat membeli OKmeter. Mungkin mereka akan membelinya dalam enam bulan. Mereka tidak dapat mengirimkan beberapa paket dengan cepat.
Dan kami mendapat ide bahwa kami memerlukan alat khusus yang tidak memerlukan instalasi apa pun, yaitu Anda tidak perlu menginstal apa pun sama sekali pada produksi. Instal di laptop Anda, atau di server pengamat tempat Anda akan menjalankannya. Dan itu akan menganalisis banyak hal: sistem operasi, sistem file, dan Postgres itu sendiri, membuat beberapa pertanyaan ringan yang dapat dijalankan langsung ke produksi dan tidak ada yang gagal.
Kami menyebutnya pemeriksaan Postgres. Dalam istilah medis, ini adalah pemeriksaan kesehatan rutin. Kalau bertema otomotif, ya seperti perawatan. Anda melakukan perawatan mobil Anda setiap enam bulan atau satu tahun, tergantung mereknya. Apakah Anda melakukan pemeliharaan untuk markas Anda? Artinya, apakah Anda melakukan penelitian mendalam secara rutin? Itu harus dilakukan. Jika Anda melakukan backup, kemudian melakukan pengecekan, hal ini tidak kalah pentingnya.
Dan kami memiliki alat seperti itu. Ini mulai aktif muncul sekitar tiga bulan lalu. Dia masih muda, tapi ada banyak hal di sana.
Mengumpulkan kelompok pertanyaan yang paling "berpengaruh" - laporkan K003 di pemeriksaan Postgres
Dan ada kelompok laporan K. Tiga laporan sejauh ini. Dan ada laporan seperti K003. Ada bagian atas dari pg_stat_statements, diurutkan berdasarkan total_waktu.
Saat kami mengurutkan grup permintaan berdasarkan total_waktu, di bagian atas kami melihat grup yang paling banyak memuat sistem kami, yaitu menggunakan lebih banyak sumber daya. Mengapa saya memberi nama grup kueri? Karena kami membuang parameternya. Ini bukan lagi permintaan, tetapi kelompok permintaan, yaitu diabstraksi.
Dan jika kami mengoptimalkan dari atas ke bawah, kami akan meringankan sumber daya kami dan menunda saat kami perlu melakukan peningkatan. Ini adalah cara yang sangat baik untuk menghemat uang.
Mungkin ini bukan cara yang baik untuk menjaga pengguna, karena kita mungkin tidak melihat kasus yang jarang terjadi, namun sangat menjengkelkan di mana seseorang menunggu 15 detik. Secara total, mereka sangat langka sehingga kita tidak melihatnya, tapi kita berurusan dengan sumber daya.
Apa yang terjadi di tabel ini? Kami mengambil dua foto. Postgres_checkup akan memberi Anda delta untuk setiap metrik: total waktu, panggilan, baris, shared_blks_read, dll. Itu saja, delta telah dihitung. Masalah besar dengan pg_stat_statements adalah ia tidak ingat kapan direset. Jika pg_stat_database mengingatnya, maka pg_stat_statements tidak mengingatnya. Anda lihat ada angka 1, tapi kita tidak tahu dari mana kita menghitungnya.
Dan di sini kita tahu, di sini kita mempunyai dua gambaran. Kita tahu bahwa delta dalam kasus ini adalah 56 detik. Kesenjangan yang sangat singkat. Diurutkan berdasarkan total_waktu. Lalu kita bisa membedakannya, yaitu kita membagi semua metrik berdasarkan durasi. Jika kita membagi setiap metrik berdasarkan durasi, kita akan mendapatkan jumlah panggilan per detik.
Selanjutnya, total_waktu per detik adalah metrik favorit saya. Ini diukur dalam detik, per detik, yaitu berapa detik yang dibutuhkan sistem kami untuk mengeksekusi kelompok permintaan ini per detik. Jika Anda melihat lebih dari satu detik per detik di sana, berarti Anda harus memberikan lebih dari satu inti. Ini adalah metrik yang sangat bagus. Bisa dimaklumi, sobat ini misalnya membutuhkan setidaknya tiga core.
Ini adalah pengetahuan kami, saya belum pernah melihat yang seperti ini di mana pun. Harap dicatat - ini adalah hal yang sangat sederhana - detik per detik. Terkadang, ketika CPU Anda 100%, maka setengah jam per detik, artinya, Anda menghabiskan setengah jam hanya untuk melakukan permintaan ini.
Selanjutnya kita melihat baris per detik. Kita tahu berapa banyak baris per detik yang dikembalikan.
Lalu ada juga hal yang menarik. Berapa banyak shared_buffers yang kita baca per detik dari shared_buffers itu sendiri. Hitnya sudah ada, dan kami mengambil baris dari cache sistem operasi atau dari disk. Opsi pertama cepat, dan opsi kedua mungkin cepat atau tidak, tergantung situasinya.
Dan cara diferensiasi yang kedua adalah dengan membagi jumlah permintaan dalam kelompok ini. Di kolom kedua Anda akan selalu memiliki satu kueri yang dibagi per kueri. Dan yang menarik - berapa milidetik dalam permintaan ini. Kami tahu rata-rata perilaku kueri ini. Diperlukan 101 milidetik untuk setiap permintaan. Ini adalah metrik tradisional yang perlu kita pahami.
Berapa rata-rata baris yang dihasilkan setiap kueri? Kami melihat 8 grup ini kembali. Rata-rata, berapa banyak yang diambil dari cache dan dibaca. Kami melihat semuanya di-cache dengan baik. Hit yang solid untuk grup pertama.
Dan substring keempat di setiap baris berapa persentasenya dari total. Kami mendapat telepon. Katakanlah 1. Dan kita bisa memahami kontribusi apa yang diberikan kelompok ini. Kita melihat bahwa dalam kasus ini kelompok pertama memberikan kontribusi kurang dari 000%. Artinya, sangat lambat sehingga kita tidak melihatnya dalam gambaran keseluruhan. Dan kelompok kedua adalah 000% untuk panggilan. Artinya, 0,01% dari seluruh panggilan adalah grup kedua.
Total_time juga menarik. Kami menghabiskan 14% dari total waktu kerja kami pada kelompok permintaan pertama. Dan untuk yang kedua - 11%, dll.
Saya tidak akan menjelaskan secara detail, tetapi ada kehalusan di sana. Kami menampilkan kesalahan di atas, karena ketika kami membandingkan, snapshot mungkin mengambang, yaitu, beberapa permintaan mungkin gagal dan tidak lagi ada di permintaan kedua, sementara beberapa permintaan baru mungkin muncul. Dan di sana kami menghitung kesalahannya. Jika Anda melihat 0, maka itu bagus. Tidak ada kesalahan. Jika tingkat kesalahannya sampai 20%, tidak apa-apa.
Kemudian kita kembali ke topik kita. Kita perlu menyusun beban kerja. Kami mengambilnya dari atas ke bawah dan terus mencapai 80% atau 90%. Biasanya 10-20 kelompok. Dan kami membuat file untuk pgbench. Kami menggunakan acak di sana. Sayangnya, terkadang hal ini tidak berhasil. Dan di Postgres 12 akan ada lebih banyak peluang untuk menggunakan pendekatan ini.
Dan kemudian kita memperoleh 80-90% total_time dengan cara ini. Apa yang harus saya masukkan selanjutnya setelah β@β? Kami melihat panggilan telepon, melihat seberapa besar minat yang ada dan memahami bahwa kami berhutang banyak pada hal ini. Dari persentase tersebut kita dapat memahami bagaimana cara menyeimbangkan setiap file. Setelah itu kami menggunakan pgbench dan mulai bekerja.
Kami juga memiliki K001 dan K002.
K001 adalah satu string besar dengan empat substring. Ini adalah karakteristik dari keseluruhan beban kita. Lihat kolom kedua dan subbaris kedua. Kita melihatnya sekitar satu setengah detik per detik, yaitu jika ada dua inti, maka itu akan bagus. Akan ada sekitar 75% kapasitas. Dan itu akan bekerja seperti ini. Jika kita mempunyai 10 core, maka secara umum kita akan tenang. Dengan cara ini kita dapat mengevaluasi sumber daya.
K002 itulah yang saya sebut kelas query, yaitu SELECT, INSERT, UPDATE, DELETE. Dan secara terpisah PILIH UNTUK UPDATE, karena itu adalah kunci.
Dan di sini kita dapat menyimpulkan bahwa SELECT adalah pembaca biasa - 82% dari semua panggilan, tetapi pada saat yang sama - 74% total_time. Artinya, mereka banyak dipanggil, tetapi mengkonsumsi lebih sedikit sumber daya.
Dan kita kembali ke pertanyaan: βBagaimana kita bisa memilih shared_buffers yang tepat?β Saya mengamati bahwa sebagian besar tolok ukur didasarkan pada gagasan - mari kita lihat seperti apa throughputnya, yaitu berapa throughputnya. Biasanya diukur dalam TPS atau QPS.
Dan kami mencoba memeras sebanyak mungkin transaksi per detik dari mobil menggunakan parameter penyetelan. Ini tepatnya 311 per detik untuk dipilih.
Namun tidak ada yang berkendara ke tempat kerja dan pulang ke rumah dengan kecepatan penuh. Ini konyol. Sama dengan database. Kami tidak harus mengemudi dengan kecepatan penuh, dan tidak ada yang melakukannya. Tidak ada yang hidup dalam produksi, yang memiliki CPU 100%. Meskipun mungkin ada yang hidup, tapi ini tidak baik.
Idenya adalah kita biasanya berkendara dengan kapasitas 20 persen, sebaiknya tidak lebih dari 50%. Dan kami berusaha mengoptimalkan waktu respons bagi pengguna kami. Artinya, kita harus memutar kenop kita agar ada latensi minimum pada kecepatan 20%, dengan syarat. Ini adalah ide yang juga kami coba gunakan dalam eksperimen kami.
Dan terakhir, rekomendasi:
- Pastikan untuk melakukan Lab Basis Data.
- Jika memungkinkan, lakukan sesuai permintaan sehingga terbuka beberapa saat - mainkan dan buang. Jika Anda memiliki awan, maka hal ini sudah jelas, yaitu memiliki banyak berdiri.
- Penasaran. Dan jika ada yang salah, periksa dengan eksperimen bagaimana perilakunya. Nancy dapat digunakan untuk melatih diri sendiri untuk memeriksa cara kerja pangkalan.
- Dan bidik waktu respons minimum.
- Dan jangan takut dengan sumber Postgres. Saat Anda bekerja dengan sumber, Anda harus tahu bahasa Inggris. Banyak sekali komentar disana, semuanya dijelaskan disana.
- Dan periksa kesehatan database secara berkala, minimal tiga bulan sekali, secara manual, atau Postgres-checkup.
pertanyaan
Terima kasih banyak! Suatu hal yang sangat menarik.
Dua potong.
Ya, dua potong. Hanya saja aku tidak begitu mengerti. Saat Nancy dan saya bekerja, bisakah kami mengubah hanya satu parameter atau keseluruhan grup?
Kami memiliki parameter konfigurasi delta. Anda dapat berbelok ke sana sebanyak yang Anda inginkan sekaligus. Namun perlu Anda pahami bahwa ketika Anda mengubah banyak hal, Anda bisa menarik kesimpulan yang salah.
Ya. Mengapa saya bertanya? Karena sulit melakukan eksperimen jika hanya memiliki satu parameter. Anda mengencangkannya, lihat cara kerjanya. Aku mengusirnya. Kemudian Anda memulai yang berikutnya.
Anda dapat mengencangkannya secara bersamaan, tetapi tentu saja itu tergantung situasinya. Tapi lebih baik menguji satu ide. Kami punya ide kemarin. Kami memiliki situasi yang sangat dekat. Ada dua konfigurasi. Dan kami tidak dapat memahami mengapa ada perbedaan besar. Dan muncullah gagasan bahwa Anda perlu menggunakan dikotomi agar dapat secara konsisten memahami dan menemukan apa perbedaannya. Anda dapat langsung membuat separuh parameternya sama, lalu seperempatnya, dan seterusnya. Semuanya fleksibel.
Dan ada satu pertanyaan lagi. Proyek ini masih muda dan berkembang. Dokumentasinya sudah siap, ada penjelasan detailnya?
Saya secara khusus membuat tautan di sana ke deskripsi parameter. Ada disana. Namun masih banyak hal yang belum tercapai. Saya mencari orang yang berpikiran sama. Dan saya menemukannya ketika saya tampil. Ini keren sekali. Seseorang sudah bekerja dengan saya, seseorang membantu dan melakukan sesuatu di sana. Dan jika Anda tertarik dengan topik ini, berikan masukan tentang apa yang kurang.
Begitu kita bangun laboratoriumnya, mungkin akan ada feedback. Mari kita lihat. Terima kasih!
Halo! Terima kasih atas laporannya! Saya melihat ada dukungan Amazon. Apakah ada rencana untuk mendukung GSP?
Pertanyaan bagus. Kami mulai melakukannya. Dan kami membekukannya untuk saat ini karena kami ingin menghemat uang. Artinya, ada dukungan menggunakan run di localhost. Anda dapat membuat instance sendiri dan bekerja secara lokal. Ngomong-ngomong, itulah yang kami lakukan. Saya melakukan ini di Getlab, di GSP. Namun kami belum melihat gunanya melakukan orkestrasi seperti itu saja, karena Google tidak punya tempat yang murah. Ada ??? contohnya, namun mereka mempunyai keterbatasan. Pertama, mereka selalu hanya mendapat diskon 70% dan Anda tidak bisa bermain-main dengan harga di sana. Di beberapa tempat, kami menaikkan harga sebesar 5-10% untuk mengurangi kemungkinan Anda ditendang. Artinya, Anda menyimpan tempat, tetapi tempat tersebut dapat diambil dari Anda kapan saja. Jika Anda menawar sedikit lebih tinggi dari yang lain, Anda akan dibunuh nanti. Google memiliki spesifikasi yang sangat berbeda. Dan ada batasan lain yang sangat buruk - mereka hanya hidup selama 24 jam. Dan terkadang kami ingin menjalankan eksperimen selama 5 hari. Namun Anda bisa melakukan ini di beberapa titik; terkadang bintik tersebut bertahan hingga berbulan-bulan.
Halo! Terima kasih atas laporannya! Anda menyebutkan pemeriksaan. Bagaimana cara menghitung kesalahan stat_statements?
Pertanyaan yang sangat bagus. Saya dapat menunjukkan dan memberi tahu Anda dengan sangat detail. Singkatnya, kita melihat bagaimana kumpulan grup permintaan muncul: berapa banyak yang hilang dan berapa banyak grup baru yang muncul. Lalu kita melihat dua metrik: total_time dan panggilan, jadi ada dua kesalahan. Dan kami melihat kontribusi kelompok terapung. Ada dua subkelompok: mereka yang pergi dan mereka yang datang. Mari kita lihat apa kontribusi mereka terhadap gambaran keseluruhan.
Tidakkah Anda takut gambar akan muncul dua atau tiga kali di antara pengambilan gambar?
Artinya, apakah mereka mendaftar lagi atau bagaimana?
Misalnya permintaan ini sudah didahului satu kali, lalu datang dan didahului lagi, lalu datang lagi dan didahului lagi. Dan Anda menghitung sesuatu di sini, dan di mana semuanya?
Pertanyaan bagus, kita harus memeriksanya.
Saya melakukan hal serupa. Tentu saja lebih sederhana, saya melakukannya sendiri. Tapi saya harus mengatur ulang, mengatur ulang stat_statements dan mencari tahu pada saat snapshot bahwa ada kurang dari pecahan tertentu, yang masih belum mencapai batas atas berapa banyak stat_statements yang dapat terakumulasi di sana. Dan pemahaman saya adalah, kemungkinan besar, tidak ada yang tergeser.
Ya ya.
Tapi saya tidak mengerti bagaimana lagi melakukannya dengan andal.
Sayangnya, saya tidak ingat persis apakah kita menggunakan teks kueri di sana atau queryid dengan pg_stat_statements dan fokus padanya. Jika kita fokus pada queryid, maka secara teori kita membandingkan hal-hal yang sebanding.
Tidak, dia bisa dipaksa keluar beberapa kali di antara pengambilan gambar dan muncul lagi.
Dengan identitas yang sama?
Ya.
Kami akan mempelajari ini. Pertanyaan bagus. Kita perlu mempelajarinya. Tapi untuk saat ini, apa yang kita lihat tertulis 0...
Ini tentu saja merupakan kasus yang jarang terjadi, tetapi saya terkejut ketika mengetahui bahwa stat_statemetns dapat menggantikan sana.
Ada banyak hal di Pg_stat_statements. Kami menemukan fakta bahwa jika Anda mengaktifkan track_utility =, maka set Anda juga dilacak.
Ya tentu saja
Dan jika Anda memiliki Java hibernate yang acak, maka tabel hash mulai ditempatkan di sana. Dan segera setelah Anda mematikan aplikasi yang sangat dimuat, Anda akan mendapatkan 50-100 grup. Dan semuanya kurang lebih stabil di sana. Salah satu cara untuk mengatasi hal ini adalah dengan meningkatkan pg_stat_statements.max.
Ya, tapi Anda perlu tahu seberapa banyak. Dan entah bagaimana kita perlu mengawasinya. Itu yang saya lakukan. Artinya, saya punya pg_stat_statements.max. Dan saya melihat bahwa pada saat pengambilan gambar saya belum mencapai 70%. Oke, jadi kita tidak kehilangan apa pun. Mari kita atur ulang. Dan kami menabung lagi. Jika snapshot berikutnya kurang dari 70, kemungkinan besar Anda tidak kehilangan apa pun lagi.
Ya. Standarnya sekarang adalah 5. Dan ini cukup untuk banyak orang.
Biasanya ya.
Video:
P.S. Atas nama saya sendiri, saya akan menambahkan bahwa jika Postgres berisi data rahasia dan tidak dapat disertakan dalam lingkungan pengujian, maka Anda dapat menggunakan . Skemanya kira-kira sebagai berikut:
Sumber: www.habr.com