Ju sugjeroj të lexoni transkriptin e raportit nga fillimi i vitit 2016 nga Andrey Salnikov "Gabimet tipike në aplikacione që çojnë në fryrje në postgresql"
Në këtë raport, unë do të analizoj gabimet kryesore në aplikacione që lindin në fazën e hartimit dhe shkrimit të kodit të aplikacionit. Dhe unë do të marr vetëm ato gabime që çojnë në fryrje në Postgresql. Si rregull, ky është fillimi i përfundimit të performancës së sistemit tuaj në tërësi, megjithëse fillimisht nuk ishin të dukshme asnjë parakusht për këtë.
Me kënaqësi ju mirëpres të gjithëve! Ky raport nuk është aq teknik sa ai i mëparshmi nga kolegu im. Ky raport u drejtohet kryesisht zhvilluesve të sistemeve mbështetëse, sepse ne kemi një numër mjaft të madh klientësh. Dhe të gjithë bëjnë të njëjtat gabime. Unë do t'ju tregoj për to. Unë do të shpjegoj në çfarë gjërash fatale dhe të këqija çojnë këto gabime.
Pse bëhen gabime? Ato kryhen për dy arsye: në mënyrë të rastësishme, ndoshta do të funksionojë dhe për shkak të mosnjohjes së disa mekanizmave që ndodhin në nivelin midis bazës së të dhënave dhe aplikacionit, si dhe në vetë bazën e të dhënave.
Unë do t'ju jap tre shembuj me fotografi të tmerrshme se sa keq u bënë gjërat. Unë do t'ju tregoj shkurtimisht për mekanizmin që ndodh atje. Dhe si të merreni me to, kur kanë ndodhur dhe cilat metoda parandaluese duhet të përdoren për të parandaluar gabimet. Unë do t'ju tregoj për mjetet ndihmëse dhe do t'ju ofroj lidhje të dobishme.
Kam përdorur një bazë të dhënash testimi ku kisha dy tabela. Njëra pjatë me llogaritë e klientëve, tjetra me transaksione në këto llogari. Dhe me një farë frekuencë ne përditësojmë bilancet në këto llogari.
Të dhënat fillestare të pllakës: është mjaft e vogël, 2 MB. Koha e përgjigjes për bazën e të dhënave dhe konkretisht për shenjën është gjithashtu shumë e mirë. Dhe një ngarkesë mjaft e mirë - 2 operacione në sekondë sipas pllakës.
Dhe përmes këtij raporti do t'ju tregoj grafikët në mënyrë që të kuptoni qartë se çfarë po ndodh. Gjithmonë do të ketë 2 sllajde me grafikë. Sllajdi i parë është ajo që ndodh në përgjithësi në server.
Dhe në këtë situatë, ne shohim se kemi vërtet një shenjë të vogël. Indeksi është i vogël në 2 MB. Ky është grafiku i parë në të majtë.
Koha mesatare e përgjigjes në server është gjithashtu e qëndrueshme dhe e shkurtër. Ky është grafiku lart djathtas.
Grafiku i poshtëm majtas tregon transaksionet më të gjata. Ne shohim që transaksionet përfundojnë shpejt. Dhe autovakuumi nuk funksionon ende këtu, sepse ishte një test fillestar. Do të vazhdojë të funksionojë dhe do të jetë e dobishme për ne.
Sllajdi i dytë do t'i kushtohet gjithmonë pllakës që testohet. Në këtë situatë, ne përditësojmë vazhdimisht gjendjet e llogarisë së klientit. Dhe ne shohim se koha mesatare e përgjigjes për një operacion përditësimi është mjaft e mirë, më pak se një milisekondë. Ne shohim që burimet e procesorit (ky është grafiku i sipërm djathtas) gjithashtu konsumohen në mënyrë të barabartë dhe mjaft të vogla.
Grafiku djathtas poshtë tregon se sa memorie operative dhe të diskut kalojmë në kërkim të linjës sonë të dëshiruar përpara se ta përditësojmë. Dhe numri i operacioneve sipas shenjës është 2 në sekondë, siç thashë në fillim.
Dhe tani kemi një tragjedi. Për disa arsye ka një transaksion të harruar prej kohësh. Arsyet janë zakonisht të gjitha banale:
- Një nga më të zakonshmet është që filluam të aksesojmë një shërbim të jashtëm në kodin e aplikacionit. Dhe ky shërbim nuk na përgjigjet. Kjo do të thotë, ne hapëm një transaksion, bëmë një ndryshim në bazën e të dhënave dhe shkuam nga aplikacioni për të lexuar postën ose në një shërbim tjetër brenda infrastrukturës sonë, dhe për disa arsye ai nuk na përgjigjet. Dhe seanca jonë ka ngecur në një gjendje ku nuk dihet se kur do të zgjidhet.
- Situata e dytë është kur një përjashtim ka ndodhur në kodin tonë për ndonjë arsye. Dhe në përjashtim nuk e përpunuam mbylljen e transaksionit. Dhe ne përfunduam me një seancë pezull me një transaksion të hapur.
- Dhe kjo e fundit është gjithashtu një rast mjaft i zakonshëm. Ky është kod me cilësi të ulët. Disa korniza hapin një transaksion. Varet dhe mund të mos e dini në aplikacion që e keni të varur.
Ku të çojnë gjëra të tilla?
Deri në atë pikë sa tabelat dhe indekset tona fillojnë të rriten në mënyrë dramatike. Ky është saktësisht i njëjti efekt fryrjeje. Për bazën e të dhënave, kjo do të thotë që koha e përgjigjes së bazës së të dhënave do të rritet shumë ndjeshëm dhe ngarkesa në serverin e bazës së të dhënave do të rritet. Dhe si rezultat, aplikacioni ynë do të vuajë. Sepse nëse keni shpenzuar 10 milisekonda në kodin tuaj në një kërkesë në bazën e të dhënave, 10 milisekonda në logjikën tuaj, atëherë funksioni juaj mori 20 milisekonda për t'u përfunduar. Dhe tani situata juaj do të jetë shumë e trishtuar.
Dhe le të shohim se çfarë ndodh. Grafiku i poshtëm majtas tregon se kemi një transaksion të gjatë të gjatë. Dhe nëse shikojmë grafikun e sipërm majtas, shohim se madhësia e tabelës është rritur papritur nga dy megabajt në 300 megabajt. Në të njëjtën kohë, sasia e të dhënave në tabelë nuk ka ndryshuar, d.m.th. ka një sasi mjaft të madhe mbeturinash atje.
Situata e përgjithshme në lidhje me kohën mesatare të përgjigjes së serverit ka ndryshuar gjithashtu me disa renditje të madhësisë. Kjo do të thotë, të gjitha kërkesat në server filluan të bien plotësisht. Dhe në të njëjtën kohë, proceset e brendshme të Postgres u nisën në formën e autovakumit, të cilët po përpiqen të bëjnë diçka dhe konsumojnë burime.
Çfarë po ndodh me shenjën tonë? E njëjta. Koha jonë mesatare e përgjigjes sipas shenjës është rritur me disa rend të madhësisë. Konkretisht për sa i përket burimeve të konsumuara, shohim se ngarkesa në procesor është rritur shumë. Ky është grafiku lart djathtas. Dhe është rritur sepse procesori duhet të zgjidhë një sërë linjash të padobishme në kërkim të asaj që nevojitet. Ky është grafiku i poshtëm djathtas. Dhe si rezultat, numri ynë i thirrjeve në sekondë filloi të bjerë shumë ndjeshëm, sepse baza e të dhënave nuk kishte kohë të përpunonte të njëjtin numër kërkesash.
Duhet të kthehemi në jetë. Ne shkojmë në internet dhe zbulojmë se transaksionet e gjata çojnë në një problem. Ne e gjejmë dhe e vrasim këtë transaksion. Dhe gjithçka po bëhet normale për ne. Gjithçka funksionon ashtu siç duhet.
Ne u qetësuam, por pas një kohe fillojmë të vërejmë se aplikacioni nuk funksionon njësoj si përpara urgjencës. Kërkesat ende përpunohen më ngadalë dhe dukshëm më ngadalë. Një e gjysmë deri në dy herë më ngadalë veçanërisht në shembullin tim. Ngarkesa në server është gjithashtu më e lartë se sa ishte para aksidentit.
Dhe pyetja: "Çfarë po ndodh me bazën në këtë moment?" Dhe situata e mëposhtme ndodh me bazën. Në grafikun e transaksioneve mund të shihni se ai është ndalur dhe realisht nuk ka transaksione afatgjata. Por madhësia e shenjës u rrit fatalisht gjatë aksidentit. Dhe që atëherë ato nuk janë ulur. Koha mesatare në bazë është stabilizuar. Dhe përgjigjet duket se po vijnë në mënyrë adekuate me një shpejtësi të pranueshme për ne. Autovakuumi u bë më aktiv dhe filloi të bëjë diçka me shenjën, sepse duhet të analizojë më shumë të dhëna.
Konkretisht, sipas targës së testimit me llogaritë, ku ndryshojmë bilancet: koha e përgjigjes për një kërkesë duket se është kthyer në normalitet. Por në realitet është një herë e gjysmë më e lartë.
Dhe nga ngarkesa në procesor, ne shohim se ngarkesa në procesor nuk është kthyer në vlerën e kërkuar para përplasjes. Dhe arsyet qëndrojnë pikërisht në grafikun e poshtëm djathtas. Mund të shihet se një sasi e caktuar memorie po kërkohet atje. Kjo do të thotë, për të gjetur linjën e kërkuar, ne harxhojmë burimet e serverit të bazës së të dhënave duke renditur të dhënat e padobishme. Numri i transaksioneve në sekondë është stabilizuar.
Në përgjithësi mirë, por situata është më e keqe se sa ishte. Pastroni degradimin e bazës së të dhënave si pasojë e aplikacionit tonë që punon me këtë bazë të dhënash.
Dhe për të kuptuar se çfarë po ndodh atje, nëse nuk keni qenë në raportin e mëparshëm, tani le të marrim një teori të vogël. Teoria rreth procesit të brendshëm. Pse një fshesë me korrent dhe çfarë bën ai?
Fjalë për fjalë shkurt për të kuptuar. Në një moment në kohë kemi një tryezë. Ne kemi rreshta në tabelë. Këto linja mund të jenë aktive, të gjalla dhe ato që na duhen tani. Ato janë të shënuara me ngjyrë të gjelbër në foto. Dhe ka afate që tashmë janë përpunuar, janë përditësuar dhe hyrje të reja janë shfaqur në to. Dhe ata janë shënuar se nuk janë më interesante për bazën e të dhënave. Por ato janë në tabelë për shkak të një veçorie Postgres.
Pse keni nevojë për një fshesë me korrent? Në një moment, autovakuumi vjen, hyn në bazën e të dhënave dhe e pyet: "Ju lutem më jepni ID-në e transaksionit më të vjetër që është aktualisht i hapur në bazën e të dhënave." Baza e të dhënave e kthen këtë ID. Dhe autovakuumi, duke u mbështetur në të, rendit nëpër linjat në tabelë. Dhe nëse sheh se disa rreshta janë ndryshuar nga transaksione shumë më të vjetra, atëherë ai ka të drejtë t'i shënojë ato si linja që mund t'i ripërdorim në të ardhmen duke shkruar të dhëna të reja atje. Ky është një proces sfondi.
Në këtë kohë, ne vazhdojmë të punojmë me bazën e të dhënave dhe vazhdojmë të bëjmë disa ndryshime në tabelë. Dhe në këto rreshta, të cilat mund t'i ripërdorim, ne shkruajmë të dhëna të reja. Dhe kështu marrim një cikël, d.m.th gjatë gjithë kohës aty shfaqen disa vija të vjetra të vdekura, në vend të tyre ne shkruajmë rreshta të rinj që na duhen. Dhe kjo është një gjendje normale që PostgreSQL të funksionojë.
Çfarë ndodhi gjatë aksidentit? Si ndodhi ky proces atje?
Ne kishim një shenjë në një gjendje, disa të gjalla, disa linja. Ka ardhur vakuumi i makinës. Ai pyeti bazën e të dhënave se cili është transaksioni ynë më i vjetër dhe cili është id-i i tij. Mora këtë ID, e cila mund të ishte shumë orë më parë, ndoshta dhjetë minuta më parë. Kjo varet nga sa e rëndë ngarkesa keni në bazën e të dhënave tuaja. Dhe ai shkoi të kërkonte rreshta që mund t'i shënonte si të ripërdorura. Dhe unë nuk gjeta rreshta të tillë në tabelën tonë.
Por në këtë kohë ne vazhdojmë të punojmë me tabelën. Ne bëjmë diçka në të, e përditësojmë, ndryshojmë të dhënat. Çfarë duhet të bëjë baza e të dhënave në këtë kohë? Ajo nuk ka zgjidhje tjetër veçse të shtojë rreshta të rinj në fund të tabelës ekzistuese. Dhe kështu madhësia e tryezës sonë fillon të fryhet.
Në realitet, ne kemi nevojë për linja të gjelbra për të funksionuar. Por gjatë një problemi të tillë, rezulton se përqindja e vijave jeshile është jashtëzakonisht e ulët në të gjithë tabelën.
Dhe kur ekzekutojmë një pyetje, baza e të dhënave duhet të kalojë nëpër të gjitha linjat: të kuqe dhe jeshile, për të gjetur vijën e dëshiruar. Dhe efekti i fryrjes së një tavoline me të dhëna të padobishme quhet "fryrje", e cila gjithashtu na ha hapësirën e diskut. Mos harroni, ishte 2 MB, u bë 300 MB? Tani ndryshoni megabajt në gigabajt dhe shpejt do të humbni të gjitha burimet tuaja të diskut.
Çfarë pasojash mund të ketë për ne?
- Në shembullin tim, tabela dhe indeksi u rritën 150 herë. Disa nga klientët tanë kanë pasur raste më fatale kur thjesht filluan të mbaronin hapësirën në disk.
- Madhësia e tabelave në vetvete nuk do të ulet kurrë. Autovakuumi në disa raste mund të presë bishtin e tavolinës nëse ka vetëm vija të fundit. Por meqenëse ka një rrotullim të vazhdueshëm, një vijë e gjelbër mund të ngrijë në fund dhe të mos përditësohet, ndërsa të gjitha të tjerat do të shënohen diku në fillim të pllakës. Por kjo është një ngjarje kaq e pamundur që tavolina juaj të zvogëlohet në madhësi, kështu që nuk duhet të shpresoni për të.
- Baza e të dhënave duhet të renditë një grup të tërë linjash të padobishme. Dhe ne shpërdorojmë burimet e diskut, humbim burimet e procesorit dhe energjinë elektrike.
- Dhe kjo ndikon drejtpërdrejt në aplikacionin tonë, sepse nëse në fillim shpenzuam 10 milisekonda në kërkesë, 10 milisekonda në kodin tonë, atëherë gjatë përplasjes filluam të shpenzojmë një sekondë në kërkesë dhe 10 milisekonda për kodin, d.m.th. madhësia në performancën e aplikimit është ulur. Dhe kur aksidenti u zgjidh, filluam të shpenzonim 20 milisekonda për një kërkesë, 10 milisekonda për një kod. Kjo do të thotë se ne kemi ende një rënie me një herë e gjysmë në produktivitet. Dhe kjo është e gjitha për shkak të një transaksioni që ngriu, ndoshta për fajin tonë.
- Dhe pyetja: "Si mund t'i kthejmë gjithçka?" në mënyrë që gjithçka të jetë në rregull me ne dhe kërkesat të vijnë aq shpejt sa para aksidentit.
Për këtë qëllim ka një cikël të caktuar pune që kryhet.
Fillimisht duhet të gjejmë tabelat problematike që janë të fryra. Kuptojmë se në disa tabela regjistrimi është më aktiv, në të tjera më pak aktiv. Dhe për këtë përdorim shtesën . Duke instaluar këtë shtesë, mund të shkruani pyetje që do t'ju ndihmojnë të gjeni tabela që janë mjaft të fryra.
Pasi të keni gjetur këto tabela, duhet t'i kompresoni ato. Tashmë ka mjete për këtë. Në kompaninë tonë ne përdorim tre mjete. E para është VACUUM FULL e integruar. Ai është mizor, i ashpër dhe i pamëshirshëm, por ndonjëherë është shumë i dobishëm. и - Këto janë shërbime të palëve të treta për kompresimin e tabelave. Dhe ata e trajtojnë bazën e të dhënave më me kujdes.
Ato përdoren në varësi të asaj që është më e përshtatshme për ju. Por unë do t'ju tregoj për këtë në fund. Gjëja kryesore është se ka tre mjete. Ka shumë për të zgjedhur.
Pasi të kemi korrigjuar gjithçka dhe të jemi siguruar që gjithçka është në rregull, duhet të dimë se si ta parandalojmë këtë situatë në të ardhmen:
- Mund të parandalohet mjaft lehtë. Ju duhet të monitoroni kohëzgjatjen e seancave në serverin Master. Seancat veçanërisht të rrezikshme në gjendje boshe në gjendje transaksioni. Këta janë ata që sapo hapën një transaksion, bënë diçka dhe u larguan, ose thjesht u varën, humbën në kod.
- Dhe për ju, si zhvillues, është e rëndësishme të testoni kodin tuaj kur lindin këto situata. Nuk është e vështirë të bëhet. Ky do të jetë një kontroll i dobishëm. Do të shmangni një numër të madh problemesh “fëminore” që lidhen me transaksionet e gjata.
Në këto grafikë, doja t'ju tregoja se si ndryshuan shenja dhe sjellja e bazës së të dhënave pasi kalova shenjën me VACUUM FULL në këtë rast. Ky nuk është prodhim për mua.
Madhësia e tabelës u kthye menjëherë në gjendjen e saj normale të funksionimit prej disa megabajt. Kjo nuk ndikoi shumë në kohën mesatare të përgjigjes për serverin.
Por konkretisht për shenjën tonë të testimit, ku përditësuam bilancet e llogarisë, shohim se koha mesatare e përgjigjes për një kërkesë për përditësimin e të dhënave në shenjë u reduktua në nivelet e para-urgjencës. Burimet e konsumuara nga procesori për të plotësuar këtë kërkesë ranë gjithashtu në nivelet para përplasjes. Dhe grafiku i poshtëm djathtas tregon se tani ne gjejmë saktësisht vijën që na nevojitet menjëherë, pa kaluar nëpër grumbujt e vijave të vdekura që ishin aty përpara se tabela të ngjeshej. Dhe koha mesatare e kërkesës mbeti afërsisht në të njëjtin nivel. Por këtu kam, përkundrazi, një gabim në harduerin tim.
Këtu përfundon historia e parë. Është më i zakonshmi. Dhe kjo u ndodh të gjithëve, pavarësisht nga përvoja e klientit dhe sa të kualifikuar janë programuesit. Herët a vonë kjo ndodh.
Historia e dytë, në të cilën shpërndajmë ngarkesën dhe optimizojmë burimet e serverit
- Tashmë jemi rritur dhe jemi bërë djem seriozë. Dhe ne e kuptojmë që kemi një kopje dhe do të ishte mirë që ne të balanconim ngarkesën: t'i shkruajmë Mjeshtrit dhe të lexojmë nga kopja. Dhe zakonisht kjo situatë lind kur duam të përgatisim disa raporte ose ETL. Dhe biznesi është shumë i lumtur për këtë. Ai me të vërtetë dëshiron një shumëllojshmëri raportesh me shumë analiza komplekse.
- Raportet zgjasin shumë orë, sepse analitika komplekse nuk mund të llogaritet në milisekonda. Ne, si djem të guximshëm, shkruajmë kod. Në aplikacionin e futjes bëjmë regjistrimin në Master, dhe ekzekutojmë raportet në kopje.
- Shpërndarja e ngarkesës.
- Gjithçka funksionon në mënyrë perfekte. Ne jemi të shkëlqyer.
Dhe si duket kjo situatë? Konkretisht në këto grafikë, kam shtuar edhe kohëzgjatjen e transaksioneve nga kopja për kohëzgjatjen e transaksionit. Të gjithë grafikët e tjerë i referohen vetëm serverit Master.
Në këtë kohë, bordi im i raportimit ishte rritur. Ka më shumë prej tyre. Ne shohim që koha mesatare e përgjigjes së serverit është e qëndrueshme. Ne shohim që në kopje kemi një transaksion afatgjatë që funksionon për 2 orë. Ne shohim funksionimin e qetë të autovakumit, i cili përpunon linjat e fundit. Dhe gjithçka është në rregull me ne.
Konkretisht, sipas targës së testuar, vazhdojmë të përditësojmë gjendjet e llogarisë atje. Dhe ne gjithashtu kemi një kohë të qëndrueshme përgjigjeje për kërkesat, konsum të qëndrueshëm të burimeve. Gjithçka është në rregull me ne.
Gjithçka është në rregull deri në momentin që këto raporte fillojnë të kthehen për shkak të një konflikti me përsëritjen. Dhe ata qëllojnë përsëri në intervale të rregullta.
Ne shkojmë në internet dhe fillojmë të lexojmë pse po ndodh kjo. Dhe ne gjejmë një zgjidhje.
Zgjidhja e parë është rritja e vonesës së replikimit. Ne e dimë që raporti ynë zgjat 3 orë. Ne vendosëm vonesën e replikimit në 3 orë. Ne po lançojmë gjithçka, por ende vazhdojmë të kemi probleme me raportet që ndonjëherë anulohen.
Ne duam që gjithçka të jetë perfekte. Ne ngjitemi më tej. Dhe gjetëm një mjedis të këndshëm në internet - hot_standby_feedback. Le ta ndezim. Hot_standby_feedback na lejon të frenojmë autovakumin në Master. Kështu, ne shpëtojmë plotësisht nga konfliktet e përsëritjes. Dhe gjithçka funksionon mirë për ne me raporte.
Dhe çfarë po ndodh me serverin Master në këtë kohë? Dhe ne jemi në telashe totale me serverin Master. Tani po shohim grafikët kur i kam të aktivizuara të dyja këto cilësime. Dhe ne shohim që seanca në kopjen tonë filloi disi të ndikojë në situatën në serverin Master. Ajo ka një efekt sepse ndaloi autovakumin, i cili fshin kufijtë. Madhësia e tryezës sonë është rritur përsëri. Koha mesatare e ekzekutimit të pyetjeve në të gjithë bazën e të dhënave u rrit gjithashtu në qiell. Autovakumët u shtrënguan pak.
Konkretisht, nga pllaka jonë, ne shohim se përditësimi i të dhënave në të gjithashtu u hodh në qiell. Konsumi i CPU-së është rritur gjithashtu shumë. Ne përsëri po kalojmë një numër të madh linjash të vdekura, të padobishme. Dhe koha e përgjigjes për këtë shenjë dhe numri i transaksioneve kanë rënë.
Si do të duket nëse nuk e dimë se për çfarë po flisja më parë?
- Ne fillojmë të kërkojmë probleme. Nëse kemi hasur probleme në pjesën e parë, ne e dimë se kjo mund të jetë për shkak të një transaksioni të gjatë dhe të shkojë te Master. Ne kemi një problem me Mjeshtrin. Salcice atë. Nxehet, mesatarja e ngarkesës së saj është rreth njëqind.
- Kërkesat atje janë të ngadalta, por ne nuk shohim ndonjë transaksion afatgjatë atje. Dhe ne nuk e kuptojmë se çfarë është puna. Nuk kuptojmë ku të shikojmë.
- Ne kontrollojmë pajisjet e serverit. Ndoshta bastisja jonë u rrëzua. Ndoshta memoria jonë është djegur. Po, çdo gjë mund të ndodhë. Por jo, serverët janë të rinj, gjithçka funksionon mirë.
- Të gjithë po vrapojnë: administratorët, zhvilluesit dhe drejtori. Asgjë nuk ndihmon.
- Dhe në një moment gjithçka papritmas fillon të korrigjohet.
Në këtë kohë, kërkesa për kopjen tonë u përpunua dhe u largua. Ne e morëm raportin. Biznesi është ende i lumtur. Siç mund ta shihni, shenja jonë është rritur sërish dhe nuk do të tkurret. Në grafikun me sesionet, kam lënë një pjesë të këtij transaksioni të gjatë nga një kopje, në mënyrë që të vlerësoni se sa kohë duhet derisa situata të stabilizohet.
Seanca ka përfunduar. Dhe vetëm pas njëfarë kohe serveri vjen pak a shumë në rregull. Dhe koha mesatare e përgjigjes për kërkesat në serverin Master kthehet në normale. Sepse, më në fund, autovakuumi ka mundësinë të pastrojë dhe të shënojë këto kufij. Dhe ai filloi të bënte punën e tij. Dhe sa shpejt e bën ai, aq shpejt do të rregullohemi.
Sipas tabletit të testuar, ku përditësojmë bilancet e llogarive, shohim saktësisht të njëjtën pamje. Koha mesatare e përditësimit të llogarisë po normalizohet gjithashtu gradualisht. Reduktohen gjithashtu burimet e konsumuara nga procesori. Dhe numri i transaksioneve në sekondë kthehet në normalitet. Por sërish jemi kthyer në normalitet, jo si para aksidentit.
Në çdo rast, marrim një ulje të performancës, si në rastin e parë, nga një e gjysmë deri në dy herë, dhe ndonjëherë edhe më shumë.
Duket se kemi bërë gjithçka siç duhet. Shpërndani ngarkesën. Pajisja nuk është boshe. Kërkesat i ndamë sipas mendjes, por megjithatë gjithçka doli keq.
- Nuk aktivizoni hot_standby_feedback? Po, nuk rekomandohet ta ndizni pa arsye veçanërisht të forta. Sepse kjo kthesë ndikon drejtpërdrejt në serverin Master dhe pezullon funksionimin e autovakumit atje. Duke e aktivizuar atë në disa kopje dhe duke e harruar atë, ju mund të vrisni Masterin dhe të keni probleme të mëdha me aplikacionin.
- Të rritet max_standby_streaming_delay? Po, për raportet kjo është e vërtetë. Nëse keni një raport tre-orësh dhe nuk dëshironi që ai të rrëzohet për shkak të konflikteve të përsëritjes, atëherë thjesht rrisni vonesën. Një raport afatgjatë nuk kërkon kurrë të dhëna që kanë mbërritur në bazën e të dhënave tani. Nëse e keni për tre orë, atëherë po e përdorni për një periudhë të vjetër të të dhënave. Dhe për ju, nëse do të ketë një vonesë prej tre orësh ose një vonesë prej gjashtë orësh nuk do të bëjë ndonjë ndryshim, por ju do të merrni raporte të vazhdueshme dhe nuk do të keni asnjë problem me rënien e tyre.
- Natyrisht, ju duhet të kontrolloni seanca të gjata në kopje, veçanërisht nëse vendosni të aktivizoni hot_standby_feedback në një kopje. Sepse çdo gjë mund të ndodhë. Ne ia dhamë këtë kopje zhvilluesit në mënyrë që ai të mund të testonte kërkesat. Ai shkroi një kërkesë të çmendur. Ai e nisi dhe shkoi të pinte çaj, dhe ne morëm Mjeshtrin e vendosur. Ose mbase kemi vendosur aplikacionin e gabuar atje. Situatat janë të ndryshme. Seancat në kopje duhet të monitorohen me aq kujdes sa në Master.
- Dhe nëse keni pyetje të shpejta dhe të gjata për kopjet, atëherë në këtë rast është më mirë t'i ndani ato për të shpërndarë ngarkesën. Kjo është një lidhje me streaming_delay. Për ato të shpejta, keni një kopje me një vonesë të vogël përsëritjeje. Për kërkesat e raportimit afatgjatë, keni një kopje që mund të vonojë me 6 orë ose një ditë. Kjo është një situatë krejtësisht normale.
Ne eliminojmë pasojat në të njëjtën mënyrë:
- Gjejmë tavolina të fryra.
- Dhe e ngjeshim me mjetin më të përshtatshëm që na përshtatet.
Historia e dytë përfundon këtu. Le të kalojmë në historinë e tretë.
Gjithashtu mjaft e zakonshme për ne ku bëjmë migrim.
- Çdo produkt softuer po rritet. Kërkesat për të po ndryshojnë. Në çdo rast, ne duam të zhvillojmë. Dhe ndodh që ne duhet të përditësojmë të dhënat në tabelë, përkatësisht të ekzekutojmë një përditësim për sa i përket migrimit tonë për funksionalitetin e ri që po prezantojmë si pjesë e zhvillimit tonë.
- Formati i vjetër i të dhënave nuk është i kënaqshëm. Le të themi se tani i drejtohemi tabelës së dytë, ku unë kam transaksione në këto llogari. Dhe le të themi se ato ishin në rubla, dhe ne vendosëm të rrisim saktësinë dhe ta bëjmë atë në kopecks. Dhe për këtë duhet të bëjmë një përditësim: shumëzojeni fushën me shumën e transaksionit me njëqind.
- Në botën e sotme, ne përdorim mjete të automatizuara të kontrollit të versionit të bazës së të dhënave. Le të themi . Ne e regjistrojmë migrimin tonë atje. Ne e testojmë atë në bazën tonë të provës. Cdo gje eshte ne rregull. Përditësimi po kalon. Bllokon punën për një kohë, por ne marrim të dhëna të përditësuara. Dhe ne mund të lëshojmë funksione të reja për këtë. Gjithçka u testua dhe u kontrollua. Gjithçka u konfirmua.
- Kemi kryer punë të planifikuara dhe kemi kryer migrimin.
Këtu është migrimi me përditësimin e paraqitur para jush. Meqenëse këto janë transaksionet e llogarisë sime, targa ishte 15 GB. Dhe meqenëse përditësojmë çdo rresht, dyfishuam madhësinë e tabelës me përditësimin, sepse rishkruam çdo rresht.
Gjatë migrimit, ne nuk mund të bënim asgjë me këtë pllakë, sepse të gjitha kërkesat për të ishin në radhë dhe pritën derisa të përfundonte ky përditësim. Por këtu dua të tërheq vëmendjen tuaj te numrat që janë në boshtin vertikal. Kjo do të thotë, ne kemi një kohë mesatare të kërkesës para migrimit prej rreth 5 milisekonda dhe ngarkesës së procesorit, numri i operacioneve të bllokut për leximin e memories së diskut është më pak se 7,5.
Kemi kryer migrimin dhe kemi pasur sërish probleme.
Migrimi ishte i suksesshëm, por:
- Funksionaliteti i vjetër tani kërkon më shumë kohë për t'u përfunduar.
- Tabela u rrit përsëri në madhësi.
- Ngarkesa në server u bë përsëri më e madhe se më parë.
- Dhe, sigurisht, ne ende jemi duke e ndërlidhur me funksionalitetin që funksionoi mirë, e kemi përmirësuar pak.
Dhe kjo është përsëri fryrje, e cila përsëri shkatërron jetën tonë.
Këtu demonstroj se tabela, si dy rastet e mëparshme, nuk do të kthehet në madhësitë e mëparshme. Ngarkesa mesatare e serverit duket të jetë e mjaftueshme.
Dhe nëse i drejtohemi tabelës me llogaritë, do të shohim se koha mesatare e kërkesës është dyfishuar për këtë tabelë. Ngarkesa në procesor dhe numri i linjave të renditura në memorie u hodh mbi 7,5, por ishte më i ulët. Dhe u hodh 2 herë në rastin e procesorëve, 1,5 herë në rastin e operacioneve të bllokut, dmth patëm një degradim në performancën e serverit. Dhe si rezultat - degradim i performancës së aplikacionit tonë. Në të njëjtën kohë, numri i thirrjeve mbeti afërsisht në të njëjtin nivel.
Dhe gjëja kryesore këtu është të kuptoni se si të bëni migrime të tilla në mënyrë korrekte. Dhe ato duhet të bëhen. Ne i bëjmë këto migrime mjaft të qëndrueshme.
- Migrime të tilla të mëdha nuk ndodhin automatikisht. Ata duhet të jenë gjithmonë nën kontroll.
- Kërkohet mbikëqyrje nga një person i ditur. Nëse keni një DBA në ekipin tuaj, atëherë lëreni DBA-në ta bëjë atë. Është puna e tij. Nëse jo, atëherë le ta bëjë atë personi më me përvojë, i cili di të punojë me bazat e të dhënave.
- Një skemë e re e bazës së të dhënave, edhe nëse përditësojmë një kolonë, ne gjithmonë e përgatisim në faza, d.m.th paraprakisht përpara se të dalë versioni i ri i aplikacionit:
- Shtohen fusha të reja në të cilat do të regjistrojmë të dhënat e përditësuara.
- Ne transferojmë të dhënat nga fusha e vjetër në fushën e re në pjesë të vogla. Pse po e bëjmë këtë? Së pari, ne gjithmonë kontrollojmë procesin e këtij procesi. Ne e dimë që tashmë kemi transferuar kaq shumë tufa dhe na kanë mbetur shumë.
- Dhe efekti i dytë pozitiv është se midis çdo grupi të tillë mbyllim transaksionin, hapim një të re dhe kjo lejon që autovakuumi të funksionojë sipas pllakës, të shënojë linjat e fundit për ripërdorim.
- Për linjat që do të shfaqen gjatë ekzekutimit të aplikacionit (ne kemi ende aplikacionin e vjetër në punë), shtojmë një shkas që shkruan vlera të reja në fusha të reja. Në rastin tonë, kjo është shumëzim me njëqind e vlerës së vjetër.
- Nëse jemi plotësisht kokëfortë dhe duam të njëjtën fushë, atëherë pas përfundimit të të gjitha migrimeve dhe përpara se të nxjerrim një version të ri të aplikacionit, ne thjesht i riemërtojmë fushat. Të vjetrave u jepet një emër i shpikur, dhe fushat e reja u riemëruan në ato të vjetra.
- Dhe vetëm pas kësaj ne lëshojmë një version të ri të aplikacionit.
Dhe në të njëjtën kohë nuk do të marrim fryrje dhe nuk do të vuajmë për sa i përket performancës.
Këtu përfundon historia e tretë.
Dhe tani pak më shumë detaje rreth mjeteve që përmenda në tregimin e parë.
Para se të kërkoni për bloat, duhet të instaloni shtesën .
Në mënyrë që të mos keni nevojë të bëni pyetje, ne i kemi shkruar tashmë këto pyetje në punën tonë. Ju mund t'i përdorni ato. Këtu ka dy kërkesa.
- E para kërkon shumë kohë për të punuar, por do t'ju tregojë vlerat e sakta të fryrjes nga tabela.
- E dyta funksionon më shpejt dhe është shumë efektive kur duhet të vlerësoni shpejt nëse ka fryrje apo jo sipas tabelës. Dhe gjithashtu duhet të kuptoni se fryrja është gjithmonë e pranishme në një tabelë Postgres. Kjo është një veçori e modelit të saj MVCC.
- Dhe fryrja 20% është normale për tavolinat në shumicën e rasteve. Kjo është, ju nuk duhet të shqetësoheni dhe të ngjeshni këtë tabelë.
Ne kuptuam se si të identifikojmë tabelat që janë të fryra me të dhëna të padobishme.
Tani se si të rregulloni fryrjen:
- Nëse kemi një tabletë të vogël dhe disqe të mirë, domethënë në një tabletë deri në një gigabajt, është mjaft e mundur të përdorim VACUUM FULL. Ai do të marrë një bravë ekskluzive nga ju në tavolinë për disa sekonda dhe në rregull, por ai do të bëjë gjithçka shpejt dhe ashpër. Çfarë bën VACUUM FULL? Ai merr një bllokim ekskluziv në tabelë dhe rishkruan rreshtat e drejtpërdrejtë nga tabelat e vjetra në tabelën e re. Dhe në fund i zëvendëson. Fshin skedarët e vjetër dhe zëvendëson të vjetrat me të reja. Por për kohëzgjatjen e punës së saj, ajo merr një bravë ekskluzive në tavolinë. Kjo do të thotë që ju nuk mund të bëni asgjë me këtë tabelë: as t'i shkruani, as të lexoni në të, as ta modifikoni. Dhe VACUUM FULL kërkon hapësirë shtesë në disk për të shkruar të dhëna.
- Mjeti tjetër . Në parim, është shumë i ngjashëm me VACUUM FULL, sepse gjithashtu rishkruan të dhënat nga skedarët e vjetër në ato të reja dhe i zëvendëson ato në tabelë. Por në të njëjtën kohë, ai nuk merr një bllokim ekskluziv në tryezë në fillimin e punës së tij, por e merr atë vetëm në momentin kur ka tashmë të dhëna të gatshme për të zëvendësuar skedarët. Kërkesat e tij për burimet e diskut janë të ngjashme me ato të VACUUM FULL. Keni nevojë për hapësirë shtesë në disk, dhe kjo ndonjëherë është kritike nëse keni tabela terabyte. Dhe është mjaft i uritur për procesor sepse punon në mënyrë aktive me I/O.
- Shërbimi i tretë është . Është më i kujdesshëm me burimet sepse funksionon sipas parimeve paksa të ndryshme. Ideja kryesore e pgcompacttable është se ai lëviz të gjitha rreshtat e drejtpërdrejtë në fillim të tabelës duke përdorur përditësimet në tabelë. Dhe pastaj krijon një vakum në këtë tabelë, sepse ne e dimë se kemi rreshta të gjallë në fillim dhe rreshta të vdekur në fund. Dhe vetë vakuumi e pret këtë bisht, d.m.th. nuk kërkon shumë hapësirë shtesë në disk. Dhe në të njëjtën kohë, ajo ende mund të shtrydhet për sa i përket burimeve.
Gjithçka me mjete.
Nëse ju duket interesante tema e fryrjes për sa i përket kërkimit të mëtejshëm brenda, këtu janë disa lidhje të dobishme:
- - Ky është një raport nga kolegu im. Është e përgjithshme se ku shkon hapësira e Postgres gjatë punës dhe jetës së tij. Dhe ekziston një pjesë teknike shumë e madhe dhe e detajuar për administratorët e bazës së të dhënave në lidhje me fryrjen.
- – kjo është një lidhje me depon tonë, ku ruajmë një sërë skriptesh të dobishme për të kontrolluar gjendjen e bazës së të dhënave. Aty mund të gjeni skripta për të kërkuar bloat.
- и lidhje me mjetet që do t'ju ndihmojnë të tkurni shenjat.
- – Ky është një postim i kolegut tim. Aty ai analizon mjaft seriozisht dhe teknikisht fryrjen në detaje në një nivel afër administratorëve.
Unë u përpoqa më shumë për të treguar një histori horror për zhvilluesit, sepse ata janë klientët tanë të drejtpërdrejtë të bazave të të dhënave dhe duhet të kuptojnë se çfarë dhe çfarë veprimesh çojnë. Shpresoj se kam pasur sukses. Faleminderit per vemendjen!
Pyetjet tuaja
Faleminderit për raportin! Ju folët se si mund t'i identifikoni problemet. Si mund të paralajmërohen? Kjo do të thotë, unë pata një situatë ku kërkesat vareshin jo vetëm sepse kishin akses në disa shërbime të jashtme. Këto ishin vetëm disa bashkime të egra. Kishte disa kërkesa të vogla, të padëmshme që mbetën të varura për një ditë, dhe më pas filluan të bënin disa marrëzi. Kjo është, shumë e ngjashme me atë që përshkruani. Si ta gjurmoni këtë? Uluni dhe shikoni vazhdimisht se cila kërkesë ka ngecur? Si mund të parandalohet kjo?
Në këtë rast, kjo është një detyrë për administratorët e kompanisë suaj, jo domosdoshmërisht për DBA.
Unë jam një administrator.
PostgreSQL ka një pamje të quajtur pg_stat_activity që tregon pyetje të varura. Dhe ju mund të shihni se sa kohë qëndron atje.
A duhet të hyj dhe të shikoj çdo 5 minuta?
Vendosni cron dhe kontrolloni. Nëse keni një kërkesë afatgjatë, shkruani një letër dhe kaq. Kjo do të thotë, nuk keni nevojë të shikoni me sytë tuaj, mund të automatizohet. Ju do të merrni një letër, ju reagoni ndaj saj. Ose mund të qëlloni automatikisht.
A ka ndonjë arsye të dukshme pse ndodh kjo?
Unë kam renditur disa. Shembuj të tjerë më kompleks. Dhe mund të ketë një bisedë për një kohë të gjatë.
Faleminderit për raportin! Doja të sqaroja në lidhje me mjetin pg_repack. Nëse ajo nuk bën një bllokim ekskluziv, atëherë...
Ajo bën një bllokim ekskluziv.
... atëherë unë mund të humbas potencialisht të dhëna. A nuk duhet që aplikacioni im të regjistrojë asgjë gjatë kësaj kohe?
Jo, funksionon pa probleme me tabelën, d.m.th. pg_repack së pari transferon të gjitha linjat e drejtpërdrejta që ekzistojnë. Natyrisht, një lloj hyrjeje në tabelë ndodh atje. Ai thjesht po e hedh këtë bisht.
Kjo është, ai në të vërtetë e bën atë në fund?
Në fund, ai merr një bllokim ekskluziv për të shkëmbyer këto skedarë.
A do të jetë më i shpejtë se VACUUM FULL?
VACUUM FULL, sapo filloi, menjëherë mori një bravë ekskluzive. Dhe derisa të bëjë gjithçka, ai nuk do ta lërë të shkojë. Dhe pg_repack merr një bllokim ekskluziv vetëm në kohën e zëvendësimit të skedarit. Në këtë moment nuk do të shkruani aty, por të dhënat nuk do të humbasin, gjithçka do të jetë mirë.
Përshëndetje! Ju folët për funksionimin e një vakumi makine. Kishte një grafik me qeliza regjistrimi të kuqe, të verdhë dhe jeshile. Domethënë të verdha - i ka shënuar si të fshira. Dhe si rezultat, mund të shkruhet diçka e re në to?
Po. Postgres nuk fshin rreshtat. Ai ka një specifikë të tillë. Nëse përditësuam një rresht, e shënuam atë të vjetër si të fshirë. ID-ja e transaksionit që ndryshoi këtë rresht shfaqet atje dhe ne shkruajmë një rresht të ri. Dhe ne kemi sesione që mund t'i lexojnë ato. Në një moment ata bëhen mjaft të vjetër. Dhe thelbi i mënyrës se si funksionon autovakuumi është se ai kalon nëpër këto rreshta dhe i shënon ato si të panevojshme. Dhe ju mund të mbishkruani të dhënat atje.
e kuptoj. Por pyetja nuk është për këtë. Nuk mbarova. Le të supozojmë se kemi një tabelë. Ka fusha me madhësi të ndryshueshme. Dhe nëse përpiqem të fus diçka të re, ajo thjesht mund të mos përshtatet në qelizën e vjetër.
Jo, në çdo rast e gjithë linja përditësohet atje. Postgres ka dy modele të ruajtjes së të dhënave. Ai zgjedh nga lloji i të dhënave. Ka të dhëna që ruhen direkt në tabelë, dhe ka edhe të dhëna tos. Këto janë sasi të mëdha të dhënash: tekst, json. Ato ruhen në pjata të veçanta. Dhe sipas këtyre tabletave, ndodh e njëjta histori me fryrjen, pra gjithçka është njësoj. Ato thjesht janë renditur veçmas.
Faleminderit për raportin! A është e pranueshme të përdoren pyetjet e skadimit të deklaratave për të kufizuar kohëzgjatjen?
Shumë e pranueshme. Ne e përdorim këtë kudo. Dhe duke qenë se ne nuk kemi shërbimet tona, ne ofrojmë mbështetje në distancë, ne kemi një shumëllojshmëri klientësh. Dhe të gjithë janë plotësisht të kënaqur me këtë. Domethënë kemi cron jobs që kontrollojnë. Kohëzgjatja e seancave është thjesht dakord me klientin, para së cilës ne nuk jemi dakord. Mund të jetë një minutë, mund të jetë 10 minuta. Varet nga ngarkesa në bazë dhe qëllimi i saj. Por ne të gjithë përdorim pg_stat_activity.
Faleminderit për raportin! Po përpiqem të aplikoj raportin tuaj në aplikacionet e mia. Dhe duket sikur ne fillojmë një transaksion kudo, dhe qartësisht e përfundojmë atë kudo. Nëse ka ndonjë përjashtim, atëherë përsëri ndodh rikthimi. Dhe pastaj fillova të mendoj. Në fund të fundit, transaksioni mund të mos fillojë në mënyrë të qartë. Kjo ndoshta është një aluzion për vajzën. Nëse thjesht përditësoj një rekord, a do të fillojë transaksioni në PostgreSQL dhe do të përfundojë vetëm kur lidhja shkëputet?
Nëse po flisni tani për nivelin e aplikacionit, atëherë varet nga drejtuesi që po përdorni, nga ORM që po përdoret. Ka shumë cilësime atje. Nëse e keni të aktivizuar kryerjen automatike, atëherë një transaksion fillon atje dhe mbyllet menjëherë.
Kjo do të thotë, mbyllet menjëherë pas përditësimit?
Varet nga cilësimet. Unë emërova një cilësim. Ky është kryerja automatike. Është mjaft e zakonshme. Nëse është i aktivizuar, atëherë transaksioni është hapur dhe mbyllur. Nëse nuk keni thënë në mënyrë të qartë "fillimi i transaksionit" dhe "përfundimi i transaksionit", por thjesht keni nisur një kërkesë në seancë.
Përshëndetje! Faleminderit për raportin! Le të imagjinojmë se kemi një bazë të dhënash që po fryhet dhe fryhet dhe më pas hapësira në server mbaron. A ka ndonjë mjet për të rregulluar këtë situatë?
Hapësira në server duhet të monitorohet siç duhet.
Për shembull, DBA shkoi për çaj, ishte në një vendpushim, etj.
Kur krijohet një sistem skedari, të paktën krijohet një lloj hapësire rezervë ku të dhënat nuk shkruhen.
Po sikur të jetë plotësisht nën zero?
Aty quhet hapësira e rezervuar, d.m.th mund të lirohet dhe varësisht nga sa e madhe është krijuar, ju merrni hapësirë të lirë. Si parazgjedhje nuk e di sa janë. Dhe në një rast tjetër, dorëzoni disqe në mënyrë që të keni hapësirë për të kryer një operacion rindërtues. Ju mund të fshini disa tabelë që garantohet se nuk do t'ju nevojiten.
A ka ndonjë mjet tjetër?
Është gjithmonë i punuar me dorë. Dhe në nivel lokal bëhet e qartë se çfarë është më mirë të bëhet atje, sepse disa të dhëna janë kritike dhe disa jokritike. Dhe për çdo bazë të dhënash dhe aplikacionin që punon me të, varet nga biznesi. Gjithmonë vendoset në vend.
Faleminderit për raportin! Kam dy pyetje. Së pari, ju treguat rrëshqitje që treguan se kur transaksionet ngecin, rriten si madhësia e hapësirës së tabelës ashtu edhe madhësia e indeksit. Dhe më tej në raport kishte një mori shërbimesh që paketonin tabletin. Po indeksi?
Edhe ato i paketojnë.
Por vakuumi nuk ndikon në indeks?
Disa punojnë me një indeks. Për shembull, pg_rapack, pgcompacttable. Vakuumi rikrijon indekset dhe ndikon në to. Me VACUUM FULL ideja është të mbishkruash gjithçka, d.m.th. funksionon me të gjithë.
Dhe pyetja e dytë. Nuk e kuptoj pse raportet për kopjet varen kaq shumë nga vetë përsëritja. Më dukej se raportet lexohen, dhe përsëritja është shkrim.
Çfarë e shkakton një konflikt replikimi? Ne kemi një Master mbi të cilin zhvillohen proceset. Ne kemi një vakum në makinë. Çfarë bën në të vërtetë një autovakum? Ai po shkurton disa rreshta të vjetër. Nëse në këtë kohë kemi një kërkesë për replikën që lexon këto rreshta të vjetër dhe tek Master ka ndodhur një situatë që autovakuumi i ka shënuar këto rreshta si të mundshme për mbishkrim, atëherë ne i shkruajmë ato. Dhe ne morëm një paketë të dhënash, kur duhet të rishkruajmë ato rreshta që i duhen kërkesës në kopje, procesi i replikimit do të presë për afatin që keni konfiguruar. Dhe më pas PostgreSQL do të vendosë se çfarë është më e rëndësishme për të. Dhe replikimi është më i rëndësishëm për të sesa kërkesa, dhe ai do ta shkrepë kërkesën për të bërë këto ndryshime në replikë.
Andrey, kam një pyetje. Këto grafikë të mrekullueshëm që treguat gjatë prezantimit, a janë këto rezultat i punës së një lloji të dobisë suaj? Si janë bërë grafikët?
Ky është një shërbim .
A është ky një produkt komercial?
Po. Ky është një produkt komercial.
Burimi: www.habr.com