Ik stel foar dat jo it transkripsje fan it rapport fan it begjin fan 2016 lêze troch Andrey Salnikov "Typyske flaters yn applikaasjes dy't liede ta bloat yn postgresql"
Yn dit rapport sil ik de wichtichste flaters analysearje yn applikaasjes dy't ûntsteane yn it stadium fan it ûntwerpen en skriuwen fan applikaasjekoade. En ik sil allinich de flaters nimme dy't liede ta bloat yn Postgresql. As regel is dit it begjin fan 'e ein fan' e prestaasjes fan jo systeem as gehiel, hoewol yn 't earstoan gjin betingsten foar dit wiene sichtber.
Bliid om elkenien wolkom te hjitten! Dit rapport is net sa technysk as it foarige fan myn kollega. Dit rapport is benammen rjochte op ûntwikkelders fan backend-systeem, om't wy in frij grut oantal kliïnten hawwe. En se meitsje allegear deselde flaters. Ik sil dy oer harren fertelle. Ik sil útlizze hokker fatale en minne dingen dizze flaters liede ta.
Wêrom wurde flaters makke? Se wurde dien foar twa redenen: willekeurich, miskien sil it wurkje en fanwege ûnwittendheid fan guon meganismen dy't foarkomme op it nivo tusken de databank en de applikaasje, likegoed as yn de databank sels.
Ik jou jim trije foarbylden mei ferskriklike foto's fan hoe slim it gie. Ik sil jo koart fertelle oer it meganisme dat dêr bart. En hoe om te gean mei harren, doe't se bard, en hokker previntive metoaden te brûken om foar te kommen flaters. Ik sil jo fertelle oer de helpmiddels en nuttige keppelings leverje.
Ik brûkte in test databank dêr't ik hie twa tabellen. Ien plaat mei klant akkounts, de oare mei transaksjes op dizze akkounts. En mei wat frekwinsje aktualisearje wy de saldo's op dizze akkounts.
Inisjele gegevens fan 'e plaat: it is frij lyts, 2 MB. De reaksjetiid foar de databank en spesifyk foar it teken is ek heul goed. En in frij goede lading - 2 operaasjes per sekonde neffens de plaat.
En fia dit rapport sil ik jo grafiken sjen litte, sadat jo dúdlik kinne begripe wat der bart. D'r sille altyd 2 dia's mei grafiken wêze. De earste slide is wat bart yn it algemien op de tsjinner.
En yn dizze situaasje sjogge wy dat wy echt in lyts teken hawwe. De yndeks is lyts op 2 MB. Dit is de earste grafyk oan de linkerkant.
De gemiddelde reaksjetiid op 'e tsjinner is ek stabyl en koart. Dit is de top rjochts grafyk.
De grafyk links ûnder toant de langste transaksjes. Wy sjogge dat transaksjes fluch wurde foltôge. En it autovacuum wurket hjir noch net, want it wie in starttest. It sil trochgean te wurkjen en sil nuttich wêze foar ús.
De twadde slide sil altyd wijd wurde oan de plaat dy't wurdt hifke. Yn dizze situaasje aktualisearje wy de akkountsaldo's fan 'e kliïnt konstant. En wy sjogge dat de gemiddelde reaksjetiid foar in update operaasje is frij goed, minder as in millisekonde. Wy sjogge dat prosessorboarnen (dit is de grafyk rjochts boppe) ek evenredich en frij lyts wurde konsumearre.
De grafyk rjochts ûnder lit sjen hoefolle bestjoerings- en skiifûnthâld wy geane troch op syk nei ús winske line foardat it bywurkjen fan it. En it oantal operaasjes neffens it teken is 2 per sekonde, lykas ik sei oan it begjin.
En no hawwe wy in trageedzje. Om ien of oare reden is d'r in lang fergetten transaksje. De redenen binne normaal allegear banaal:
- Ien fan 'e meast foarkommende is dat wy tagong hawwe ta in eksterne tsjinst yn' e applikaasjekoade. En dizze tsjinst antwurdet ús net. Dat is, wy hawwe in transaksje iepene, in feroaring yn 'e database makke en gongen fan' e applikaasje om e-post te lêzen of nei in oare tsjinst binnen ús ynfrastruktuer, en om ien of oare reden reagearret it net op ús. En ús sesje sit fêst yn in steat wêr't it ûnbekend is wannear't it sil wurde oplost.
- De twadde situaasje is as in útsûndering foarkaam yn ús koade om ien of oare reden. En yn 'e útsûndering hawwe wy it sluten fan' e transaksje net ferwurke. En wy einige mei in hingjende sesje mei in iepen transaksje.
- En de lêste is ek in frij gewoan gefal. Dit is lege kwaliteit koade. Guon kaders iepenje in transaksje. It hinget, en jo meie net witte yn de applikaasje dat jo hawwe it hingjen.
Wêr liede sokke dingen ta?
Oan it punt dat ús tabellen en yndeksen dramatysk begjinne te swollen. Dit is krekt itselde bloat-effekt. Foar de databank sil dit betsjutte dat de responstiid fan 'e databank tige skerp sil tanimme en de lading op' e databanktsjinner sil tanimme. En as gefolch sil ús applikaasje lije. Want as jo trochbrocht 10 millisekonden yn jo koade op in fersyk oan de databank, 10 millisekonden op jo logika, dan dyn funksje naam 20 millisekonden te foltôgjen. En no sil jo situaasje tige tryst wêze.
En lit ús sjen wat der bart. De grafyk links ûnder lit sjen dat wy in lange lange transaksje hawwe. En as wy nei de boppeste loftergrafyk sjogge, sjogge wy dat de grutte fan ús tabel ynienen sprong fan twa megabytes nei 300 megabytes. Tagelyk is de hoemannichte gegevens yn 'e tabel net feroare, d.w.s. d'r is dêr in frijwat grut bedrach fan jiskefet.
De algemiene situaasje oangeande de gemiddelde tsjinner reaksjetiid is ek feroare troch ferskate oarders fan grutte. Dat is, alle oanfragen op 'e tsjinner begon folslein te fallen. En tagelyk waarden ynterne Postgres-prosessen lansearre yn 'e foarm fan autovacuum, dy't besykje wat te dwaan en boarnen te konsumearjen.
Wat bart der mei ús teken? Itselde. Us gemiddelde reaksjetiid neffens it teken is ferskate oarders fan grutte sprongen. Spesifyk yn termen fan konsumearre boarnen, sjogge wy dat de lading op 'e prosessor sterk tanommen is. Dit is de top rjochts grafyk. En it is tanommen omdat de prosessor moat sortearje troch in bosk nutteleaze rigels op syk nei de iene nedich. Dit is de grafyk ûnder rjochts. En as gefolch begon ús oantal oproppen per sekonde heul signifikant te sakjen, om't de databank gjin tiid hie om itselde oantal oanfragen te ferwurkjen.
Wy moatte werom nei it libben. Wy geane online en fine út dat lange transaksjes liede ta problemen. Wy fine en deadzje dizze transaksje. En alles wurdt normaal foar ús. Alles wurket sa't it moat.
Wy binne rêstich, mar nei in skoft begjinne wy te merken dat de applikaasje net op deselde manier wurket as foar de need. Oanfragen wurde noch stadiger ferwurke, en signifikant stadiger. Ien en in heal oant twa kear stadiger spesifyk yn myn foarbyld. De lading op de tsjinner is ek heger as foar it ûngelok.
En de fraach: "Wat bart der op dit stuit mei de basis?" En de folgjende situaasje bart mei de basis. Op it transaksjediagram kinne jo sjen dat it stoppe is en d'r echt gjin transaksjes op lange termyn binne. Mar de grutte fan it teken naam deadlik ta by it ûngelok. En sûnt dy tiid binne se net minder wurden. De gemiddelde tiid op 'e basis is stabilisearre. En de antwurden lykje adekwaat te kommen mei in foar ús akseptabel snelheid. It autovacuum waard aktyfer en begon wat te dwaan mei it teken, om't it mear gegevens moat siftje.
Spesifyk, neffens de test plaat mei rekkens, dêr't wy feroarje saldo: de reaksje tiid foar in fersyk liket te hawwen werom nei normaal. Mar yn werklikheid is it ien en in heal kear heger.
En út 'e lading op' e prosessor sjogge wy dat de lading op 'e prosessor net werom is nei de fereaske wearde foar it ûngelok. En de redenen dêr lizze krekt yn de grafyk ûnder rjochts. It is te sjen dat der in bepaalde hoemannichte ûnthâld trochsocht wurdt. Dat is, om de fereaske line te finen, fergrieme wy de boarnen fan 'e databanktsjinner by it sortearjen troch nutteleaze gegevens. It oantal transaksjes per sekonde is stabilisearre.
Oer it algemien goed, mar de situaasje is slimmer dan it wie. Dúdlik databankdegradaasje as gefolch fan ús applikaasje dy't wurket mei dizze databank.
En om te begripen wat der bart, as jo net by it foarige rapport wiene, litte wy no in bytsje teory krije. Teory oer it ynterne proses. Wêrom in auto stofzuiger en wat docht it?
Letterlik koart foar begryp. Op in stuit hawwe wy in tafel. Wy hawwe rigen yn 'e tabel. Dizze rigels kinne aktyf wêze, libje, en wat wy no nedich binne. Se binne markearre yn grien op de foto. En d'r binne deadlines dy't al binne útwurke, binne bywurke, en nije yngongen binne op har ferskynd. En se wurde markearre dat se net mear ynteressant binne foar de databank. Mar se binne yn 'e tabel troch in Postgres-funksje.
Wêrom hawwe jo in auto fakuüm nedich? Op in stuit komt it autofakuüm, tagong ta de database en freget it: "Jou my asjebleaft de id fan 'e âldste transaksje dy't op it stuit iepen is yn' e database." De databank jout dizze id werom. En it autovacuum, ôfhinklik fan it, sortearret troch de rigels yn 'e tabel. En as hy sjocht dat guon rigels feroare binne troch folle âldere transaksjes, dan hat hy it rjocht om se te markearjen as rigels dy't wy yn 'e takomst opnij brûke kinne troch dêr nije gegevens te skriuwen. Dit is in eftergrûnproses.
Op dit stuit, wy fierder te wurkjen mei de databank en fierder te meitsje wat feroarings oan de tabel. En op dizze rigels, dy't wy opnij brûke kinne, skriuwe wy nije gegevens. En sa krije wy in syklus, d.w.s. hieltyd komme der wat deade âlde rigels op, ynstee dêrfan skriuwe wy nije rigels op dy't wy nedich hawwe. En dit is in normale steat foar PostgreSQL om te wurkjen.
Wat barde by it ûngelok? Hoe barde dit proses dêr?
Wy hiene in teken yn guon steat, guon live, guon deade rigels. De auto stofzuiger is oankaam. Hy frege de databank wat ús âldste transaksje is en wat syn id is. Ik krige dizze id, dy't in protte oeren lyn koe wêze, miskien tsien minuten lyn. It hinget ôf fan hoe swier de lading jo hawwe op jo databank. En hy gong op syk nei rigels dy't er as opnij brûkt markearje koe. En ik fûn sokke rigels net yn ús tabel.
Mar op dit stuit wurkje wy fierder mei de tafel. Wy dogge der wat yn, aktualisearje it, feroarje de gegevens. Wat moat de databank op dit stuit dwaan? Se hat gjin oare kar as in foegjen nije rigels oan 'e ein fan' e besteande tabel. En sa begjint ús tafelgrutte te swollen.
Yn werklikheid hawwe wy griene linen nedich om te wurkjen. Mar tidens sa'n probleem docht bliken dat it persintaazje griene linen is ekstreem leech troch de hiele tabel.
En as wy in query útfiere, moat de databank troch alle rigels gean: sawol read as grien, om de winske line te finen. En it effekt fan it opblazen fan in tabel mei nutteleaze gegevens wurdt "bloat" neamd, dy't ek ús skiifromte opfet. Unthâld, it wie 2 MB, it waard 300 MB? Feroarje no megabytes nei gigabytes en jo sille al jo skiifboarnen fluch ferlieze.
Hokker gefolgen kinne der foar ús wêze?
- Yn myn foarbyld groeide de tabel en yndeks 150 kear. Guon fan ús kliïnten hawwe mear fatale gefallen hân doe't se gewoan begon te rinnen fan skiifromte.
- De grutte fan 'e tabellen sels sil nea ôfnimme. Autovacuum kin yn guon gefallen de sturt fan 'e tafel ôfsnien wurde as d'r allinich deadlinen binne. Mar om't d'r konstante rotaasje is, kin ien griene line oan 'e ein befrieze en net bywurke wurde, wylst alle oaren earne oan it begjin fan' e plaat opskreaun wurde. Mar dit is sa'n ûnwierskynlik barren dat jo tafel sels yn grutte sil krimpe, dus jo moatte der net op hoopje.
- De databank moat troch in hiele bosk nutteleaze rigels sortearje. En wy fergrieme skiif boarnen, wy fergrieme prosessor middels en elektrisiteit.
- En dit hat direkte ynfloed op ús applikaasje, om't as wy yn it begjin 10 millisekonden bestege oan it fersyk, 10 millisekonden oan ús koade, dan begon wy yn 'e crash in sekonde te besteegjen oan it fersyk en 10 millisekonden oan' e koade, dus in bestelling fan omfang yn applikaasje prestaasjes fermindere. En doe't it ûngelok waard oplost, wy begûn te besteegjen 20 millisekonden op in fersyk, 10 millisekonden op in koade. Dat betsjut dat wy noch oardel kear sakken yn produktiviteit. En dit alles komt troch ien transaksje dy't beferzen, miskien troch ús skuld.
- En de fraach: “Hoe kinne we alles werom krije?” sadat alles goed mei ús komt en fersykjes binnen komme as foar it ûngelok.
Foar dit doel is der in bepaalde syklus fan wurk dat wurdt útfierd.
Earst moatte wy de problematyske tabellen fine dy't opblaasd binne. Wy begripe dat yn guon tabellen de opname aktyf is, yn oaren minder aktyf. En dêrfoar brûke wy de útwreiding . Troch dizze tafoeging te ynstallearjen, kinne jo fragen skriuwe dy't jo sille helpe tabellen te finen dy't frijwat opblaasd binne.
As jo dizze tabellen hawwe fûn, moatte jo se komprimearje. Dêr binne al ark foar. Yn ús bedriuw brûke wy trije ark. De earste is de ynboude VACUUM FULL. Hy is wreed, hurd en genedeleas, mar soms is hy tige nuttich. и - Dit binne nutsbedriuwen fan tredden foar it komprimearjen fan tabellen. En se behannelje de databank foarsichtiger.
Se wurde brûkt ôfhinklik fan wat is handiger foar jo. Mar ik sil jo hjiroer oan 'e ein fertelle. It wichtichste is dat d'r trije ark binne. D'r binne genôch om út te kiezen.
Nei't wy alles hawwe korrizjearre en derfoar soarge dat alles goed is, moatte wy witte hoe't wy dizze situaasje yn 'e takomst kinne foarkomme:
- It kin frij maklik foarkommen wurde. Jo moatte de doer fan sesjes kontrolearje op 'e Master-tsjinner. Benammen gefaarlike sesjes yn idle yn transaksje tastân. Dit binne dejingen dy't krekt in transaksje hawwe iepene, wat diene en ferlieten, of gewoan hingje, ferlern gien yn 'e koade.
- En foar jo, as ûntwikkelders, is it wichtich om jo koade te testen as dizze situaasjes ûntsteane. It is net dreech om te dwaan. Dit sil in nuttige kontrôle wêze. Jo sille in grut oantal "bernelike" problemen foarkomme dy't ferbûn binne mei lange transaksjes.
Yn dizze grafiken woe ik jo sjen litte hoe't it teken en it gedrach fan 'e database feroare nei't ik yn dit gefal troch it teken gie mei VACUUM FULL. Dit is gjin produksje foar my.
De tabelgrutte kaam fuortendaliks werom nei syn normale bestjoeringsstân fan in pear megabytes. Dit hat gjin grutte ynfloed op de gemiddelde reaksjetiid foar de tsjinner.
Mar spesifyk foar ús test teken, dêr't wy bywurke account saldo, wy sjogge dat de gemiddelde antwurd tiid foar in fersyk om te aktualisearjen gegevens yn it teken waard fermindere ta pre-emergency nivo. De boarnen konsumearre troch de prosessor om dit fersyk te foltôgjen sakke ek nei pre-crash-nivo's. En de grafyk rjochts ûnder lit sjen dat wy no krekt de line fine dy't wy daliks nedich hawwe, sûnder troch de stapels deade linen te gean dy't der wiene foardat de tafel waard komprimearre. En de gemiddelde oanfraachtiid bleau sawat op itselde nivo. Mar hjir haw ik leaver in flater yn myn hardware.
Dit is wêr't it earste ferhaal einiget. It is de meast foarkommende. En it bart mei elkenien, nettsjinsteande de ûnderfining fan 'e kliïnt en hoe kwalifisearre de programmeurs binne. Ier of let bart dit.
It twadde ferhaal, wêryn wy de lading fersprieden en serverboarnen optimalisearje
- Wy binne al grut wurden en serieuze jonges wurden. En wy begripe dat wy in replika hawwe en it soe goed wêze foar ús om de lading te balansearjen: skriuw nei de Master, en lês út 'e replika. En meastal dizze situaasje ûntstiet as wy wolle tariede guon rapporten of ETL. En it bedriuw is hjir tige bliid mei. Hy wol wirklik in ferskaat oan rapporten mei in protte komplekse analytiken.
- Rapporten duorje in protte oeren, om't komplekse analytiken net yn millisekonden kinne wurde berekkene. Wy, lykas dappere jonges, skriuwe koade. Yn 'e ynfoegjeapplikaasje meitsje wy de opname op' e Master, en fiere de rapporten oer de replika út.
- Fersprieding fan de lading.
- Alles wurket perfekt. Wy binne geweldich.
En hoe sjocht dizze situaasje der út? Spesifyk op dizze grafiken haw ik ek de doer fan transaksjes fan 'e replika tafoege foar de transaksjedoer. Alle oare grafiken ferwize allinnich nei de Master tsjinner.
Tsjin dy tiid wie myn rapportboerd groeid. Der binne mear fan harren. Wy sjogge dat de gemiddelde antwurdtiid fan 'e server stabyl is. Wy sjogge dat wy op 'e replika in langrinnende transaksje hawwe dy't 2 oeren rint. Wy sjogge de stille wurking fan 'e autovacuum, dy't deadlinen ferwurket. En alles is goed mei ús.
Spesifyk, neffens de teste plaat, bliuwe wy troch mei it bywurkjen fan akkountsaldo's dêr. En wy hawwe ek in stabile antwurd tiid foar oanfragen, stabile boarne konsumpsje. Alles is goed mei ús.
Alles is goed oant it momint dat dizze rapporten begjinne werom te sjitten fanwege in konflikt mei replikaasje. En se fjoer werom mei geregelde tuskenskoften.
Wy geane online en begjinne te lêzen wêrom dit bart. En wy fine in oplossing.
De earste oplossing is it fergrutsjen fan de replikaasje latency. Wy witte dat ús rapport rint foar 3 oeren. Wy sette de replikaasjefertraging op 3 oeren. Wy lansearje alles, mar wy bliuwe noch hieltyd problemen mei rapporten dy't soms annulearre wurde.
Wy wolle dat alles perfekt is. Wy klimme fierder. En wy fûnen in koele ynstelling op it ynternet - hot_standby_feedback. Litte wy it oansette. Hot_standby_feedback lit ús it autovacuum op 'e Master weromhâlde. Sa komme wy folslein kwyt fan replikaasjekonflikten. En alles wurket goed foar ús mei rapporten.
En wat bart der op dit stuit mei de Master-tsjinner? En wy binne yn totale problemen mei de Master-tsjinner. No sjogge wy de grafiken as ik dizze beide ynstellingen ynskeakele haw. En wy sjogge dat de sesje op ús replika op ien of oare manier de situaasje op 'e Master-tsjinner begon te beynfloedzjen. Se hat wol in effekt, om't se it autovacuum ûnderbrekke, wat de deadlinen opheft. Us tafelgrutte is wer omheech gien. De gemiddelde útfieringstiid fan query's oer de heule databank rûn ek op. De autovacuums waarden wat oanskerpe.
Spesifyk, fan ús plaat, sjogge wy dat de gegevensfernijing derop ek nei de loften sprongen. CPU-konsumpsje is lykwols sterk tanommen. Wy geane wer troch in grut tal deade, nutteleaze rigels. En de reaksjetiid foar dit teken en it oantal transaksjes binne sakke.
Hoe sil it der útsjen as wy net witte wêr't ik it earder oer hie?
- Wy begjinne op syk nei problemen. As wy tsjinkaam problemen yn it earste diel, wy witte dat dit kin wêze troch in lange transaksje en gean nei de Master. Wy hawwe in probleem mei de Master. Worst him. It ferwaarmt, syn Load Gemiddelde is sawat hûndert.
- Fersiken binne der stadich, mar wy sjogge gjin lange-rinnende transaksjes dêr. En wy begripe net wat der oan de hân is. Wy begripe net wêr't wy moatte sykje.
- Wy kontrolearje tsjinner apparatuer. Miskien is ús oerfal ferûngelokke. Miskien is ús memory stick útbaarnd. Ja, alles kin barre. Mar nee, de servers binne nij, alles wurket goed.
- Elkenien rint: behearders, ûntwikkelders en de direkteur. Neat helpt.
- En op in stuit begjint alles ynienen himsels te korrigearjen.
Op dit stuit waard it fersyk op ús replika ferwurke en ferlitten. Wy hawwe it rapport krigen. It bedriuw is noch altyd bliid. Sa't jo sjen kinne, is ús teken wer groeid en sil net krimp. Op 'e grafyk mei sesjes liet ik in stik fan dizze lange transaksje fan in replika litte, sadat jo kinne skatte hoe lang it duorret oant de situaasje stabilisearret.
De sesje is foarby. En pas nei in skoft komt de server min of mear yn oarder. En de gemiddelde antwurdtiid foar oanfragen op 'e Master-tsjinner komt werom nei normaal. Om't, úteinlik, it autovacuum de kâns hat om dizze deade rigels skjin te meitsjen en te markearjen. En hy begon syn wurk te dwaan. En hoe fluch hy it docht, sa gau komme wy yn oarder.
Neffens de testen tablet, wêr't wy akkountsaldo's bywurkje, sjogge wy krekt deselde foto. De gemiddelde tiid bywurking fan akkount wurdt ek stadichoan normalisearjend. De boarnen konsumearre troch de prosessor wurde ek fermindere. En it oantal transaksjes per sekonde komt werom nei normaal. Mar wer binne wy werom nei normaal, net itselde as foar it ûngelok.
Yn alle gefallen krije wy, lykas yn it earste gefal, ien en in heal oant twa kear, en soms mear.
Wy lykje alles goed dien te hawwen. Fersprieden de lading. De apparatuer is net idle. Wy hawwe de oanfragen ferdield neffens ús ferstân, mar dochs rûn alles min.
- Hot_standby_feedback net ynskeakelje? Ja, it is net oan te rieden om it yn te skeakeljen sûnder bysûndere sterke redenen. Om't dizze twist direkt de Master-tsjinner beynfloedet en de wurking fan it autovacuum dêr ophâldt. Troch it yn te skeakeljen op guon replika en it te ferjitten, kinne jo de Master deadzje en grutte problemen krije mei de applikaasje.
- max_standby_streaming_delay fergrutsje? Ja, foar rapporten is dit wier. As jo in rapport fan trije oeren hawwe en jo net wolle dat it crasht fanwege replikaasjekonflikten, ferheegje dan gewoan de fertraging. In rapport op lange termyn fereasket noait gegevens dy't op it stuit yn 'e databank binne oankommen. As jo it trije oeren hawwe, dan rinne jo it foar wat âlde gegevensperioade. En foar jo, oft der in fertraging fan trije oeren of seis oeren fertraging sil gjin ferskil meitsje, mar jo krije rapporten konsekwint en sil gjin problemen hawwe mei dat se falle.
- Fansels moatte jo lange sesjes op replika's kontrolearje, foaral as jo beslute om hot_standby_feedback op in replika yn te skeakeljen. Want alles kin barre. Wy joegen dizze replika oan de ûntwikkelder sadat hy de fragen koe testen. Hy skreau in gek fersyk. Hy lansearre it en gie fuort om tee te drinken, en wy krigen de oprjochte Master. Of miskien sette wy dêr de ferkearde applikaasje yn. De situaasjes binne ferskillend. Sesjes op replika's moatte sa soarchfâldich kontrolearre wurde as op 'e Master.
- En as jo rappe en lange fragen hawwe oer replika's, dan is it yn dit gefal better om se te splitsen om de lading te fersprieden. Dit is in keppeling nei streaming_delay. Foar rappe, hawwe ien replika mei in lytse replikaasjefertraging. Foar langrinnende rapportaazjefragen, hawwe in replika dy't 6 oeren as in dei kin efterlitte. Dit is in folslein normale situaasje.
Wy eliminearje de gefolgen op deselde manier:
- Wy fine opblaasde tabellen.
- En wy komprimearje it mei it meast handige ark dat by ús past.
It twadde ferhaal einiget hjir. Litte wy nei it tredde ferhaal gean.
Ek frij gewoan foar ús wêryn wy migraasje dogge.
- Elk softwareprodukt groeit. De easken dêrfoar feroarje. Wy wolle ús yn alle gefallen ûntwikkelje. En it bart dat wy de gegevens yn 'e tabel moatte bywurkje, nammentlik om in update út te fieren yn termen fan ús migraasje foar de nije funksjonaliteit dy't wy yntrodusearje as ûnderdiel fan ús ûntwikkeling.
- It âlde gegevensformaat is net befredigjend. Litte wy sizze dat wy no nei de twadde tabel gean, wêr't ik transaksjes haw op dizze akkounts. En lit ús sizze dat se wiene yn roebel, en wy besletten om te fergrutsjen de krektens en doch it yn kopecks. En hjirfoar moatte wy in update meitsje: fermannichfâldigje it fjild mei it transaksjebedrach mei hûndert.
- Yn 'e hjoeddeistige wrâld brûke wy automatisearre ark foar kontrôle fan databaseferzjes. Litte we sizze . Dêr registrearje wy ús migraasje. Wy testen it op ús testbasis. Alles is ynoarder. De fernijing giet troch. It blokkearret wurk foar in skoft, mar wy krije bywurke gegevens. En wy kinne nije funksjonaliteit op dizze lansearje. Alles waard hifke en kontrolearre. Alles waard befêstige.
- Wy hawwe pland wurk útfierd en migraasje útfierd.
Hjir is de migraasje mei de update foar jo presintearre. Sûnt dit binne myn akkount transaksjes, wie de plaat 15 GB. En om't wy elke rigel bywurkje, ferdûbele wy de grutte fan 'e tafel mei de fernijing, om't wy elke rigel opnij skreaun hawwe.
Tidens de migraasje koenen wy neat mei dizze plaat dwaan, om't alle oanfragen dêre yn 'e wachtrige waarden en wachte oant dizze fernijing foltôge wie. Mar hjir wol ik jo omtinken jaan oan de nûmers dy't op 'e fertikale as steane. Dat is, wy hawwe in gemiddelde oanfraachtiid foar migraasje fan sawat 5 millisekonden en de prosessorlading, it oantal blokoperaasjes foar it lêzen fan skiifûnthâld is minder dan 7,5.
Wy hawwe de migraasje útfierd en krigen wer problemen.
De migraasje wie suksesfol, mar:
- De âlde funksjonaliteit duorret no langer om te foltôgjen.
- De tafel groeide wer yn omfang.
- De lading op de tsjinner waard wer grutter as earder.
- En wy binne fansels noch oan it tinken mei de funksjonaliteit dy't goed wurke, wy hawwe it in bytsje ferbettere.
En dit is wer bloat, dy't ús libben wer ferneatiget.
Hjir demonstrearje ik dat de tafel, lykas de foarige twa gefallen, net weromkomt nei syn foarige grutte. De gemiddelde serverlading liket adekwaat te wêzen.
En as wy keare nei de tafel mei akkounts, wy sille sjen dat de gemiddelde fersyk tiid hat ferdûbele foar dizze tabel. De lading op de prosessor en it oantal rigels sortearre út yn it ûnthâld sprong boppe 7,5, mar wie leger. En it sprong 2 kear yn 't gefal fan processors, 1,5 kear yn' t gefal fan blokoperaasjes, d.w.s. wy krigen in degradaasje yn serverprestaasjes. En as gefolch - degradaasje fan 'e prestaasjes fan ús applikaasje. Tagelyk bleau it tal oproppen sawat op itselde nivo.
En it wichtichste ding hjir is om te begripen hoe't jo sokke migraasjes korrekt dwaan. En se moatte dien wurde. Wy dogge dizze migraasjes frij konsekwint.
- Sokke grutte migraasjes komme net automatysk foar. Se moatte altyd ûnder kontrôle wêze.
- Tafersjoch troch in betûfte persoan is nedich. As jo in DBA yn jo team hawwe, lit de DBA it dan dwaan. It is syn wurk. Sa net, lit dan de meast betûfte persoan dwaan, dy't wit hoe te wurkjen mei databases.
- In nij databankskema, sels as wy ien kolom bywurkje, meitsje wy ús altyd yn stadia ta, dat wol sizze foarôf foardat de nije ferzje fan 'e applikaasje wurdt útrôle:
- Nije fjilden wurde tafoege wêryn wy de bywurke gegevens sille opnimme.
- Wy drage gegevens oer fan it âlde fjild nei it nije fjild yn lytse dielen. Wêrom dogge wy dit? As earste kontrolearje wy it proses fan dit proses altyd. Wy witte dat wy al safolle batches oerdroegen hawwe en dat wy noch safolle oer hawwe.
- En it twadde positive effekt is dat wy tusken elke sa'n batch de transaksje slute, in nije iepenje, en dit lit it autovacuum wurkje neffens de plaat, markearje deadlinen foar werbrûk.
- Foar de rigels dy't sille ferskine wylst de applikaasje rint (wy hawwe noch altyd de âlde applikaasje rint), foegje wy in trigger ta dy't nije wearden skriuwt nei nije fjilden. Yn ús gefal is dit fermannichfâldigje mei hûndert fan 'e âlde wearde.
- As wy folslein koppich binne en itselde fjild wolle, dan nei it foltôgjen fan alle migraasjes en foardat wy in nije ferzje fan 'e applikaasje útrolje, feroarje wy de fjilden gewoan. De âlde wurde jûn wat útfûn namme, en de nije fjilden wurde omneamd ta de âlde.
- En pas dêrnei lansearje wy in nije ferzje fan 'e applikaasje.
En tagelyk sille wy gjin blaas krije en sille net lije yn termen fan prestaasjes.
Dit is wêr't it tredde ferhaal einiget.
En no in bytsje mear detail oer de ark dy't ik neamde yn it earste ferhaal.
Foardat jo sykje nei bloat, moatte jo de tafoeging ynstallearje .
Dat jo net mei fragen hoege te kommen, hawwe wy dizze fragen al skreaun yn ús wurk. Jo kinne se brûke. Hjir binne twa oanfragen.
- De earste duorret nochal lang om te wurkjen, mar it sil jo de krekte bloatwearden sjen litte fan 'e tabel.
- De twadde wurket rapper en is tige effektyf as jo fluch moatte beoardielje oft der in blaas is of net neffens de tabel. En jo moatte ek begripe dat bloat altyd oanwêzich is yn in Postgres-tabel. Dit is in skaaimerk fan har MVCC-model.
- En 20% bloat is normaal foar tabellen yn de measte gefallen. Dat is, jo moatte gjin soargen meitsje en dizze tabel komprimearje.
Wy hawwe útfûn hoe't jo tabellen identifisearje dy't swollen binne mei nutteleaze gegevens.
No oer hoe't jo bloat reparearje:
- As wy in lytse tablet en goede skiven hawwe, dat is, op in tablet oant in gigabyte, is it hiel mooglik om VACUUM FULL te brûken. Hy sil nimme in eksklusive slot fan jo op 'e tafel foar in pear sekonden en okee, mar hy sil dwaan alles fluch en hurd. Wat docht VACUUM FULL? It nimt in eksklusyf slot op 'e tafel en skriuwt live rigen fan' e âlde tabellen yn 'e nije tafel. En op it lêst ferfangt er se. It wisket âlde bestannen en ferfangt de âlde mei nije. Mar foar de doer fan syn wurk, it nimt in eksklusyf slot op 'e tafel. Dit betsjut dat jo neat mei dizze tabel dwaan kinne: der net nei skriuwe, noch ynlêze, noch wizigje. En VACUUM FULL fereasket ekstra skiifromte om gegevens te skriuwen.
- Folgjende ark . Yn syn prinsipe is it heul gelyk oan VACUUM FULL, om't it ek gegevens fan âlde bestannen nei nije skriuwt en ferfangt se yn 'e tabel. Mar tagelyk nimt it net oan it begjin fan syn wurk in eksklusyf slot op 'e tafel, mar nimt it allinich op it momint dat it al kleare gegevens hat om de bestannen te ferfangen. De easken foar skiifboarnen binne fergelykber mei dy fan VACUUM FULL. Jo moatte ekstra skiif romte, en dit is soms kritysk as jo terabyte tabellen. En it is frij prosessor-hongerich, om't it aktyf wurket mei I / O.
- It tredde nut is . It is foarsichtiger mei boarnen, om't it wurket neffens wat oare prinsipes. It haadidee fan pgcompacttable is dat it alle live rigen ferpleatst nei it begjin fan 'e tabel mei help fan updates yn' e tabel. En dan rint it in fakuüm op dizze tafel, want wy witte dat wy hawwe live rigen oan it begjin en deade rigen oan 'e ein. En it fakuüm sels snijt dizze sturt ôf, dat wol sizze dat it net folle ekstra skiifromte nedich is. En tagelyk kin it noch squeeze wurde yn termen fan middels.
Alles mei ark.
As jo it bloat-ûnderwerp ynteressant fine yn termen fan ferdjipje fierder binnen, binne hjir wat nuttige keppelings:
- - Dit is in ferslach fan myn kollega. It giet algemien oer wêr't de romte fan Postgres hinne giet yn syn wurk en libben. En d'r is in heul grut en detaillearre technysk stik foar databasebehearders oer bloat.
- - dit is in keppeling nei ús repository, wêr't wy in boskje nuttige skripts opslaan foar it kontrolearjen fan de steat fan 'e databank. Dêr kinne jo skripts fine om te sykjen nei bloat.
- и keppelings nei ark dy't jo sille helpe tekens te krimpjen.
- - dit is in post fan myn kollega. Dêr analysearret hy heul serieus en technysk bloat yn detail op in nivo tichtby behearders.
Ik besocht mear om in horrorferhaal foar ûntwikkelders sjen te litten, om't se ús direkte kliïnten fan databases binne en moatte begripe wat en hokker aksjes liede ta. Ik hoopje dat ik slagge. Tank foar jo oandacht!
Jo fragen
Tank foar it ferslach! Jo hawwe praat oer hoe't jo problemen kinne identifisearje. Hoe kinne se warskôge wurde? Dat is, ik hie in situaasje wêr't oanfragen net allinich hingje om't se tagong hawwe ta guon eksterne tsjinsten. Dit wiene gewoan wat wylde joins. D'r wiene wat lytse, harmless oanfragen dy't in dei hingje, en doe begongen te dwaan wat ûnsin. Dat is, heul gelyk oan wat jo beskriuwe. Hoe kinne jo dit folgje? Sitte en konstant sjen hokker fersyk is fêst? Hoe kin dit foarkommen wurde?
Yn dit gefal is dit in taak foar de behearders fan jo bedriuw, net needsaaklik foar de DBA.
Ik bin in behearder.
PostgreSQL hat in werjefte neamd pg_stat_activity dy't dangling queries toant. En jo kinne sjen hoe lang it dêr hinget.
Moat ik elke 5 minuten nei binnen komme en sjen?
Ynstelle cron en kontrolearje. As jo in lange-termyn fersyk, skriuw in brief en dat is it. Dat is, jo hoege net mei jo eagen te sjen, it kin automatisearre wurde. Jo krije in brief, jo reagearje der op. Of jo kinne automatysk sjitte.
Binne der dúdlike redenen wêrom't dit bart?
Ik haw listed guon. Oare mear komplekse foarbylden. En der kin lang in petear wurde.
Tank foar it ferslach! Ik woe dúdlik meitsje oer it pg_repack-hulpprogramma. As se gjin eksklusyf slot docht, dan ...
Se docht in eksklusyf slot.
... dan kin ik mooglik gegevens ferlieze. Moat myn applikaasje yn dizze tiid neat opnimme?
Nee, it wurket soepel mei de tafel, d.w.s. pg_repack ferpleatst earst alle live rigels dy't bestean. Fansels komt dêr in soarte fan yngong yn 'e tabel foar. Hy smyt dizze ponytail gewoan út.
Dat is, hy docht it eins op it lêst?
Op it lêst nimt hy in eksklusyf slot om dizze bestannen te wikseljen.
Sil it rapper wêze dan VACUUM FULL?
VACUUM FULL, sa gau as it begûn, fuortendaliks naam in eksklusive slot. En oant er alles docht, lit er har net litte. En pg_repack nimt in eksklusyf slot allinnich op it momint fan triem ferfanging. Op dit stuit sille jo dêr net skriuwe, mar de gegevens sille net ferlern gean, alles sil goed wêze.
Hallo! Jo hawwe it oer de wurking fan in auto fakuüm. Der wie in grafyk mei reade, giele en griene opname sellen. Dat is, giele - hy markearre se as wiske. En dêrtroch kin der wat nijs yn skreaun wurde?
Ja. Postgres wisket gjin rigels. Hy hat sa'n spesifisiteit. As wy in rigel bywurke hawwe, markearje wy de âlde as wiske. De id fan de transaksje dy't feroare dizze line ferskynt dêr, en wy skriuwe in nije rigel. En wy hawwe sesjes dy't se mooglik lêze kinne. Op in stuit wurde se frij âld. En de essinsje fan hoe't it autovacuum wurket is dat it troch dizze rigels giet en se markearret as net nedich. En jo kinne dêr gegevens oerskriuwe.
Ik begryp it. Mar dêr giet de fraach net oer. Ik bin net klear. Litte wy oannimme dat wy in tabel hawwe. It hat fjilden fan fariabele grutte. En as ik besykje wat nijs yn te foegjen, past it miskien gewoan net yn 'e âlde sel.
Nee, yn alle gefallen wurdt de hiele rigel dêr bywurke. Postgres hat twa modellen foar gegevensopslach. It selektearret út it gegevenstype. Der is gegevens dy't wurdt opslein direkt yn 'e tabel, en der is ek tos gegevens. Dit binne grutte hoemannichten gegevens: tekst, json. Se wurde opslein yn aparte platen. En neffens dizze tabletten komt itselde ferhaal mei bloat foar, dus alles is itselde. Se wurde gewoan apart neamd.
Tank foar it ferslach! Is it oannimlik om query's foar útspraaktimeout te brûken om de doer te beheinen?
Hiel akseptabel. Wy brûke dit oeral. En om't wy gjin eigen tsjinsten hawwe, leverje wy stipe op ôfstân, wy hawwe nochal in ferskaat oan kliïnten. En elkenien is hjir hielendal tefreden oer. Dat is, wy hawwe cron banen dy't kontrolearje. De doer fan 'e sesjes wurdt gewoan ôfpraat mei de klant, wêrfoar't wy it net iens binne. It kin in minút wêze, it kin 10 minuten wêze. It hinget ôf fan 'e lading op' e basis en har doel. Mar wy brûke allegear pg_stat_activity.
Tank foar it ferslach! Ik besykje jo rapport oan te passen op myn oanfragen. En it liket as wy begjinne in transaksje oeral, en dúdlik foltôgje it oeral. As d'r wat útsûndering is, dan komt rollback noch foar. En doe begon ik te tinken. Nei alle gedachten kin de transaksje net eksplisyt begjinne. Dit is wierskynlik in oanwizing foar it famke. As ik gewoan in rekord bywurkje, sil de transaksje begjinne yn PostgreSQL en pas foltôgje as de ferbining is loskeppele?
As jo no prate oer it tapassingsnivo, dan hinget it ôf fan 'e bestjoerder dy't jo brûke, fan' e ORM dy't wurdt brûkt. Der binne in protte ynstellings dêr. As jo auto commit op ynskeakele hawwe, dan begjint in transaksje dêr en slút fuortendaliks.
Dat is, it slút fuortendaliks nei de fernijing?
It hinget ôf fan de ynstellings. Ik neamde ien ynstelling. Dit is auto-commit oan. It is hiel gewoan. As it ynskeakele is, dan is de transaksje iepene en sluten. Behalven as jo eksplisyt sein "begjin transaksje" en "ein transaksje", mar gewoan in fersyk lansearre yn 'e sesje.
Hallo! Tank foar it ferslach! Litte wy ús foarstelle dat wy in databank hawwe dy't swollet en swollet en dan rint de romte op 'e tsjinner op. Binne d'r ark om dizze situaasje te reparearjen?
De romte op 'e tsjinner moat goed kontrolearre wurde.
Bygelyks, de DBA gie foar tee, wie op in resort, ensfh.
As in bestânsysteem wurdt oanmakke, wurdt op syn minst in soarte fan reservekopyromte makke wêr't gegevens net skreaun wurde.
Wat as it folslein ûnder nul is?
Dêr wurdt it reservearre romte neamd, d.w.s. it kin frijmakke wurde en ôfhinklik fan hoe grut it makke is, krije jo frije romte. Standert wit ik net hoefolle it binne. En yn in oar gefal, leverje skiven sadat jo romte hawwe om in rekonstruktive operaasje út te fieren. Jo kinne wiskje wat tabel dat jo garandearre net nedich.
Binne der oare ark?
It is altyd mei de hân makke. En lokaal wurdt dúdlik wat dêr it bêste te dwaan is, want guon gegevens binne kritysk en guon binne net-kritysk. En foar elke databank en de applikaasje dy't dêrmei wurket, hinget it ôf fan it bedriuw. It wurdt altyd lokaal besletten.
Tank foar it ferslach! Ik haw twa fragen. Earst hawwe jo dia's sjen litten dy't sjen litte dat as transaksjes fêst sitte, sawol de tabelromtegrutte as de yndeksgrutte groeie. En fierderop it rapport wie d'r in boskje nutsbedriuwen dy't de tablet ferpakke. Hoe sit it mei de yndeks?
Se pakke se ek yn.
Mar it fakuüm hat gjin ynfloed op de yndeks?
Guon wurkje mei in yndeks. Bygelyks, pg_rapack, pgcompacttable. It fakuüm makket de yndeksen opnij en beynfloedet se. Mei VACUUM FULL is it idee om alles te oerskriuwen, d.w.s. it wurket mei elkenien.
En de twadde fraach. Ik begryp net wêrom rapporten oer replika's sa ôfhinklik binne fan 'e replikaasje sels. It like my ta dat rapporten lêzen wurde, en replikaasje skriuwe.
Wat feroarsake in replikaasjekonflikt? Wy hawwe in Master wêrop prosessen plakfine. Wy hawwe in auto fakuüm geande. Wat docht in autovacuum eins? Hy snijt wat âlde rigels út. As wy op dit stuit in fersyk hawwe op 'e replika dy't dizze âlde rigels lêst, en op' e Master barde in situaasje dat it autovacuum dizze rigels as mooglik markearre foar oerskriuwen, dan hawwe wy se oerskreaun. En wy krigen in gegevenspakket, as wy dy rigels moatte oerskriuwe dy't it fersyk nedich is op 'e replika, sil it replikaasjeproses wachtsje op de timeout dy't jo ynsteld hawwe. En dan sil PostgreSQL beslute wat der wichtiger foar is. En replikaasje is wichtiger foar him as it fersyk, en hy sil it fersyk sjitte om dizze feroaringen op 'e replika te meitsjen.
Andrey, ik haw in fraach. Dizze prachtige grafiken dy't jo hawwe sjen litten tidens de presintaasje, binne dit it resultaat fan it wurk fan in soarte fan nut fan jo? Hoe binne de grafiken makke?
Dit is in tsjinst .
Is dit in kommersjeel produkt?
Ja. Dit is in kommersjeel produkt.
Boarne: www.habr.com