Aku saranake sampeyan maca transkrip laporan saka awal 2016 dening Andrey Salnikov "Kesalahan khas ing aplikasi sing nyebabake kembung ing postgresql"
Ing laporan iki, aku bakal nganalisa kesalahan utama ing aplikasi sing muncul ing tahap ngrancang lan nulis kode aplikasi. Lan aku mung bakal njupuk kesalahan sing nyebabake kembung ing Postgresql. Minangka aturan, iki minangka wiwitan pungkasan kinerja sistem sampeyan kanthi sakabehe, sanajan ora ana prasyarat sing katon.
Sugeng rawuh kabeh! Laporan iki ora teknis kaya laporan sadurunge saka kancaku. Laporan iki utamane ditujokake kanggo pangembang sistem backend amarga kita duwe klien sing cukup akeh. Lan kabeh padha nggawe kesalahan sing padha. Aku bakal pitutur marang kowe bab wong-wong mau. Aku bakal nerangake apa fatal lan ala kesalahan iki mimpin kanggo.
Yagene ana kesalahan? Iki ditindakake kanthi rong alasan: kanthi acak, bisa uga bakal ditindakake lan amarga ora ngerti sawetara mekanisme sing kedadeyan ing tingkat antarane database lan aplikasi, uga ing database kasebut dhewe.
Aku bakal menehi telung conto kanthi gambar sing nggegirisi babagan kedadeyan sing ala. Aku bakal ngandhani sampeyan babagan mekanisme sing kedadeyan ing kana. Lan carane menehi hasil karo wong-wong mau, nalika padha kedaden, lan apa cara nyegah kanggo nggunakake kanggo nyegah kesalahane. Aku bakal pitutur marang kowe babagan alat bantu lan nyedhiyakake pranala sing migunani.
Aku digunakake database test ngendi aku loro tabel. Siji piring karo akun pelanggan, liyane karo transaksi ing akun kasebut. Lan kanthi sawetara frekuensi kita nganyari imbangan ing akun kasebut.
Data awal piring: cukup cilik, 2 MB. Wektu respon kanggo database lan khusus kanggo tandha uga apik banget. Lan beban sing cukup apik - 2 operasi per detik miturut piring.
Lan liwat laporan iki aku bakal nuduhake grafik supaya sampeyan bisa ngerti kanthi jelas apa sing kedadeyan. Bakal mesthi ana 2 slide kanthi grafik. Slide pisanan yaiku kedadeyan umum ing server.
Lan ing kahanan iki, kita weruh yen kita pancene duwe tandha cilik. Indeks cilik ing 2 MB. Iki minangka grafik pisanan ing sisih kiwa.
Wektu respon rata-rata ing server uga stabil lan cendhak. Iki minangka grafik sisih tengen ndhuwur.
Grafik kiwa ngisor nuduhake transaksi paling dawa. Kita weruh yen transaksi rampung kanthi cepet. Lan autovacuum durung bisa digunakake ing kene, amarga iki minangka tes wiwitan. Iku bakal terus bisa lan bakal migunani kanggo kita.
Muter kapindho bakal tansah darmabakti kanggo piring sing dites. Ing kahanan iki, kita terus-terusan nganyari saldo akun klien. Lan kita weruh manawa wektu respon rata-rata kanggo operasi nganyari cukup apik, kurang saka milidetik. Kita weruh manawa sumber daya prosesor (iki grafik sisih tengen ndhuwur) uga dikonsumsi kanthi rata lan cukup cilik.
Grafik sisih tengen ngisor nuduhake jumlah operasi lan memori disk sing kita lakoni kanggo nggoleki garis sing dikarepake sadurunge nganyari. Lan jumlah operasi miturut tandha yaiku 2 per detik, kaya sing dakkandhakake ing wiwitan.
Lan saiki kita duwe tragedi. Kanggo sawetara alesan ana transaksi dawa lali. Alasan biasane kabeh banal:
- Salah siji sing paling umum yaiku kita miwiti ngakses layanan eksternal ing kode aplikasi. Lan layanan iki ora mangsuli kita. Yaiku, kita mbukak transaksi, nggawe pangowahan ing database lan lunga saka aplikasi kanggo maca surat utawa layanan liyane ing infrastruktur kita, lan sakperangan alesan ora nanggapi kita. Lan sesi kita macet ing negara sing ora dingerteni kapan bakal dirampungake.
- Kahanan kapindho yaiku nalika ana pangecualian ing kode kita sakperangan alesan. Lan kajaba kita ora ngolah penutupan transaksi. Lan kita rampung karo sesi gantung karo transaksi mbukak.
- Lan sing pungkasan uga kasus sing cukup umum. Iki kode kualitas kurang. Sawetara kerangka mbukak transaksi. Iku macet, lan sampeyan bisa uga ora ngerti ing aplikasi sing wis hanging.
Tumindak kaya mangkono iku tumuju ing ngendi?
Kanggo titik sing tabel lan indeks kita wiwiti swell dramatically. Iki persis efek kembung sing padha. Kanggo database, iki bakal tegese wektu respon database bakal tambah banget lan beban ing server database bakal nambah. Lan minangka asil, aplikasi kita bakal nandhang sangsara. Amarga yen sampeyan ngentekake 10 milidetik ing kode sampeyan kanggo panjaluk menyang database, 10 milidetik ing logika sampeyan, mula fungsi sampeyan butuh 20 milidetik kanggo ngrampungake. Lan saiki kahananmu bakal sedhih banget.
Lan ayo ndeleng apa sing kedadeyan. Grafik sisih kiwa ngisor nuduhake yen kita duwe transaksi sing dawa. Lan yen kita ndeleng grafik kiwa ndhuwur, kita weruh yen ukuran meja kita dumadakan mlumpat saka rong megabyte dadi 300 megabyte. Ing wektu sing padha, jumlah data ing tabel ora owah, yaiku ana jumlah sampah sing cukup akeh.
Kahanan umum babagan wektu nanggepi server rata-rata uga wis diganti dening sawetara urutan gedhene. Yaiku, kabeh panjaluk ing server wiwit ilang. Lan ing wektu sing padha, pangolahan Postgres internal diluncurake kanthi bentuk autovacuum, sing nyoba nindakake apa wae lan nggunakake sumber daya.
Apa sing kedadeyan karo tandha kita? Semono uga. Wektu nanggepi rata-rata miturut tandha wis mlumpat munggah sawetara pesenan magnitudo. Khusus babagan sumber daya sing dikonsumsi, kita weruh manawa beban prosesor saya tambah akeh. Iki minangka grafik sisih tengen ndhuwur. Lan wis tambah amarga prosesor kudu ngurutake akeh garis sing ora ana guna kanggo nggoleki sing dibutuhake. Iki grafik sisih tengen ngisor. Lan minangka asil, nomer telpon saben detik wiwit mudhun banget, amarga database ora duwe wektu kanggo proses nomer padha panjalukan.
Kita kudu bali menyang urip. Kita online lan ngerteni manawa transaksi sing dawa nyebabake masalah. Kita nemokake lan mateni transaksi iki. Lan kabeh dadi normal kanggo kita. Kabeh tumindak kaya sing dikarepake.
We calmed mudhun, nanging sawise sawetara wektu kita wiwiti sok dong mirsani sing aplikasi ora bisa digunakake ing cara sing padha sadurunge darurat. Panjaluk isih diproses luwih alon, lan luwih alon. Siji lan setengah nganti kaping pindho luwih alon ing contoku. Beban ing server uga luwih dhuwur tinimbang sadurunge kacilakan.
Lan pitakonan: "Apa sing kedadeyan ing pangkalan saiki?" Lan kahanan ing ngisor iki kedadeyan karo dhasar. Ing grafik transaksi sampeyan bisa ndeleng manawa wis mandheg lan ora ana transaksi jangka panjang. Nanging ukuran tandha fatally tambah sak Laka. Lan wiwit iku padha ora suda. Wektu rata-rata ing pangkalan wis stabil. Lan jawaban kasebut katon kanthi cepet kanthi cepet sing bisa ditampa. Autovacuum dadi luwih aktif lan wiwit nindakake soko karo tandha, amarga perlu sift liwat data liyane.
Khusus, miturut piring test karo akun, ing ngendi kita ngganti imbangan: wektu nanggepi panjalukan katon normal. Nanging ing kasunyatan iku siji lan setengah kaping luwih.
Lan saka beban ing prosesor, kita weruh manawa beban ing prosesor durung bali menyang nilai sing dibutuhake sadurunge kacilakan. Lan alasane ana ing grafik sisih tengen ngisor. Sampeyan bisa ndeleng sing jumlah tartamtu saka memori lagi digoleki ana. Yaiku, kanggo nemokake baris sing dibutuhake, kita mbuwang sumber daya server database nalika ngurutake data sing ora ana gunane. Jumlah transaksi per detik wis stabil.
Sakabèhé apik, nanging kahanan sing luwih elek tinimbang saiki. Mbusak degradasi database minangka akibat saka aplikasi kita sing bisa digunakake karo database iki.
Lan kanggo mangerteni apa sing kedadeyan ing kana, yen sampeyan ora ana ing laporan sadurunge, saiki ayo entuk teori sethithik. Teori babagan proses internal. Napa vakum mobil lan apa sing ditindakake?
Secara harfiah ringkes kanggo pangerten. Ing sawetara titik ing wektu kita duwe meja. Kita duwe larik ing meja. Garis iki bisa aktif, urip, lan apa sing kita butuhake saiki. Padha ditandhani ing ijo ing gambar. Lan ana garis mati sing wis digarap, wis dianyari, lan entri anyar wis katon ing wong-wong mau. Lan padha ditandhani sing lagi ora menarik kanggo database. Nanging ana ing meja amarga fitur Postgres.
Napa sampeyan butuh vakum mobil? Ing sawetara titik, autovacuum teka, ngakses database lan takon: "Mangga wenehi id transaksi paling tuwa sing saiki mbukak ing database." Database ngasilake id iki. Lan autovacuum, gumantung ing, diurutake liwat garis ing meja. Lan yen dheweke weruh yen sawetara garis diganti dening transaksi sing luwih lawas, mula dheweke duwe hak kanggo menehi tandha minangka garis sing bisa digunakake maneh ing mangsa ngarep kanthi nulis data anyar ing kana. Iki minangka proses latar mburi.
Ing wektu iki, kita terus nggarap database lan terus nggawe sawetara owah-owahan ing meja. Lan ing garis kasebut, sing bisa digunakake maneh, kita nulis data anyar. Lan kanthi mangkono kita entuk siklus, yaiku kabeh wektu sawetara garis lawas sing mati katon ana, tinimbang dheweke nulis garis anyar sing dibutuhake. Lan iki minangka kahanan normal kanggo PostgreSQL bisa digunakake.
Apa sing kedadeyan nalika kacilakan? Kepiye proses iki kedadeyan ing kana?
Kita duwe tandha ing sawetara kondisi, sawetara urip, sawetara garis mati. Vakum mobil wis teka. Dheweke takon database apa transaksi paling tuwa kita lan apa id sawijining. Aku nampa id iki, sing bisa dadi pirang-pirang jam kepungkur, bisa uga sepuluh menit kepungkur. Iku gumantung carane abot mbukak ing database. Lan dheweke nggoleki garis sing bisa ditandhani minangka digunakake maneh. Lan aku ora nemu garis kuwi ing meja kita.
Nanging ing wektu iki kita terus bisa karo meja. Kita nindakake soko ing, nganyari, ngganti data. Apa sing kudu ditindakake database ing wektu iki? Dheweke ora duwe pilihan nanging nambah garis anyar ing mburi meja sing wis ana. Lan kanthi mangkono ukuran meja kita wiwit swell.
Ing kasunyatan, kita kudu garis ijo kanggo bisa. Nanging sajrone masalah kasebut, ternyata persentase garis ijo sithik banget ing kabeh meja.
Lan nalika kita nglakokake pitakon, database kudu ngliwati kabeh baris: abang lan ijo, kanggo nemokake baris sing dikarepake. Lan efek kembung meja kanthi data sing ora ana gunane diarani "kembung", sing uga mangan ruang disk kita. Elinga, iku 2 MB, dadi 300 MB? Saiki ganti megabyte dadi gigabyte lan sampeyan bakal cepet ilang kabeh sumber daya disk.
Apa akibat sing bisa ditindakake kanggo kita?
- Ing conto, tabel lan indeks tansaya 150 kaping. Sawetara klien kita ngalami kasus sing luwih fatal nalika wiwit kehabisan ruang disk.
- Ukuran tabel dhewe ora bakal suda. Autovacuum ing sawetara kasus bisa ngethok buntut meja yen mung ana garis mati. Nanging amarga ana rotasi pancet, siji baris ijo bisa beku ing mburi lan ora dianyari, nalika kabeh liyane bakal ditulis mudhun nang endi wae ing awal piring. Nanging iki minangka acara sing ora mungkin yen meja sampeyan bakal nyuda ukurane, mula sampeyan ora ngarep-arep.
- Basis data kudu ngurutake pirang-pirang garis sing ora ana gunane. Lan kita mbuwang sumber daya disk, kita mbuwang sumber daya prosesor lan listrik.
- Lan iki langsung mengaruhi aplikasi kita, amarga yen ing wiwitan kita ngenteni 10 milidetik ing panyuwunan, 10 milidetik ing kode kita, banjur sajrone kacilakan, kita wiwit ngentekake detik kanggo panyuwunan lan 10 milidetik ing kode kasebut, yaiku urutan saka gedhene ing kinerja aplikasi suda. Lan nalika kacilakan iki ditanggulangi, kita wiwit nglampahi 20 milliseconds ing request, 10 milliseconds ing kode. Iki tegese kita isih mudhun siji setengah kaping ing produktivitas. Lan iki kabeh amarga siji transaksi sing beku, bisa uga amarga kesalahan kita.
- Lan pitakonan: "Kepiye carane bisa bali kabeh?" Supaya kabeh apik karo kita lan panjaluk teka kanthi cepet kaya sadurunge kacilakan.
Kanggo maksud iki ana siklus tartamtu saka karya sing dileksanakake.
Pisanan kita kudu nemokake tabel masalah sing kembung. Kita ngerti manawa ing sawetara tabel rekaman luwih aktif, ing liyane kurang aktif. Lan kanggo iki kita nggunakake extension . Kanthi nginstal ekstensi iki, sampeyan bisa nulis pitakon sing bakal mbantu sampeyan nemokake tabel sing cukup kembung.
Sawise sampeyan nemokake tabel kasebut, sampeyan kudu ngompres. Wis ana alat kanggo iki. Ing perusahaan kita nggunakake telung alat. Sing pertama yaiku VACUUM FULL sing dibangun. Dheweke kejem, kasar lan ora duwe welas asih, nanging kadhangkala migunani banget. ΠΈ - Iki minangka sarana pihak katelu kanggo compressing tabel. Lan padha nambani database luwih kasebut kanthi teliti,.
Padha digunakake gumantung apa sing luwih trep kanggo sampeyan. Nanging aku bakal ngandhani sampeyan babagan iki ing pungkasan. Sing utama yaiku ana telung alat. Ana akeh sing bisa dipilih.
Sawise kita mbenerake kabeh lan mesthekake yen kabeh wis apik, kita kudu ngerti carane nyegah kahanan iki ing mangsa ngarep:
- Bisa dicegah kanthi gampang. Sampeyan kudu ngawasi durasi sesi ing server Master. Sesi utamane mbebayani nalika nganggur ing negara transaksi. Iki sing mung mbukak transaksi, nindakake soko lan ninggalake, utawa mung Hung, ilang ing kode.
- Lan kanggo sampeyan, minangka pangembang, penting kanggo nyoba kode nalika kahanan kasebut muncul. Ora angel ditindakake. Iki bakal dadi mriksa migunani. Sampeyan bakal ngindhari akeh masalah "bocah" sing ana gandhengane karo transaksi sing dawa.
Ing grafik iki, aku pengin nuduhake sampeyan carane tandha lan prilaku database diganti sawise aku ngliwati tandha karo VACUUM FULL ing kasus iki. Iki dudu produksi kanggo aku.
Ukuran meja langsung bali menyang negara operasi normal saperangan megabyte. Iki ora mengaruhi wektu respon rata-rata kanggo server.
Nanging khusus kanggo tandha test kita, ngendi kita nganyari saldo akun, kita weruh yen wektu respon rata-rata kanggo panjalukan kanggo nganyari data ing tandha wis suda kanggo tingkat pra-darurat. Sumber daya sing digunakake prosesor kanggo ngrampungake panjalukan iki uga mudhun menyang tingkat pra-kacilakan. Lan grafik tengen ngisor nuduhake yen saiki kita nemokake persis garis sing kita butuhake langsung, tanpa ngliwati tumpukan garis mati sing ana sadurunge meja dikompres. Lan wektu panyuwunan rata-rata tetep ing tingkat sing padha. Nanging ing kene aku duwe kesalahan ing hardware.
Iki ngendi crita pisanan rampung. Iku sing paling umum. Lan kedaden kanggo kabeh wong, preduli saka pengalaman klien lan carane qualified programer. Cepet utawa mengko iki kedadeyan.
Crita kapindho, ing ngendi kita nyebarake beban lan ngoptimalake sumber daya server
- Kita wis diwasa lan dadi wong lanang sing serius. Lan kita ngerti manawa kita duwe replika lan luwih becik kita ngimbangi beban: nulis menyang Master, lan maca saka replika. Lan biasane kahanan iki muncul nalika kita pengin nyiapake sawetara laporan utawa ETL. Lan bisnis seneng banget babagan iki. Dheweke pancen pengin macem-macem laporan kanthi akeh analytics kompleks.
- Laporan mbutuhake pirang-pirang jam, amarga analitik rumit ora bisa diwilang ing milidetik. Kita, kaya wong sing wani, nulis kode. Ing aplikasi sisipan kita nggawe rekaman ing Master, lan nglakokake laporan ing replika.
- Distribusi beban.
- Kabeh dianggo sampurna. Kita pancen apikan.
Lan kaya apa kahanan iki? Khusus ing grafik kasebut, aku uga nambahake durasi transaksi saka replika kanggo durasi transaksi. Kabeh grafik liyane mung nuduhake server Master.
Ing wektu iki, papan laporan saya tambah akeh. Ana liyane saka wong-wong mau. Kita weruh manawa wektu respon server rata-rata stabil. Kita weruh yen ing replika kita duwe transaksi sing wis suwe nganti 2 jam. Kita ndeleng operasi sepi autovacuum, sing ngolah garis mati. Lan kabeh apik karo kita.
Khusus, miturut piring sing diuji, kita terus nganyari saldo akun ing kana. Lan kita uga duwe wektu respon stabil kanggo panjalukan, konsumsi sumber daya stabil. Kabeh apik karo kita.
Kabeh iku apik nganti wayahe laporan iki wiwit murub maneh amarga konflik karo replikasi. Lan padha murub maneh ing interval biasa.
Kita online lan miwiti maca kenapa iki kedadeyan. Lan kita nemokake solusi.
Solusi pisanan yaiku nambah latensi replikasi. Kita ngerti yen laporan kita mlaku sajrone 3 jam. Kita nyetel wektu tundha replikasi nganti 3 jam. Kita miwiti kabeh, nanging isih ana masalah karo laporan sing kadhangkala dibatalake.
Kita pengin kabeh dadi sampurna. We menek luwih. Lan kita nemokake setelan kelangan ing Internet - hot_standby_feedback. Ayo diuripake. Hot_standby_feedback ngidini kita nahan autovacuum ing Master. Mangkono, kita rampung nyingkirake konflik replikasi. Lan kabeh bisa uga kanggo kita karo laporan.
Lan apa sing kedadeyan karo server Master ing wektu iki? Lan kita ana masalah total karo server Master. Saiki kita ndeleng grafik nalika aku duwe loro setelan kasebut. Lan kita weruh yen sesi ing tiron kita piye wae wiwit mengaruhi kahanan ing server Master. Dheweke duwe efek amarga ngaso autovacuum, sing mbusak garis mati. Ukuran meja kita wis skyrocketed maneh. Wektu eksekusi query rata-rata ing kabeh database uga skyrocketed. Autovacuums tightened munggah sethitik.
Khusus, saka piring kita, kita weruh manawa nganyari data kasebut uga mlumpat menyang langit. Konsumsi CPU uga tambah akeh. We are maneh liwat nomer akeh mati, garis ora ana guna. Lan wektu nanggepi tandha iki lan jumlah transaksi wis mudhun.
Apa sing bakal katon yen kita ora ngerti apa sing dakkandhakake sadurunge?
- Kita miwiti nggoleki masalah. Yen kita nemoni masalah ing bagean pisanan, kita ngerti yen iki bisa uga amarga transaksi sing dawa lan menyang Master. Kita duwe masalah ing Master. Sosis dheweke. Panas, Rata-rata Muatan kira-kira satus.
- Panjaluk ana alon, nanging kita ora weruh transaksi long-mlaku ana. Lan kita ora ngerti apa sing kedadeyan. Kita ora ngerti ngendi arep nggoleki.
- Kita mriksa peralatan server. Mungkin serangan kita tubrukan. Mungkin memory stick kita kebakar. Ya, apa wae bisa kedadeyan. Nanging ora, server anyar, kabeh bisa digunakake kanthi becik.
- Kabeh wong mlaku: pangurus, pangembang lan direktur. Ora ana sing mbantu.
- Lan ing sawetara titik kabeh dumadakan wiwit mbenerake dhewe.
Ing wektu iki, panjalukan ing replika wis diproses lan ditinggalake. Kita nampa laporan kasebut. Bisnis isih seneng. Kaya sing sampeyan ngerteni, tandha kita wis tuwuh maneh lan ora bakal nyusut. Ing grafik karo sesi, aku ninggalake potongan saka transaksi dawa iki saka replika supaya sampeyan bisa ngira suwene wektu nganti kahanan stabil.
Sesi wis rampung. Lan mung sawise sawetara wektu server teka luwih utawa kurang supaya. Lan wektu respon rata-rata kanggo panjalukan ing server Master bali menyang normal. Amarga, pungkasane, autovacuum duwe kesempatan kanggo ngresiki lan menehi tandha garis mati kasebut. Lan dheweke wiwit nindakake pakaryane. Lan carane cepet dheweke nindakake, supaya cepet kita bakal njaluk supaya.
Miturut tablet sing dites, ing ngendi kita nganyari saldo akun, kita ndeleng persis gambar sing padha. Wektu nganyari akun rata-rata uga mboko sithik normal. Sumber daya sing dikonsumsi prosesor uga suda. Lan jumlah transaksi per detik bali menyang normal. Nanging maneh kita bali menyang normal, ora kaya sadurunge kacilakan.
Ing kasus apa wae, kita entuk drawdown kinerja, kaya ing kasus sing sepisanan, siji lan setengah nganti kaping pindho, lan kadhangkala luwih.
Kita koyone wis nindakake kabeh kanthi bener. Distribusi beban. Peralatan ora nganggur. Kita dibagi panjalukan miturut pikiran kita, nanging isih kabeh dadi ala.
- Aja ngaktifake hot_standby_feedback? Ya, ora dianjurake kanggo nguripake tanpa alasan sing kuwat. Amarga corak iki langsung mengaruhi server Master lan nundha operasi autovacuum ana. Kanthi ngaktifake sawetara replika lan dilalekake, sampeyan bisa mateni Master lan entuk masalah gedhe karo aplikasi kasebut.
- Tambah max_standby_streaming_delay? Ya, kanggo laporan iki bener. Yen sampeyan duwe laporan telung jam lan sampeyan ora pengin nabrak amarga konflik replikasi, banjur tambahake wektu tundha. Laporan jangka panjang ora mbutuhake data sing wis teka ing basis data saiki. Yen sampeyan duwe telung jam, sampeyan bakal mbukak kanggo sawetara periode data lawas. Lan kanggo sampeyan, apa ana wektu tundha telung jam utawa wektu tundha enem jam ora bakal nggawe prabΓ©dan, nanging sampeyan bakal nampa laporan terus-terusan lan ora bakal duwe masalah karo wong-wong mau tiba.
- Mesthi wae, sampeyan kudu ngontrol sesi dawa ing replika, utamane yen sampeyan arep ngaktifake hot_standby_feedback ing replika. Amarga apa wae bisa kedadeyan. Kita menehi replika iki kanggo pangembang supaya bisa nyoba pitakon. Dheweke nulis panjaluk edan. Dheweke mbukak lan banjur ngombe teh, lan kita entuk Guru sing wis mapan. Utawa Mungkin kita sijine aplikasi salah ing kono. Kahanane maneka warna. Sesi ing replika kudu dipantau kanthi ati-ati kaya ing Master.
- Lan yen sampeyan duwe pitakon cepet lan dawa babagan replika, banjur ing kasus iki luwih becik dibagi kanggo nyebarake beban. Iki link menyang streaming_delay. Kanggo sing cepet, duwe siji replika kanthi wektu tundha replikasi cilik. Kanggo panjalukan laporan sing dawa, duwe replika sing bisa telat 6 jam utawa sedina. Iki minangka kahanan sing normal.
Kita ngilangi akibat kanthi cara sing padha:
- Kita nemokake meja sing kembung.
- Lan kita kompres nganggo alat sing paling trep sing cocog karo kita.
Crita kapindho rampung ing kene. Ayo pindhah menyang crita katelu.
Uga cukup umum kanggo kita sing nindakake migrasi.
- Sembarang produk piranti lunak saya akeh. Syarat kasebut ganti. Ing kasus apa wae, kita pengin berkembang. Lan kedadeyan yen kita kudu nganyari data ing tabel, yaiku kanggo mbukak nganyari babagan migrasi kita kanggo fungsi anyar sing kita kenalake minangka bagean saka pangembangan kita.
- Format data lawas ora marem. Ayo dadi saiki kita nguripake kanggo tabel kapindho, ngendi aku duwe transaksi ing akun iki. Lan ayo ngomong yen dheweke ana ing rubel, lan kita mutusake kanggo nambah akurasi lan nindakake ing kopecks. Lan kanggo iki, kita kudu nganyari: multiply lapangan kanthi jumlah transaksi kanthi satus.
- Ing jagad saiki, kita nggunakake alat kontrol versi database otomatis. Ayo ngomong . Kita ndhaptar migrasi kita ing kana. Kita nyoba ing basis test kita. Kabeh apik. Nganyari lagi liwat. Iku pamblokiran karya kanggo nalika, nanging kita njaluk data dianyari. Lan kita bisa miwiti fungsi anyar babagan iki. Kabeh wis dites lan dipriksa. Kabeh wis dikonfirmasi.
- Kita nindakake karya sing direncanakake lan nindakake migrasi.
Mangkene migrasi kanthi nganyari sing ditampilake ing ngarep sampeyan. Wiwit iki transaksi akun, piring ana 15 GB. Lan wiwit kita nganyari saben baris, kita tikel ukuran meja karo nganyari, amarga kita rewrote saben baris.
Sajrone migrasi, kita ora bisa nindakake apa-apa karo piring iki, amarga kabeh panjaluk kasebut antri lan ngenteni nganti nganyari iki rampung. Nanging ing kene aku pengin narik perhatian sampeyan menyang nomer sing ana ing sumbu vertikal. Yaiku, kita duwe wektu panyuwunan rata-rata sadurunge migrasi kira-kira 5 milidetik lan beban prosesor, jumlah operasi blok kanggo maca memori disk kurang saka 7,5.
Kita nindakake migrasi lan entuk masalah maneh.
Migrasi kasebut sukses, nanging:
- Fungsi lawas saiki butuh wektu luwih suwe kanggo rampung.
- Tabel tansaya gedhe maneh.
- Beban ing server maneh dadi luwih gedhe tinimbang sadurunge.
- Lan, mesthi, kita isih tinkering karo fungsi sing makarya uga, kita wis nambah sethitik.
Lan iki maneh bloat, sing maneh ngrusak urip kita.
Ing kene aku nduduhake yen meja, kaya rong kasus sadurunge, ora bakal bali menyang ukuran sadurunge. Muatan server rata-rata katon cukup.
Lan yen kita nguripake menyang meja karo akun, kita bakal weruh sing wektu request rata-rata wis tikel kaping pindho kanggo meja iki. Beban ing prosesor lan nomer garis diurutake metu ing memori mlumpat ndhuwur 7,5, nanging luwih murah. Lan mlumpat kaping 2 ing kasus pemroses, 1,5 kaping ing operasi pamblokiran, yaiku kita entuk degradasi kinerja server. Lan minangka asil - degradasi kinerja aplikasi kita. Ing wektu sing padha, jumlah telpon tetep kira-kira ing tingkat sing padha.
Lan sing utama ing kene yaiku ngerti carane nindakake migrasi kasebut kanthi bener. Lan padha kudu rampung. Kita nindakake migrasi kasebut kanthi konsisten.
- Migrasi gedhe kasebut ora kedadeyan kanthi otomatis. Padha kudu tansah ing kontrol.
- Pengawasan dening wong sing duwe kawruh dibutuhake. Yen sampeyan duwe DBA ing tim sampeyan, ayo DBA nindakaken. Tugase. Yen ora, mula wong sing paling berpengalaman nindakake, sing ngerti carane nggarap database.
- Skema basis data anyar, sanajan kita nganyari siji kolom, kita mesthi nyiapake kanthi bertahap, yaiku sadurunge sadurunge versi anyar aplikasi diluncurake:
- Kolom anyar ditambahake ing ngendi kita bakal ngrekam data sing dianyari.
- Kita nransfer data saka lapangan lawas menyang lapangan anyar ing bagean cilik. Yagene kita nindakake iki? Kaping pisanan, kita tansah ngontrol proses proses iki. Kita ngerti manawa kita wis nransfer akeh batch lan isih akeh.
- Lan efek positif kapindho iku antarane saben kumpulan kuwi kita nutup transaksi, mbukak anyar, lan iki ngidini autovacuum bisa miturut piring, tandha garis mati kanggo nggunakake maneh.
- Kanggo garis sing bakal katon nalika aplikasi lagi mlaku (kita isih duwe aplikasi lawas mlaku), kita nambah pemicu sing nulis nilai anyar kanggo lapangan anyar. Ing kasus kita, iki minangka perkalian kanthi satus nilai lawas.
- Yen kita pancen wangkal lan pengin lapangan sing padha, banjur sawise rampung kabeh migrasi lan sadurunge nggulung versi anyar saka aplikasi, kita mung ngganti jeneng lapangan. Sing lawas diwenehi jeneng sing diciptakake, lan lapangan anyar diganti jeneng dadi sing lawas.
- Lan mung sawise kita miwiti versi anyar saka aplikasi.
Lan ing wektu sing padha kita ora bakal kembung lan ora bakal nandhang sangsara saka segi kinerja.
Iki ngendi crita katelu rampung.
Lan saiki luwih rinci babagan alat sing dakkandhakake ing crita pisanan.
Sadurunge nggoleki bloat, sampeyan kudu nginstal ekstensi kasebut .
Supaya sampeyan ora kudu nggawe pitakon, kita wis nulis pitakon kasebut ing karya kita. Sampeyan bisa nggunakake. Ana rong panjaluk ing kene.
- Sing pertama mbutuhake wektu sing cukup suwe, nanging bakal nuduhake nilai bloat sing tepat saka tabel.
- Sing nomer loro luwih cepet lan efektif banget nalika sampeyan kudu ngevaluasi kanthi cepet apa ana kembung utawa ora miturut tabel. Lan sampeyan uga kudu ngerti yen bloat tansah ana ing tabel Postgres. Iki minangka fitur saka model MVCC.
- Lan 20% bloat normal kanggo tabel ing akeh kasus. Sing, sampeyan ora kudu kuwatir lan compress meja iki.
Kita nemtokake cara kanggo ngenali tabel sing abuh karo data sing ora ana gunane.
Saiki babagan carane ndandani bloat:
- Yen kita duwe tablet cilik lan disk sing apik, yaiku, ing tablet nganti gigabyte, bisa uga nggunakake VACUUM FULL. Dheweke bakal njupuk kunci eksklusif saka sampeyan ing meja kanggo sawetara detik lan oke, nanging bakal nindakake kabeh cepet lan atos. Apa sing ditindakake VACUUM FULL? Butuh kunci eksklusif ing meja lan nulis ulang baris urip saka tabel lawas menyang meja anyar. Lan ing pungkasan dheweke ngganti. Mbusak file lawas lan ngganti sing lawas karo sing anyar. Nanging sajrone karyane, butuh kunci eksklusif ing meja. Iki tegese sampeyan ora bisa nindakake apa-apa karo tabel iki: aja nulis, utawa maca, utawa ngowahi. Lan VACUUM FULL mbutuhake papan disk tambahan kanggo nulis data.
- Alat sabanjure . Ing asas, meh padha karo VACUUM FULL, amarga uga nulis ulang data saka file lawas menyang anyar lan ngganti ing meja. Nanging ing wektu sing padha, ora njupuk kunci eksklusif ing meja ing awal karya, nanging mung ing wayahe yen wis duwe data siap kanggo ngganti file. Persyaratan sumber daya disk padha karo VACUUM FULL. Sampeyan mbutuhake papan disk tambahan, lan iki kadhangkala kritis yen sampeyan duwe tabel terabyte. Lan cukup prosesor-luwe amarga aktif dianggo karo I / O.
- Utawa kaping telu yaiku . Luwih ati-ati karo sumber daya amarga kerjane miturut prinsip sing rada beda. Gagasan utama pgcompacttable yaiku mindhah kabeh baris langsung menyang wiwitan tabel kanthi nggunakake nganyari ing tabel. Banjur mbukak vakum ing meja iki, amarga kita ngerti yen kita duwe baris urip ing wiwitan lan baris mati ing pungkasan. Lan vakum dhewe ngethok buntut iki, yaiku ora mbutuhake papan disk tambahan. Lan ing wektu sing padha, isih bisa diperes saka segi sumber daya.
Kabeh nganggo alat.
Yen sampeyan nemokake topik bloat sing menarik babagan nggoleki luwih jero, ana sawetara tautan sing migunani:
- - Iki laporan saka kancaku. Umume babagan papan Postgres sajrone karya lan urip. Lan ana potongan teknis sing gedhe banget lan rinci kanggo pangurus database babagan bloat.
- - iki minangka link menyang gudang, ing ngendi kita nyimpen akeh skrip sing migunani kanggo mriksa kahanan database. Ing kana sampeyan bisa nemokake skrip kanggo nggoleki bloat.
- ΠΈ pranala menyang alat sing bakal mbantu nyilikake pratandha.
- β iki kiriman saka kancaku. Ing kana dheweke cukup serius lan teknis nganalisa bloat kanthi rinci ing tingkat sing cedhak karo pangurus.
Aku nyoba luwih akeh kanggo nuduhake crita medeni kanggo pangembang, amarga dheweke minangka klien database langsung lan kudu ngerti apa lan tumindak apa. Muga-muga aku kasil. Matur nuwun kanggo perhatian sampeyan!
Pitakonan
Matur nuwun kanggo laporan! Sampeyan ngomong babagan carane sampeyan bisa ngenali masalah. Kepiye carane bisa dielingake? Yaiku, aku duwe kahanan sing njaluk panjaluk ora mung amarga ngakses sawetara layanan eksternal. Iki mung sawetara gabungan alam bΓ©bas. Ana sawetara panjaluk cilik lan ora mbebayani sing digantung nganti sedina, banjur wiwit nindakake omong kosong. Yaiku, meh padha karo sing sampeyan jelasake. Carane nglacak iki? Lungguh lan terus-terusan nonton panjaluk endi sing macet? Kepiye carane bisa dicegah?
Ing kasus iki, iki minangka tugas kanggo pangurus perusahaan sampeyan, ora kudu kanggo DBA.
Aku dadi administrator.
PostgreSQL duwe tampilan sing diarani pg_stat_activity sing nuduhake pitakon sing dangling. Lan sampeyan bisa ndeleng suwene iku macet ana.
Apa aku kudu mlebu lan ndeleng saben 5 menit?
Setel cron lan mriksa. Yen sampeyan duwe panjaluk jangka panjang, tulisake layang lan mung. Yaiku, sampeyan ora perlu ndeleng kanthi mripat, bisa kanthi otomatis. Sampeyan bakal nampa layang, sampeyan nanggepi. Utawa sampeyan bisa njupuk kanthi otomatis.
Apa ana alesan sing jelas kenapa kedadeyan kasebut?
Aku wis kadhaptar sawetara. Conto liyane sing luwih kompleks. Lan bisa dadi obrolan kanggo dangu.
Matur nuwun kanggo laporan! Aku pengin njlentrehake babagan utilitas pg_repack. Yen dheweke ora nindakake kunci eksklusif, banjur ...
Dheweke nindakake kunci eksklusif.
... banjur aku duweni potensi ilang data. Apa aplikasiku ora ngrekam apa-apa sajrone wektu iki?
Ora, kerjane lancar karo meja, yaiku pg_repack pisanan nransfer kabeh baris urip sing ana. Alami, ana sawetara jinis entri menyang meja. Dheweke mung mbuwang ponytail iki.
Yaiku, dheweke pancen nindakake ing pungkasan?
Pungkasane, dheweke njupuk kunci eksklusif kanggo ngganti file kasebut.
Apa bakal luwih cepet tinimbang VACUUM FULL?
VACUUM FULL, sanalika diwiwiti, langsung njupuk kunci eksklusif. Lan nganti dheweke nindakake kabeh, dheweke ora bakal nglilani dheweke lunga. Lan pg_repack njupuk kunci eksklusif mung nalika ngganti file. Ing wayahe sampeyan ora bakal nulis ana, nanging data ora bakal ilang, kabeh bakal nggoleki.
Hello! Sampeyan ngomong babagan operasi vakum mobil. Ana grafik kanthi sel rekaman abang, kuning lan ijo. Yaiku, sing kuning - dheweke menehi tandha yen wis dibusak. Lan minangka asil, soko anyar bisa ditulis menyang wong?
ya wis. Postgres ora mbusak garis. Dheweke duwe spesifik kaya ngono. Yen kita nganyari baris, kita nandhani sing lawas wis dibusak. Id saka transaksi sing diganti baris iki katon ana, lan kita nulis baris anyar. Lan kita duwe sesi sing bisa maca. Ing sawetara titik padha dadi cukup tuwa. Lan intine carane autovacuum bisa ditindakake yaiku ngliwati garis kasebut lan menehi tandha yen ora perlu. Lan sampeyan bisa nimpa data ana.
Aku ngerti. Nanging dudu pitakonan kasebut. Aku ora rampung. Ayo kita nganggep kita duwe meja. Wis lapangan ukuran variabel. Lan yen aku nyoba nglebokake sing anyar, bisa uga ora cocog karo sel lawas.
Ora, ing kasus kabeh baris dianyari ana. Postgres duwe rong model panyimpenan data. Iku milih saka jinis data. Ana data sing disimpen langsung ing tabel, lan uga ana data tos. Iki minangka jumlah data sing akeh: teks, json. Padha disimpen ing piring sing kapisah. Lan miturut tablet kasebut, crita sing padha karo kembung, yaiku kabeh padha. Dheweke mung kadhaptar kanthi kapisah.
Matur nuwun kanggo laporan! Apa bisa nggunakake pitakon wektu entek statement kanggo mbatesi durasi?
Ditrima banget. Kita nggunakake iki nang endi wae. Lan amarga kita ora duwe layanan dhewe, kita nyedhiyani support remot, kita duwe cukup macem-macem klien. Lan kabeh wong wis wareg karo iki. Yaiku, kita duwe proyek cron sing mriksa. Durasi sesi kasebut mung disepakati karo klien, sadurunge kita ora setuju. Bisa dadi menit, bisa uga 10 menit. Iku gumantung saka beban ing basa lan tujuane. Nanging kita kabeh nggunakake pg_stat_activity.
Matur nuwun kanggo laporan! Aku nyoba ngetrapake laporan sampeyan ing aplikasiku. Lan misale jek kaya kita miwiti transaksi nang endi wae, lan kanthi jelas ngrampungake ing endi wae. Yen ana sawetara pangecualian, banjur rollback isih ana. Banjur aku wiwit mikir. Sawise kabeh, transaksi bisa uga ora diwiwiti kanthi jelas. Iki mbokmenawa pitunjuk kanggo cah wadon. Yen aku mung nganyari rekaman, bakal miwiti transaksi ing PostgreSQL lan mung rampung nalika sambungan wis pedhot?
Yen sampeyan lagi ngomong babagan level aplikasi, mula gumantung saka driver sing sampeyan gunakake, ing ORM sing digunakake. Ana akeh setelan ing kana. Yen sampeyan ngaktifake komit otomatis, banjur transaksi diwiwiti lan langsung ditutup.
Yaiku, langsung ditutup sawise nganyari?
Iku gumantung ing setelan. Aku jenenge siji setelan. Iki auto commit on. Iku cukup umum. Yen diaktifake, banjur transaksi wis dibukak lan ditutup. Kajaba sampeyan ujar kanthi tegas "miwiti transaksi" lan "transaksi pungkasan", nanging mung ngluncurake panjaluk menyang sesi kasebut.
Hello! Matur nuwun kanggo laporan! Coba bayangake yen kita duwe database sing abuh lan abuh banjur spasi ing server entek. Apa ana alat kanggo ndandani kahanan iki?
Spasi ing server kudu dipantau kanthi bener.
Contone, DBA lunga kanggo teh, ana ing resort, etc.
Nalika sistem file digawe, paling ora sawetara jinis papan serep digawe ing ngendi data ora ditulis.
Apa yen wis rampung ngisor nul?
Ing kono diarani papan sing dilindhungi, yaiku bisa dibebasake lan gumantung saka ukurane digawe, sampeyan entuk ruang bebas. Secara default aku ora ngerti jumlahe. Lan ing kasus liyane, ngirim disk supaya sampeyan duwe ruang kanggo nindakake operasi rekonstruktif. Sampeyan bisa mbusak sawetara tabel sing dijamin ora perlu.
Apa ana alat liyane?
Iku tansah gawenan tangan. Lan sacara lokal dadi jelas apa sing paling apik kanggo ditindakake ing kana, amarga sawetara data kritis lan sawetara ora kritis. Lan kanggo saben database lan aplikasi sing bisa digunakake, iku gumantung ing bisnis. Iku tansah mutusakΓ© lokal.
Matur nuwun kanggo laporan! Aku duwe rong pitakonan. Pisanan, sampeyan nuduhake slide sing nuduhake yen transaksi macet, ukuran tablespace lan ukuran indeks bakal tuwuh. Lan luwih ing laporan ana akeh utilitas sing ngemas tablet kasebut. Kepiye babagan indeks?
Padha ngemas uga.
Nanging vakum ora mengaruhi indeks?
Sawetara bisa nganggo indeks. Contone, pg_rapack, pgcompacttable. Vakum nggawe maneh indeks lan kena pengaruh. Kanthi VACUUM FULL, ide kanggo nimpa kabeh, yaiku bisa digunakake karo kabeh wong.
Lan pitakonan kapindho. Aku ora ngerti sebabe laporan babagan replika gumantung banget karo replikasi kasebut. Iku ketoke kanggo kula sing laporan diwaca, lan replikasi ditulis.
Apa sing nyebabake konflik replikasi? Kita duwe Master babagan proses sing ditindakake. Kita duwe vakum mobil. Apa sing ditindakake autovacuum? Dheweke ngethok sawetara garis lawas. Yen ing wektu iki kita duwe panjalukan ing tiron sing maca garis lawas iki, lan ing Master kahanan sing autovacuum nandhani garis iki minangka bisa kanggo nimpa, banjur kita overwrote wong. Lan kita nampa paket data, nalika kita kudu nulis ulang baris sing panjalukan perlu ing tiron, proses replikasi bakal ngenteni wektu entek sing wis diatur. Banjur PostgreSQL bakal mutusake apa sing luwih penting. Lan replikasi luwih penting kanggo dheweke tinimbang panjaluk kasebut, lan dheweke bakal njupuk panjaluk kasebut supaya owah-owahan kasebut ing replika kasebut.
Andrey, aku duwe pitakonan. Iki grafik apik sing sampeyan nuduhake nalika presentation, apa iki asil karya saka sawetara jinis utilitas sampeyan? Kepiye grafik kasebut digawe?
Iki minangka layanan .
Apa iki produk komersial?
ya wis. Iki minangka produk komersial.
Source: www.habr.com