Saya cadangkan anda membaca transkrip laporan dari awal tahun 2016 oleh Andrey Salnikov "Ralat biasa dalam aplikasi yang membawa kepada kembung dalam postgresql"
Dalam laporan ini, saya akan menganalisis ralat utama dalam aplikasi yang timbul pada peringkat mereka bentuk dan menulis kod aplikasi. Dan saya hanya akan mengambil ralat yang membawa kepada kembung dalam Postgresql. Sebagai peraturan, ini adalah permulaan penghujung prestasi sistem anda secara keseluruhan, walaupun pada mulanya tiada prasyarat untuk ini kelihatan.
Senang mengalu-alukan semua orang! Laporan ini tidak begitu teknikal seperti yang sebelumnya dari rakan sekerja saya. Laporan ini ditujukan terutamanya kepada pembangun sistem bahagian belakang kerana kami mempunyai bilangan pelanggan yang agak besar. Dan mereka semua melakukan kesilapan yang sama. Saya akan memberitahu anda tentang mereka. Saya akan menerangkan apa yang membawa maut dan perkara buruk daripada kesilapan ini.
Mengapa kesilapan dilakukan? Mereka dilakukan untuk dua sebab: secara rawak, mungkin ia akan berjaya dan kerana ketidaktahuan beberapa mekanisme yang berlaku pada tahap antara pangkalan data dan aplikasi, serta dalam pangkalan data itu sendiri.
Saya akan memberi anda tiga contoh dengan gambar yang mengerikan tentang keadaan yang buruk. Saya akan memberitahu anda secara ringkas tentang mekanisme yang berlaku di sana. Dan bagaimana untuk menanganinya, bila ia berlaku, dan kaedah pencegahan yang digunakan untuk mengelakkan kesilapan. Saya akan memberitahu anda tentang alatan tambahan dan menyediakan pautan yang berguna.
Saya menggunakan pangkalan data ujian di mana saya mempunyai dua jadual. Satu plat dengan akaun pelanggan, satu lagi dengan transaksi pada akaun ini. Dan dengan beberapa kekerapan kami mengemas kini baki pada akaun ini.
Data awal plat: ia agak kecil, 2 MB. Masa tindak balas untuk pangkalan data dan khusus untuk tanda juga sangat baik. Dan beban yang agak baik - 2 operasi sesaat mengikut plat.
Dan melalui laporan ini saya akan menunjukkan kepada anda graf supaya anda dapat memahami dengan jelas apa yang berlaku. Akan sentiasa ada 2 slaid dengan graf. Slaid pertama ialah apa yang berlaku secara umum pada pelayan.
Dan dalam keadaan ini, kita melihat bahawa kita benar-benar mempunyai tanda kecil. Indeksnya kecil iaitu 2 MB. Ini ialah graf pertama di sebelah kiri.
Purata masa tindak balas pada pelayan juga stabil dan pendek. Ini ialah graf kanan atas.
Graf kiri bawah menunjukkan transaksi terpanjang. Kami melihat bahawa urus niaga selesai dengan cepat. Dan autovakum masih belum berfungsi di sini, kerana ia adalah ujian permulaan. Ia akan terus berfungsi dan akan berguna kepada kami.
Slaid kedua akan sentiasa didedikasikan untuk plat yang diuji. Dalam keadaan ini, kami sentiasa mengemas kini baki akaun pelanggan. Dan kami melihat bahawa purata masa tindak balas untuk operasi kemas kini agak baik, kurang daripada satu milisaat. Kami melihat bahawa sumber pemproses (ini ialah graf kanan atas) juga digunakan secara sama rata dan agak kecil.
Graf sebelah kanan bawah menunjukkan jumlah operasi dan memori cakera yang kami lalui untuk mencari baris yang kami kehendaki sebelum mengemas kininya. Dan bilangan operasi mengikut tanda adalah 2 sesaat, seperti yang saya katakan pada mulanya.
Dan kini kita mengalami tragedi. Atas sebab tertentu terdapat transaksi yang lama dilupakan. Alasannya biasanya semua cetek:
- Salah satu yang paling biasa ialah kami mula mengakses perkhidmatan luaran dalam kod aplikasi. Dan perkhidmatan ini tidak menjawab kami. Iaitu, kami membuka transaksi, membuat perubahan dalam pangkalan data dan pergi dari aplikasi untuk membaca mel atau ke perkhidmatan lain dalam infrastruktur kami, dan atas sebab tertentu ia tidak bertindak balas kepada kami. Dan sesi kami tersekat dalam keadaan yang tidak diketahui bila ia akan diselesaikan.
- Situasi kedua ialah apabila pengecualian berlaku dalam kod kami atas sebab tertentu. Dan dalam pengecualian kami tidak memproses penutupan transaksi. Dan kami berakhir dengan sesi gantung dengan transaksi terbuka.
- Dan yang terakhir juga merupakan kes yang agak biasa. Ini adalah kod berkualiti rendah. Sesetengah rangka kerja membuka transaksi. Ia tergantung, dan anda mungkin tidak tahu dalam aplikasi bahawa anda telah menggantungnya.
Ke manakah perkara sebegini membawa?
Sehingga jadual dan indeks kami mula membengkak secara mendadak. Ini adalah kesan kembung yang sama. Bagi pangkalan data, ini bermakna masa tindak balas pangkalan data akan meningkat dengan sangat mendadak dan beban pada pelayan pangkalan data akan meningkat. Dan akibatnya, permohonan kami akan terjejas. Kerana jika anda menghabiskan 10 milisaat dalam kod anda untuk permintaan kepada pangkalan data, 10 milisaat pada logik anda, maka fungsi anda mengambil masa 20 milisaat untuk diselesaikan. Dan sekarang keadaan anda akan menjadi sangat menyedihkan.
Dan mari kita lihat apa yang berlaku. Graf kiri bawah menunjukkan bahawa kami mempunyai transaksi yang panjang. Dan jika kita melihat graf kiri atas, kita melihat bahawa saiz jadual kita telah melonjak secara tiba-tiba daripada dua megabait kepada 300 megabait. Pada masa yang sama, jumlah data dalam jadual tidak berubah, iaitu terdapat jumlah sampah yang agak besar di sana.
Keadaan umum mengenai purata masa tindak balas pelayan juga telah berubah dengan beberapa urutan magnitud. Iaitu, semua permintaan pada pelayan mula jatuh sepenuhnya. Dan pada masa yang sama, proses Postgres dalaman telah dilancarkan dalam bentuk autovakum, yang cuba melakukan sesuatu dan menggunakan sumber.
Apa yang berlaku dengan tanda kami? Sama. Purata masa tindak balas kami mengikut tanda telah melonjak beberapa pesanan magnitud. Khususnya dari segi sumber yang digunakan, kami melihat bahawa beban pada pemproses telah meningkat dengan banyak. Ini ialah graf kanan atas. Dan ia telah meningkat kerana pemproses perlu menyusun sekumpulan baris yang tidak berguna untuk mencari yang diperlukan. Ini ialah graf kanan bawah. Dan akibatnya, bilangan panggilan kami sesaat mula menurun dengan ketara, kerana pangkalan data tidak mempunyai masa untuk memproses bilangan permintaan yang sama.
Kita perlu hidup semula. Kami pergi ke dalam talian dan mengetahui bahawa transaksi yang lama membawa kepada masalah. Kami mencari dan membunuh transaksi ini. Dan semuanya menjadi normal bagi kami. Semuanya berfungsi sebagaimana mestinya.
Kami tenang, tetapi selepas beberapa ketika kami mula menyedari bahawa permohonan itu tidak berfungsi dengan cara yang sama seperti sebelum kecemasan. Permintaan masih diproses dengan lebih perlahan dan jauh lebih perlahan. Satu setengah hingga dua kali lebih perlahan khususnya dalam contoh saya. Beban pada pelayan juga lebih tinggi daripada sebelum kemalangan.
Dan soalan: "Apa yang berlaku kepada pangkalan pada masa ini?" Dan situasi berikut berlaku dengan asas. Pada carta urus niaga anda boleh melihat bahawa ia telah berhenti dan sebenarnya tiada urus niaga jangka panjang. Tetapi saiz papan tanda itu bertambah teruk semasa kemalangan itu. Dan sejak itu mereka tidak berkurangan. Purata masa di pangkalan telah stabil. Dan jawapannya nampaknya datang secukupnya pada kelajuan yang boleh diterima oleh kita. Autovakum menjadi lebih aktif dan mula melakukan sesuatu dengan tanda itu, kerana ia perlu menyaring lebih banyak data.
Khususnya, mengikut plat ujian dengan akaun, tempat kami menukar baki: masa respons untuk permintaan nampaknya telah kembali normal. Tetapi pada hakikatnya ia adalah satu setengah kali lebih tinggi.
Dan daripada beban pada pemproses, kita melihat bahawa beban pada pemproses tidak kembali kepada nilai yang diperlukan sebelum ranap. Dan sebabnya terletak tepat pada graf kanan bawah. Dapat dilihat bahawa sejumlah memori sedang dicari di sana. Iaitu, untuk mencari baris yang diperlukan, kami membazirkan sumber pelayan pangkalan data semasa menyusun data yang tidak berguna. Bilangan urus niaga sesaat telah stabil.
Secara keseluruhannya baik, tetapi keadaannya lebih buruk daripada sebelumnya. Kosongkan kemerosotan pangkalan data akibat daripada aplikasi kami yang berfungsi dengan pangkalan data ini.
Dan untuk memahami apa yang berlaku di sana, jika anda tidak berada di laporan sebelumnya, sekarang mari kita dapatkan sedikit teori. Teori tentang proses dalaman. Mengapa vakum kereta dan apakah fungsinya?
Secara harfiah secara ringkas untuk pemahaman. Pada satu ketika kita mempunyai meja. Kami mempunyai baris dalam jadual. Talian ini boleh aktif, hidup, dan apa yang kita perlukan sekarang. Mereka ditanda dengan warna hijau dalam gambar. Dan terdapat garis mati yang telah diusahakan, telah dikemas kini, dan entri baharu telah muncul padanya. Dan mereka ditandakan bahawa mereka tidak lagi menarik kepada pangkalan data. Tetapi mereka berada dalam jadual kerana ciri Postgres.
Mengapa anda memerlukan vakum kereta? Pada satu ketika, autovakum datang, mengakses pangkalan data dan memintanya: "Sila berikan saya id transaksi tertua yang sedang dibuka dalam pangkalan data." Pangkalan data mengembalikan id ini. Dan autovakum, bergantung padanya, menyusun melalui baris dalam jadual. Dan jika dia melihat bahawa beberapa talian telah diubah oleh urus niaga yang lebih lama, maka dia mempunyai hak untuk menandakannya sebagai baris yang boleh kita gunakan semula pada masa hadapan dengan menulis data baharu di sana. Ini adalah proses latar belakang.
Pada masa ini, kami terus bekerja dengan pangkalan data dan terus membuat beberapa perubahan pada jadual. Dan pada baris ini, yang boleh kami gunakan semula, kami menulis data baharu. Dan dengan itu kita mendapat kitaran, iaitu sepanjang masa beberapa baris lama mati muncul di sana, bukannya mereka kita menulis baris baru yang kita perlukan. Dan ini adalah keadaan biasa untuk PostgreSQL berfungsi.
Apa yang berlaku semasa kemalangan itu? Bagaimanakah proses ini berlaku di sana?
Kami mempunyai tanda dalam beberapa keadaan, beberapa hidup, beberapa garis mati. Vacuum kereta telah tiba. Dia bertanya kepada pangkalan data apakah transaksi tertua kami dan apakah idnya. Saya menerima id ini, yang mungkin beberapa jam yang lalu, mungkin sepuluh minit yang lalu. Ia bergantung pada seberapa berat beban yang anda ada pada pangkalan data anda. Dan dia pergi mencari garisan yang boleh dia tandai sebagai digunakan semula. Dan saya tidak menjumpai baris sedemikian dalam jadual kami.
Tetapi pada masa ini kami terus bekerja dengan meja. Kami melakukan sesuatu di dalamnya, mengemas kininya, menukar data. Apakah yang perlu dilakukan oleh pangkalan data pada masa ini? Dia tiada pilihan selain menambah baris baharu pada penghujung jadual sedia ada. Dan dengan itu saiz meja kami mula membengkak.
Pada hakikatnya, kita memerlukan garis hijau untuk berfungsi. Tetapi semasa masalah sedemikian, ternyata peratusan garis hijau adalah sangat rendah di seluruh jadual.
Dan apabila kami melaksanakan pertanyaan, pangkalan data perlu melalui semua baris: merah dan hijau, untuk mencari baris yang dikehendaki. Dan kesan kembung meja dengan data yang tidak berguna dipanggil "kembung", yang juga memakan ruang cakera kami. Ingat, ia adalah 2 MB, ia menjadi 300 MB? Sekarang tukar megabait kepada gigabait dan anda akan kehilangan semua sumber cakera anda dengan cepat.
Apakah akibat yang mungkin berlaku untuk kita?
- Dalam contoh saya, jadual dan indeks meningkat 150 kali ganda. Sesetengah pelanggan kami mengalami lebih banyak kes maut apabila mereka mula kehabisan ruang cakera.
- Saiz meja itu sendiri tidak akan berkurangan. Autovakum dalam beberapa kes boleh memotong ekor meja jika hanya terdapat garis mati. Tetapi oleh kerana terdapat putaran berterusan, satu garisan hijau mungkin membeku pada penghujung dan tidak dikemas kini, manakala semua yang lain akan ditulis di suatu tempat di permulaan plat. Tetapi ini adalah peristiwa yang tidak mungkin sehingga saiz meja anda sendiri akan mengecil, jadi anda tidak sepatutnya mengharapkannya.
- Pangkalan data perlu mengisih banyak baris yang tidak berguna. Dan kami membazir sumber cakera, kami membazir sumber pemproses dan elektrik.
- Dan ini secara langsung mempengaruhi aplikasi kami, kerana jika pada mulanya kami menghabiskan 10 milisaat untuk permintaan, 10 milisaat pada kod kami, maka semasa ranap sistem kami mula menghabiskan satu saat untuk permintaan dan 10 milisaat pada kod, iaitu pesanan magnitud dalam prestasi aplikasi menurun. Dan apabila kemalangan itu diselesaikan, kami mula menghabiskan 20 milisaat untuk permintaan, 10 milisaat untuk kod. Ini bermakna kita masih menurun sebanyak satu setengah kali ganda dalam produktiviti. Dan ini semua kerana satu transaksi yang terhenti, mungkin kerana kesalahan kami.
- Dan soalan: "Bagaimana kami boleh mendapatkan semuanya kembali?" supaya semuanya baik-baik saja dengan kami dan permintaan datang secepat sebelum kemalangan.
Untuk tujuan ini terdapat kitaran kerja tertentu yang dijalankan.
Mula-mula kita perlu mencari jadual bermasalah yang kembung. Kami faham bahawa dalam sesetengah jadual rakaman lebih aktif, dalam jadual lain kurang aktif. Dan untuk ini kami menggunakan sambungan . Dengan memasang sambungan ini, anda boleh menulis pertanyaan yang akan membantu anda mencari jadual yang agak kembung.
Sebaik sahaja anda telah menemui jadual ini, anda perlu memampatkannya. Sudah ada alat untuk ini. Di syarikat kami, kami menggunakan tiga alat. Yang pertama ialah VACUUM FULL terbina dalam. Dia kejam, keras dan tanpa belas kasihan, tetapi kadang-kadang dia sangat berguna. ΠΈ - Ini adalah utiliti pihak ketiga untuk memampatkan jadual. Dan mereka merawat pangkalan data dengan lebih berhati-hati.
Ia digunakan bergantung pada apa yang lebih mudah untuk anda. Tetapi saya akan memberitahu anda tentang perkara ini pada penghujungnya. Perkara utama ialah terdapat tiga alat. Terdapat banyak untuk dipilih.
Selepas kita membetulkan segala-galanya dan memastikan semuanya baik-baik saja, kita mesti tahu cara untuk mencegah keadaan ini pada masa hadapan:
- Ia boleh dicegah dengan mudah. Anda perlu memantau tempoh sesi pada pelayan Master. Terutamanya sesi berbahaya dalam keadaan terbiar dalam keadaan transaksi. Mereka ini ialah mereka yang baru sahaja membuka transaksi, melakukan sesuatu dan pergi, atau sekadar menggantung, tersesat dalam kod.
- Dan untuk anda, sebagai pembangun, adalah penting untuk menguji kod anda apabila situasi ini timbul. Bukan susah nak buat. Ini akan menjadi pemeriksaan yang berguna. Anda akan mengelakkan sejumlah besar masalah "kebudak-budakan" yang berkaitan dengan transaksi yang panjang.
Dalam graf ini, saya ingin menunjukkan kepada anda bagaimana tanda dan gelagat pangkalan data berubah selepas saya melalui tanda dengan VACUUM FULL dalam kes ini. Ini bukan pengeluaran untuk saya.
Saiz jadual serta-merta kembali kepada keadaan operasi biasa beberapa megabait. Ini tidak banyak menjejaskan purata masa tindak balas untuk pelayan.
Tetapi khusus untuk tanda ujian kami, di mana kami mengemas kini baki akaun, kami melihat bahawa purata masa tindak balas untuk permintaan untuk mengemas kini data dalam tanda itu telah dikurangkan kepada tahap pra-kecemasan. Sumber yang digunakan oleh pemproses untuk melengkapkan permintaan ini juga menurun ke tahap pra-ranap sistem. Dan graf kanan bawah menunjukkan bahawa kini kita dapati dengan tepat garis yang kita perlukan dengan segera, tanpa melalui timbunan garis mati yang ada sebelum jadual dimampatkan. Dan purata masa permintaan kekal pada tahap yang lebih kurang sama. Tetapi di sini saya mempunyai, sebaliknya, ralat dalam perkakasan saya.
Di sinilah kisah pertama berakhir. Ia adalah yang paling biasa. Dan ia berlaku kepada semua orang, tanpa mengira pengalaman pelanggan dan sejauh mana kelayakan pengaturcara. Cepat atau lambat perkara ini berlaku.
Kisah kedua, di mana kami mengagihkan beban dan mengoptimumkan sumber pelayan
- Kami sudah dewasa dan menjadi lelaki yang serius. Dan kami faham bahawa kami mempunyai replika dan adalah baik untuk kami mengimbangi beban: tulis kepada Guru, dan baca dari replika. Dan biasanya keadaan ini timbul apabila kita ingin menyediakan beberapa laporan atau ETL. Dan perniagaan sangat gembira tentang ini. Dia benar-benar mahukan pelbagai laporan dengan banyak analisis yang kompleks.
- Laporan mengambil masa berjam-jam, kerana analitis kompleks tidak boleh dikira dalam milisaat. Kami, seperti lelaki yang berani, menulis kod. Dalam aplikasi sisipan kami membuat rakaman pada Master, dan melaksanakan laporan pada replika.
- Mengagihkan beban.
- Semuanya berfungsi dengan sempurna. Kami hebat.
Dan apakah keadaan ini kelihatan seperti? Khususnya pada graf ini, saya juga menambah tempoh transaksi daripada replika untuk tempoh transaksi. Semua graf lain hanya merujuk kepada pelayan Master.
Pada masa ini, papan laporan saya telah berkembang. Terdapat lebih daripada mereka. Kami melihat bahawa purata masa tindak balas pelayan adalah stabil. Kami melihat bahawa pada replika kami mempunyai transaksi jangka panjang yang berjalan selama 2 jam. Kami melihat operasi senyap autovakum, yang memproses garis mati. Dan semuanya baik-baik saja dengan kami.
Khususnya, mengikut plat yang diuji, kami terus mengemas kini baki akaun di sana. Dan kami juga mempunyai masa tindak balas yang stabil untuk permintaan, penggunaan sumber yang stabil. Semuanya baik-baik saja dengan kami.
Segala-galanya baik-baik saja sehinggalah saat laporan ini mula dibalas kerana konflik dengan replikasi. Dan mereka melepaskan tembakan secara berkala.
Kami pergi ke dalam talian dan mula membaca mengapa ini berlaku. Dan kami mencari penyelesaian.
Penyelesaian pertama ialah meningkatkan kependaman replikasi. Kami tahu bahawa laporan kami berjalan selama 3 jam. Kami menetapkan kelewatan replikasi kepada 3 jam. Kami melancarkan segala-galanya, tetapi kami masih terus menghadapi masalah dengan laporan yang kadangkala dibatalkan.
Kami mahu semuanya sempurna. Kami mendaki lebih jauh. Dan kami menemui tetapan yang menarik di Internet - hot_standby_feedback. Mari hidupkan. Hot_standby_feedback membolehkan kami menahan autovakum pada Master. Oleh itu, kami menyingkirkan sepenuhnya konflik replikasi. Dan semuanya berfungsi dengan baik untuk kami dengan laporan.
Dan apa yang berlaku dengan pelayan Master pada masa ini? Dan kami menghadapi masalah sepenuhnya dengan pelayan Master. Sekarang kita melihat graf apabila saya mempunyai kedua-dua tetapan ini didayakan. Dan kami melihat bahawa sesi pada replika kami entah bagaimana mula mempengaruhi keadaan pada pelayan Master. Dia mempunyai kesan kerana dia menjeda autovakum, yang membersihkan garis mati. Saiz meja kami telah melonjak lagi. Purata masa pelaksanaan pertanyaan merentas seluruh pangkalan data juga melonjak. Autovakum mengetatkan sedikit.
Secara khusus, dari plat kami, kami melihat bahawa kemas kini data padanya juga melonjak ke langit. Penggunaan CPU juga meningkat dengan ketara. Kami sekali lagi melalui sebilangan besar talian mati dan tidak berguna. Dan masa tindak balas untuk tanda ini dan bilangan urus niaga telah menurun.
Apakah rupanya jika kita tidak tahu apa yang saya perkatakan sebelum ini?
- Kami mula mencari masalah. Jika kami menghadapi masalah pada bahagian pertama, kami tahu bahawa ini mungkin disebabkan oleh transaksi yang lama dan pergi ke Master. Kami mempunyai masalah pada Guru. Sosej dia. Ia menjadi panas, Purata Bebannya adalah kira-kira seratus.
- Permintaan di sana adalah perlahan, tetapi kami tidak melihat sebarang transaksi yang berjalan lama di sana. Dan kami tidak faham apa masalahnya. Kami tidak faham di mana hendak mencari.
- Kami menyemak peralatan pelayan. Mungkin serbuan kami terhempas. Mungkin memory stick kita hangus. Ya, apa sahaja boleh berlaku. Tetapi tidak, pelayan baru, semuanya berfungsi dengan baik.
- Semua orang sedang berjalan: pentadbir, pembangun dan pengarah. Tiada apa yang membantu.
- Dan pada satu ketika semuanya tiba-tiba mula membetulkan dirinya sendiri.
Pada masa ini, permintaan pada replika kami telah diproses dan ditinggalkan. Kami menerima laporan itu. Bisnes tetap senang. Seperti yang anda lihat, tanda kami telah berkembang semula dan tidak akan mengecut. Pada graf dengan sesi, saya meninggalkan sekeping urus niaga yang panjang ini daripada replika supaya anda boleh menganggarkan tempoh masa yang diperlukan sehingga keadaan menjadi stabil.
Sesi sudah tamat. Dan hanya selepas beberapa lama pelayan datang lebih kurang teratur. Dan purata masa tindak balas untuk permintaan pada pelayan Master kembali normal. Kerana, akhirnya, autovakum mempunyai peluang untuk membersihkan dan menandakan garis mati ini. Dan dia mula melakukan tugasnya. Dan seberapa cepat dia melakukannya, begitu cepat kita akan mengaturnya.
Menurut tablet yang diuji, di mana kami mengemas kini baki akaun, kami melihat gambar yang sama. Purata masa kemas kini akaun juga beransur-ansur normal. Sumber yang digunakan oleh pemproses juga berkurangan. Dan bilangan urus niaga sesaat kembali normal. Tetapi sekali lagi kami kembali normal, tidak sama seperti sebelum kemalangan.
Walau apa pun, kami mendapat pengeluaran prestasi, seperti dalam kes pertama, sebanyak satu setengah hingga dua kali ganda, dan kadangkala lebih.
Kami nampaknya telah melakukan semuanya dengan betul. Agihkan beban. Peralatan tidak terbiar. Kami membahagikan permintaan mengikut fikiran kami, tetapi masih semuanya menjadi buruk.
- Jangan dayakan hot_standby_feedback? Ya, tidak disyorkan untuk menghidupkannya tanpa alasan yang kukuh. Kerana twist ini secara langsung mempengaruhi pelayan Master dan menggantung operasi autovakum di sana. Dengan mendayakannya pada beberapa replika dan melupakannya, anda boleh membunuh Master dan mendapat masalah besar dengan aplikasi.
- Tingkatkan max_standby_streaming_delay? Ya, untuk laporan ini adalah benar. Jika anda mempunyai laporan tiga jam dan anda tidak mahu laporan itu ranap disebabkan konflik replikasi, maka hanya perlu meningkatkan kelewatan. Laporan jangka panjang tidak memerlukan data yang telah tiba dalam pangkalan data sekarang. Jika anda memilikinya selama tiga jam, maka anda menjalankannya untuk beberapa tempoh data lama. Dan bagi anda, sama ada terdapat kelewatan tiga jam atau kelewatan enam jam tidak akan membawa apa-apa perbezaan, tetapi anda akan menerima laporan secara konsisten dan tidak akan menghadapi sebarang masalah dengan laporan tersebut jatuh.
- Sememangnya, anda perlu mengawal sesi panjang pada replika, terutamanya jika anda memutuskan untuk mendayakan hot_standby_feedback pada replika. Kerana apa sahaja boleh berlaku. Kami memberikan replika ini kepada pembangun supaya dia boleh menguji pertanyaan. Dia menulis permintaan gila. Dia melancarkannya dan pergi untuk minum teh, dan kami mendapat Guru yang mantap. Atau mungkin kita meletakkan aplikasi yang salah di sana. Situasi adalah pelbagai. Sesi mengenai replika mesti dipantau dengan teliti seperti pada Master.
- Dan jika anda mempunyai pertanyaan yang cepat dan panjang mengenai replika, maka dalam kes ini adalah lebih baik untuk memisahkannya untuk mengagihkan beban. Ini ialah pautan ke streaming_delay. Untuk yang pantas, miliki satu replika dengan kelewatan replikasi yang kecil. Untuk permintaan pelaporan yang berjalan lama, sediakan replika yang boleh ketinggalan selama 6 jam atau sehari. Ini adalah keadaan normal sepenuhnya.
Kami menghapuskan akibat dengan cara yang sama:
- Kami dapati meja kembung.
- Dan kami memampatkannya dengan alat yang paling mudah yang sesuai dengan kami.
Kisah kedua berakhir di sini. Mari kita beralih kepada cerita ketiga.
Juga agak biasa bagi kita di mana kita melakukan penghijrahan.
- Sebarang produk perisian sedang berkembang. Keperluan untuknya berubah. Walau apa pun, kami mahu membangunkan. Dan kebetulan kami perlu mengemas kini data dalam jadual, iaitu untuk menjalankan kemas kini dari segi penghijrahan kami untuk fungsi baharu yang kami perkenalkan sebagai sebahagian daripada pembangunan kami.
- Format data lama tidak memuaskan. Katakan kita kini beralih ke jadual kedua, di mana saya mempunyai transaksi pada akaun ini. Dan katakan bahawa mereka berada dalam rubel, dan kami memutuskan untuk meningkatkan ketepatan dan melakukannya dalam kopecks. Dan untuk ini kita perlu membuat kemas kini: darabkan medan dengan jumlah transaksi sebanyak seratus.
- Dalam dunia hari ini, kami menggunakan alat kawalan versi pangkalan data automatik. Katakan . Kami mendaftarkan penghijrahan kami di sana. Kami mengujinya pada asas ujian kami. Semuanya baik-baik sahaja. Kemas kini sedang berjalan. Ia menyekat kerja untuk seketika, tetapi kami mendapat data yang dikemas kini. Dan kami boleh melancarkan fungsi baharu mengenai perkara ini. Semuanya telah diuji dan diperiksa. Semuanya telah disahkan.
- Kami menjalankan kerja yang dirancang dan melakukan penghijrahan.
Berikut ialah penghijrahan dengan kemas kini yang dibentangkan di hadapan anda. Oleh kerana ini adalah urus niaga akaun saya, platnya ialah 15 GB. Dan kerana kami mengemas kini setiap baris, kami menggandakan saiz jadual dengan kemas kini, kerana kami menulis semula setiap baris.
Semasa penghijrahan, kami tidak dapat berbuat apa-apa dengan plat ini, kerana semua permintaan kepadanya telah beratur dan menunggu sehingga kemas kini ini selesai. Tetapi di sini saya ingin menarik perhatian anda kepada nombor yang berada pada paksi menegak. Iaitu, kami mempunyai purata masa permintaan sebelum penghijrahan kira-kira 5 milisaat dan beban pemproses, bilangan operasi blok untuk membaca memori cakera adalah kurang daripada 7,5.
Kami melakukan penghijrahan dan mendapat masalah lagi.
Penghijrahan itu berjaya, tetapi:
- Fungsi lama kini mengambil masa yang lebih lama untuk disiapkan.
- Meja itu membesar semula.
- Beban pada pelayan sekali lagi menjadi lebih besar daripada sebelumnya.
- Dan, sudah tentu, kami masih memikirkan fungsi yang berfungsi dengan baik, kami telah memperbaikinya sedikit.
Dan ini sekali lagi kembung, yang sekali lagi merosakkan hidup kita.
Di sini saya menunjukkan bahawa jadual, seperti dua kes sebelumnya, tidak akan kembali kepada saiz sebelumnya. Purata beban pelayan nampaknya mencukupi.
Dan jika kita beralih kepada jadual dengan akaun, kita akan melihat bahawa purata masa permintaan telah berganda untuk jadual ini. Beban pada pemproses dan bilangan baris yang disusun dalam ingatan melonjak melebihi 7,5, tetapi lebih rendah. Dan ia melonjak 2 kali dalam kes pemproses, 1,5 kali dalam kes operasi blok, iaitu kami mendapat kemerosotan dalam prestasi pelayan. Dan akibatnya - kemerosotan prestasi aplikasi kami. Pada masa yang sama, bilangan panggilan kekal lebih kurang pada tahap yang sama.
Dan perkara utama di sini adalah untuk memahami cara melakukan migrasi sedemikian dengan betul. Dan mereka perlu dilakukan. Kami melakukan migrasi ini dengan cukup konsisten.
- Penghijrahan besar seperti itu tidak berlaku secara automatik. Mereka mesti sentiasa terkawal.
- Pengawasan oleh orang yang berilmu diperlukan. Jika anda mempunyai DBA dalam pasukan anda, maka biarkan DBA melakukannya. Tugas dia. Jika tidak, maka biarkan orang yang paling berpengalaman melakukannya, yang tahu cara bekerja dengan pangkalan data.
- Skema pangkalan data baharu, walaupun kami mengemas kini satu lajur, kami sentiasa menyediakan secara berperingkat, iaitu lebih awal sebelum versi baharu aplikasi dilancarkan:
- Medan baharu ditambahkan di mana kami akan merekodkan data yang dikemas kini.
- Kami memindahkan data dari medan lama ke medan baru dalam bahagian kecil. Mengapa kita melakukan ini? Pertama, kami sentiasa mengawal proses proses ini. Kami tahu bahawa kami telah memindahkan begitu banyak kumpulan dan kami mempunyai banyak lagi yang tinggal.
- Dan kesan positif kedua ialah antara setiap kumpulan sedemikian kami menutup transaksi, membuka yang baru, dan ini membolehkan autovakum berfungsi mengikut plat, tandakan garisan mati untuk digunakan semula.
- Untuk baris yang akan muncul semasa aplikasi sedang berjalan (kami masih menjalankan aplikasi lama), kami menambah pencetus yang menulis nilai baharu ke medan baharu. Dalam kes kami, ini adalah pendaraban dengan seratus nilai lama.
- Jika kami benar-benar degil dan mahu medan yang sama, maka setelah selesai semua migrasi dan sebelum melancarkan versi baharu aplikasi, kami hanya menamakan semula medan tersebut. Yang lama diberi beberapa nama ciptaan, dan medan baharu dinamakan semula kepada yang lama.
- Dan hanya selepas itu kami melancarkan versi baharu aplikasi.
Dan pada masa yang sama kita tidak akan mendapat kembung dan tidak akan menderita dari segi prestasi.
Di sinilah cerita ketiga berakhir.
Dan kini lebih terperinci tentang alat yang saya nyatakan dalam cerita pertama.
Sebelum mencari bloat, anda mesti memasang sambungan .
Supaya anda tidak perlu mengemukakan pertanyaan, kami telah pun menulis pertanyaan ini dalam kerja kami. Anda boleh menggunakannya. Terdapat dua permintaan di sini.
- Yang pertama mengambil masa yang agak lama untuk berfungsi, tetapi ia akan menunjukkan kepada anda nilai bloat yang tepat dari jadual.
- Yang kedua berfungsi lebih cepat dan sangat berkesan apabila anda perlu cepat menilai sama ada terdapat kembung atau tidak mengikut jadual. Dan anda juga harus faham bahawa bloat sentiasa ada dalam jadual Postgres. Ini adalah ciri model MVCCnya.
- Dan 20% kembung adalah perkara biasa untuk jadual dalam kebanyakan kes. Iaitu, anda tidak perlu risau dan memampatkan jadual ini.
Kami memikirkan cara untuk mengenal pasti jadual yang bengkak dengan data yang tidak berguna.
Sekarang tentang cara membetulkan kembung:
- Jika kita mempunyai tablet kecil dan cakera yang baik, iaitu, pada tablet sehingga gigabait, sangat mungkin untuk menggunakan VACUUM FULL. Dia akan mengambil kunci eksklusif daripada anda di atas meja selama beberapa saat dan okay, tetapi dia akan melakukan segala-galanya dengan cepat dan keras. Apakah yang dilakukan oleh VACUUM FULL? Ia memerlukan kunci eksklusif pada meja dan menulis semula baris langsung daripada jadual lama ke dalam jadual baharu. Dan pada akhirnya dia menggantikan mereka. Ia memadam fail lama dan menggantikan yang lama dengan yang baru. Tetapi untuk tempoh kerjanya, ia memerlukan kunci eksklusif di atas meja. Ini bermakna anda tidak boleh melakukan apa-apa dengan jadual ini: tidak menulis kepadanya, atau membacanya, atau mengubah suainya. Dan VACUUM FULL memerlukan ruang cakera tambahan untuk menulis data.
- Alat seterusnya . Pada prinsipnya, ia sangat serupa dengan VACUUM FULL, kerana ia juga menulis semula data dari fail lama kepada yang baru dan menggantikannya dalam jadual. Tetapi pada masa yang sama, ia tidak mengambil kunci eksklusif di atas meja pada permulaan kerjanya, tetapi hanya mengambilnya pada masa ia sudah mempunyai data sedia untuk menggantikan fail. Keperluan sumber cakeranya adalah serupa dengan VACUUM FULL. Anda memerlukan ruang cakera tambahan, dan ini kadangkala kritikal jika anda mempunyai jadual terabait. Dan ia agak lapar pemproses kerana ia berfungsi secara aktif dengan I/O.
- Utiliti ketiga ialah . Ia lebih berhati-hati dengan sumber kerana ia berfungsi mengikut prinsip yang sedikit berbeza. Idea utama pgcompacttable ialah ia mengalihkan semua baris langsung ke permulaan jadual menggunakan kemas kini dalam jadual. Dan kemudian ia menjalankan vakum di atas meja ini, kerana kita tahu bahawa kita mempunyai baris hidup di permulaan dan baris mati di penghujung. Dan vakum itu sendiri memotong ekor ini, iaitu ia tidak memerlukan banyak ruang cakera tambahan. Dan pada masa yang sama, ia masih boleh diperah dari segi sumber.
Semuanya dengan alatan.
Jika anda mendapati topik bloat menarik dari segi menyelidiki lebih dalam, berikut adalah beberapa pautan berguna:
- - Ini adalah laporan daripada rakan sekerja saya. Ia adalah umum tentang ke mana ruang Postgres pergi semasa kerja dan kehidupannya. Dan terdapat bahagian teknikal yang sangat besar dan terperinci untuk pentadbir pangkalan data tentang kembung.
- β ini adalah pautan ke repositori kami, di mana kami menyimpan sekumpulan skrip berguna untuk menyemak keadaan pangkalan data. Di sana anda boleh mencari skrip untuk mencari bloat.
- ΠΈ pautan ke alat yang akan membantu anda mengecilkan tanda.
- β ini adalah siaran daripada rakan sekerja saya. Di sana dia secara serius dan teknikal menganalisis bloat secara terperinci pada tahap yang hampir dengan pentadbir.
Saya cuba lebih banyak lagi untuk menunjukkan kisah seram untuk pembangun, kerana mereka adalah pelanggan langsung kami bagi pangkalan data dan mesti memahami apa dan tindakan yang membawa kepada. Saya harap saya berjaya. Terima kasih kerana memberi perhatian!
soalan
Terima kasih atas laporan itu! Anda bercakap tentang bagaimana anda boleh mengenal pasti masalah. Bagaimana mereka boleh diberi amaran? Iaitu, saya mempunyai situasi di mana permintaan digantung bukan sahaja kerana mereka mengakses beberapa perkhidmatan luaran. Ini hanyalah beberapa gabungan liar. Terdapat beberapa permintaan kecil dan tidak berbahaya yang bertahan selama sehari, dan kemudian mula melakukan beberapa perkara karut. Iaitu, sangat serupa dengan apa yang anda huraikan. Bagaimana untuk menjejaki ini? Duduk dan sentiasa perhatikan permintaan mana yang tersekat? Bagaimana ini boleh dicegah?
Dalam kes ini, ini adalah tugas untuk pentadbir syarikat anda, tidak semestinya untuk DBA.
Saya seorang pentadbir.
PostgreSQL mempunyai paparan yang dipanggil pg_stat_activity yang menunjukkan pertanyaan berjuntai. Dan anda boleh melihat berapa lama ia tergantung di sana.
Adakah saya perlu masuk dan melihat setiap 5 minit?
Sediakan cron dan semak. Jika anda mempunyai permintaan jangka panjang, tulis surat dan itu sahaja. Iaitu, anda tidak perlu melihat dengan mata anda, ia boleh automatik. Anda akan menerima surat, anda bertindak balas terhadapnya. Atau anda boleh menembak secara automatik.
Adakah terdapat sebab yang jelas mengapa ini berlaku?
Saya telah menyenaraikan beberapa. Contoh lain yang lebih kompleks. Dan boleh ada perbualan untuk masa yang lama.
Terima kasih atas laporan itu! Saya ingin menjelaskan tentang utiliti pg_repack. Jika dia tidak melakukan kunci eksklusif, maka...
Dia melakukan kunci eksklusif.
... maka saya berpotensi kehilangan data. Sekiranya permohonan saya tidak merakam apa-apa pada masa ini?
Tidak, ia berfungsi dengan lancar dengan jadual, iaitu pg_repack terlebih dahulu memindahkan semua talian langsung yang wujud. Sememangnya, beberapa jenis kemasukan ke dalam jadual berlaku di sana. Dia hanya membuang ekor kuda ini.
Iaitu, dia sebenarnya melakukannya pada akhirnya?
Akhirnya, dia mengambil kunci eksklusif untuk menukar fail ini.
Adakah ia lebih pantas daripada PENUH VACUUM?
VACUUM FULL, sebaik sahaja ia bermula, segera mengambil kunci eksklusif. Dan sehingga dia melakukan segala-galanya, dia tidak akan melepaskannya. Dan pg_repack mengambil kunci eksklusif hanya pada masa penggantian fail. Pada masa ini anda tidak akan menulis di sana, tetapi data tidak akan hilang, semuanya akan baik-baik saja.
hello! Anda bercakap tentang pengendalian vakum kereta. Terdapat graf dengan sel rakaman merah, kuning dan hijau. Iaitu, yang kuning - dia menandakannya sebagai dipadam. Dan sebagai hasilnya, sesuatu yang baru boleh ditulis ke dalamnya?
ya. Postgres tidak memadamkan baris. Dia mempunyai kekhususan sedemikian. Jika kami mengemas kini baris, kami menandai baris lama sebagai dipadamkan. Id transaksi yang menukar baris ini muncul di sana, dan kami menulis baris baharu. Dan kami mempunyai sesi yang berpotensi membacanya. Pada satu ketika mereka menjadi agak tua. Dan intipati bagaimana autovakum berfungsi ialah ia melalui garisan ini dan menandakannya sebagai tidak perlu. Dan anda boleh menulis ganti data di sana.
Saya faham. Tetapi bukan itu persoalannya. saya tak habiskan. Katakan kita mempunyai meja. Ia mempunyai bidang saiz berubah-ubah. Dan jika saya cuba memasukkan sesuatu yang baru, ia mungkin tidak sesuai dengan sel lama.
Tidak, dalam apa jua keadaan keseluruhan baris dikemas kini di sana. Postgres mempunyai dua model storan data. Ia memilih daripada jenis data. Terdapat data yang disimpan terus dalam jadual, dan terdapat juga data tos. Ini adalah sejumlah besar data: teks, json. Mereka disimpan dalam pinggan berasingan. Dan menurut tablet ini, cerita yang sama dengan kembung berlaku, iaitu semuanya sama. Mereka hanya disenaraikan secara berasingan.
Terima kasih atas laporan itu! Adakah boleh diterima menggunakan pertanyaan tamat masa pernyataan untuk mengehadkan tempoh?
Sangat boleh diterima. Kami menggunakan ini di mana-mana. Dan kerana kami tidak mempunyai perkhidmatan kami sendiri, kami menyediakan sokongan jauh, kami mempunyai pelbagai pelanggan. Dan semua orang berpuas hati dengan ini. Iaitu, kami mempunyai tugas cron yang menyemak. Tempoh sesi hanya dipersetujui dengan pelanggan, sebelum itu kami tidak bersetuju. Boleh jadi seminit, boleh jadi 10 minit. Ia bergantung kepada beban pada pangkalan dan tujuannya. Tetapi kita semua menggunakan pg_stat_activity.
Terima kasih atas laporan itu! Saya cuba menggunakan laporan anda pada permohonan saya. Dan nampaknya kami memulakan urus niaga di mana-mana, dan dengan jelas menyelesaikannya di mana-mana. Jika terdapat beberapa pengecualian, maka rollback masih berlaku. Dan kemudian saya mula berfikir. Lagipun, transaksi mungkin tidak bermula secara eksplisit. Ini mungkin petunjuk kepada gadis itu. Jika saya hanya mengemas kini rekod, adakah transaksi akan bermula dalam PostgreSQL dan hanya selesai apabila sambungan diputuskan?
Jika anda bercakap sekarang tentang tahap aplikasi, maka ia bergantung pada pemacu yang anda gunakan, pada ORM yang sedang digunakan. Terdapat banyak tetapan di sana. Jika anda telah mengaktifkan autocommit didayakan, maka transaksi bermula di sana dan ditutup serta-merta.
Iaitu, ia ditutup serta-merta selepas kemas kini?
Ia bergantung pada tetapan. Saya menamakan satu tetapan. Ini adalah auto commit on. Ia agak biasa. Jika ia didayakan, maka transaksi telah dibuka dan ditutup. Melainkan anda secara eksplisit mengatakan "mulakan transaksi" dan "tamatkan transaksi", tetapi hanya melancarkan permintaan ke dalam sesi.
hello! Terima kasih atas laporan itu! Bayangkan kita mempunyai pangkalan data yang bengkak dan bengkak dan kemudian ruang pada pelayan itu habis. Adakah terdapat sebarang alat untuk membetulkan keadaan ini?
Ruang pada pelayan perlu dipantau dengan betul.
Contohnya, DBA pergi minum teh, berada di resort, dsb.
Apabila sistem fail dicipta, sekurang-kurangnya beberapa jenis ruang sandaran dibuat di mana data tidak ditulis.
Bagaimana jika ia benar-benar di bawah sifar?
Di sana ia dipanggil ruang tersimpan, iaitu ia boleh dibebaskan dan bergantung pada seberapa besar ia dicipta, anda mendapat ruang kosong. Secara lalai saya tidak tahu jumlahnya. Dan dalam kes lain, hantar cakera supaya anda mempunyai ruang untuk melakukan operasi rekonstruktif. Anda boleh memadam beberapa jadual yang anda dijamin tidak perlukan.
Adakah terdapat alat lain?
Ia sentiasa buatan tangan. Dan secara tempatan ia menjadi jelas apa yang terbaik untuk dilakukan di sana, kerana sesetengah data adalah kritikal dan ada yang tidak kritikal. Dan untuk setiap pangkalan data dan aplikasi yang berfungsi dengannya, ia bergantung pada perniagaan. Ia sentiasa diputuskan secara tempatan.
Terima kasih atas laporan itu! Saya ada dua soalan. Mula-mula, anda menunjukkan slaid yang menunjukkan bahawa apabila urus niaga tersekat, kedua-dua saiz ruang jadual dan saiz indeks berkembang. Dan selanjutnya pada laporan itu terdapat sekumpulan utiliti yang membungkus tablet. Bagaimana dengan indeks?
Mereka membungkusnya juga.
Tetapi vakum tidak menjejaskan indeks?
Sesetengah berfungsi dengan indeks. Contohnya, pg_rapack, pgcompacttable. Vakum mencipta semula indeks dan menjejaskannya. Dengan VACUUM FULL ideanya adalah untuk menulis ganti segala-galanya, iaitu ia berfungsi dengan semua orang.
Dan soalan kedua. Saya tidak faham mengapa laporan mengenai replika sangat bergantung pada replikasi itu sendiri. Nampaknya kepada saya laporan dibaca, dan replikasi ditulis.
Apakah yang menyebabkan konflik replikasi? Kami mempunyai Sarjana tentang proses yang berlaku. Kami mempunyai vakum kereta berlaku. Apakah yang sebenarnya dilakukan oleh autovakum? Dia memotong beberapa baris lama. Jika pada masa ini kami mempunyai permintaan pada replika yang membaca baris lama ini, dan pada Master situasi berlaku bahawa autovakum menandakan baris ini sebagai mungkin untuk ditulis ganti, maka kami menimpanya. Dan kami menerima paket data, apabila kami perlu menulis semula baris tersebut yang diperlukan oleh permintaan pada replika, proses replikasi akan menunggu tamat masa yang anda konfigurasikan. Dan kemudian PostgreSQL akan memutuskan perkara yang lebih penting untuknya. Dan replikasi adalah lebih penting baginya daripada permintaan, dan dia akan menembak permintaan untuk membuat perubahan ini pada replika.
Andrey, saya ada soalan. Graf indah yang anda tunjukkan semasa pembentangan ini, adakah ini hasil kerja sejenis utiliti anda? Bagaimanakah graf dibuat?
Ini adalah perkhidmatan .
Adakah ini produk komersial?
ya. Ini adalah produk komersial.
Sumber: www.habr.com