Ez ji we re pêşniyar dikim ku hûn ji destpêka sala 2016-an de ji hêla Andrey Salnikov ve bixwînin "Çewtiyên tîpîk ên di serîlêdanan de ku di postgresql de diqewiminin"
Di vê raporê de, ez ê xeletiyên sereke yên di serlêdanan de ku di qonaxa sêwirandin û nivîsandina koda serîlêdanê de derdikevin analîz bikim. Û ez ê tenê wan xeletiyên ku di Postgresql de rê li ber bloatê digirin bigirim. Wekî qaîdeyek, ev destpêka dawiya performansa pergala we bi tevahî ye, her çend di destpêkê de şertên vê yekê xuya nebûn.
Bi xêrhatina her kesî kêfxweş im! Ev rapor ne wekî ya berê ya hevkarê min teknîkî ye. Ev rapor bi giranî ji pêşdebirên pergala paşîn re tê armanc kirin ji ber ku hejmareke me ya pir zêde xerîdar hene. Û hemû jî heman xeletiyan dikin. Ez ê ji we re behsa wan bikim. Ez ê vebêjim ku ev xeletî dibin sedema çi tiştên kujer û xirab.
Çima xeletî têne kirin? Ew ji ber du sedeman têne kirin: bi rasthatinî, dibe ku ew ê bixebite û ji ber nezanîna hin mekanîzmayên ku di asta di navbera databas û serîlêdanê de, û hem jî di databasê bixwe de çêdibin.
Ez ê sê mînakan bi wêneyên tirsnak bidim we ku tiştên çiqas xirab bûne. Ez ê bi kurtasî li ser mekanîzmaya ku li wir diqewime ji we re bibêjim. Û meriv çawa bi wan re mijûl dibe, kengê ew qewimîn, û kîjan rêbazên pêşîlêgirtinê bikar bînin da ku pêşî li xeletiyan bigirin. Ez ê ji we re li ser amûrên alîkar bibêjim û girêdanên bikêr peyda bikim.
Min databasek testê bikar anî ku li wir du tabloyên min hebûn. Yek plakaya bi hesabên xerîdar, ya din bi danûstendinên li ser van hesaban. Û bi hin caran em hevsengiyên li ser van hesaban nûve dikin.
Daneyên destpêkê yên plakaya: ew pir piçûk e, 2 MB. Dema bersivê ji bo databasê û bi taybetî ji bo nîşanê jî pir baş e. Û barkêşek pir baş - 2 operasyon di çirkeyê de li gorî plakê.
Û bi rêya vê raporê ez ê grafîkan nîşanî we bidim da ku hûn bi zelalî fêm bikin ka çi diqewime. Dê her dem 2 slaytên bi grafîkan hebin. Slide yekem ew e ku bi gelemperî li ser serverê diqewime.
Û di vê rewşê de, em dibînin ku em bi rastî nîşanek piçûk heye. Indeks bi 2 MB piçûk e. Ev grafika yekem li milê çepê ye.
Dema bersivê ya navîn li ser serverê jî aram û kurt e. Ev grafika jorîn rast e.
Grafika çepê ya jêrîn danûstandinên herî dirêj nîşan dide. Em dibînin ku danûstandin zû bi dawî dibin. Û otovacuum hîn li vir naxebite, ji ber ku ew ceribandinek destpêkê bû. Ew ê xebata xwe bidomîne û dê ji me re kêrhatî be.
Slideya duyemîn dê her gav ji plakaya ku tê ceribandin ve were veqetandin. Di vê rewşê de, em bi berdewamî hevsengiyên hesabê xerîdar nûve dikin. Û em dibînin ku dema bersivê ya navîn ji bo operasyonek nûvekirinê pir baş e, ji millisecondekê kêmtir e. Em dibînin ku çavkaniyên pêvajoyê (ev grafika jorîn a rastê ye) di heman demê de û pir piçûk têne xerc kirin.
Grafika rastê ya jêrîn nîşan dide ka çiqas bîranîna xebitandinê û dîskê em di lêgerîna xeta xweya xwestinê de berî nûvekirina wê derbas dikin. Û hejmara operasyonan li gorî nîşanê 2 di çirkeyê de ye, wek ku min di destpêkê de got.
Û niha trajediyek me heye. Ji ber hin sedeman danûstendinek ji mêj ve hatî jibîrkirin heye. Sedem bi gelemperî hemî banal in:
- Yek ji yên herî gelemperî ev e ku me di koda serîlêdanê de dest bi gihîştina karûbarek derveyî kir. Û ev xizmet bersiva me nade. Ango, me danûstendinek vekir, di databasê de guheztinek çêkir û ji serîlêdanê çû ku e-nameyê an karûbarek din di nav binesaziya xwe de bixwîne, û ji ber hin sedeman ew bersivê nade me. Û rûniştina me di rewşekê de asê maye ku nayê zanîn kengî dê çareser bibe.
- Rewşa duyemîn ev e ku ji ber hin sedeman di koda me de îstîsnayek çêbû. Û di îstîsna de me girtina danûstendinê pêvajo nekir. Û em bi danişîna daleqandî ya bi danûstendinek vekirî bi dawî bû.
- Û ya paşîn jî bûyerek pir gelemperî ye. Ev koda kalîteya kêm e. Hin çarçove danûstandinek vekin. Ew daleqandî ye, û dibe ku hûn di serîlêdanê de nizanin ku we ew daleqandî ye.
Tiştên wiha ber bi ku ve diçin?
Heya ku tablo û navnîşên me bi rengek berbiçav dest pê dikin. Ev tam heman bandora bloatê ye. Ji bo databasê, ev ê tê vê wateyê ku dema bersivdana databasê dê pir tûj zêde bibe û barkirina li ser servera databasê dê zêde bibe. Û di encamê de, serlêdana me dê zirarê bibîne. Ji ber ku heke we di koda xwe de 10 milî çirkeyan li ser daxwazek ji databasê re, 10 milî çirkeyan li ser mantiqa xwe xerc kir, wê hingê fonksiyona we 20 milî çirkeyan girt ku temam bibe. Û niha rewşa we dê bi tevahî xemgîn be.
Û em bibînin ka çi dibe. Grafika çepê ya jêrîn nîşan dide ku me danûstendinek dirêj dirêj heye. Û eger em li grafika jorê çepê binerin, em dibînin ku mezinahiya tabloya me ji nişka ve ji du megabyte derketiye 300 megabyte. Di heman demê de, hêjeya daneyên di tabloyê de nehatiye guhertin, ango li wir hejmareke pir mezin a çopê heye.
Rewşa giştî ya di derbarê dema bersivdana navînî ya serverê de jî ji hêla çend rêzikên mezinbûnê ve hatî guhertin. Ango, hemî daxwazên li ser serverê bi tevahî dest pê kir. Û di heman demê de, pêvajoyên Postgres yên navxweyî di forma otovacuumê de hatin destpêkirin, ku hewl didin tiştek bikin û çavkaniyan dixwe.
Çi diqewime bi nîşana me? Hemen. Dema bersivê ya navînî ya me li gorî nîşanê çend rêzikên mezinahiyê daketiye. Bi taybetî di warê çavkaniyên vexwarinê de, em dibînin ku barkirina li ser pêvajoyê pir zêde bûye. Ev grafika jorîn rast e. Û ew zêde bûye ji ber ku pêvajo neçar e ku di lêgerîna ya ku hewce dike de komek xetên bêkêr rêz bike. Ev grafika binê rastê ye. Û di encamê de, hejmara bangên me di çirkeyê de dest pê kir pir girîng daket, ji ber ku databasê wext tune ku heman hejmara daxwazan bişopîne.
Divê em vegerin jiyanê. Em diçin serhêl û fêr dibin ku danûstandinên dirêj dibe sedema pirsgirêkan. Em vê danûstendinê dibînin û dikujin. Û her tişt ji bo me normal dibe. Her tişt wekî ku divê dixebite.
Em aram bûn, lê piştî demekê em dest pê dikin ku serîlêdan bi heman awayê berê acîl naxebite. Serlêdan hîn jî hêdîtir, û bi girîngî hêdîtir têne kirin. Bi taybetî di mînaka min de yek û nîv-du carî hêdîtir. Barkirina serverê jî ji ya beriya qezayê zêdetir e.
Û pirs: "Di vê gavê de çi bi bingehê diqewime?" Û rewşa jêrîn bi bingehîn pêk tê. Li ser nexşeya danûstendinê hûn dikarin bibînin ku ew rawestiyaye û bi rastî danûstandinên demdirêj tune. Lê mezinahiya nîşanê di dema qezayê de bi awayekî kujer zêde bû. Û ji hingê ve ew kêm nebûne. Dema navînî ya li ser bingehê stabîl bûye. Û dixuye ku bersiv bi lez û bezek ku ji me re tê pejirandin têra wan tê. Otovacuum çalaktir bû û dest pê kir ku tiştek bi nîşanê bike, ji ber ku ew hewce dike ku bêtir daneyan bişopîne.
Bi taybetî, li gorî plakaya testê ya bi hesaban re, ku em hevsengiyan diguhezînin: dema bersivê ji bo daxwazek wusa dixuye ku vegeriya normalê. Lê di rastiyê de ew qat û nîv zêdetir e.
Û ji barkirina li ser pêvajoyê, em dibînin ku barkirina li ser pêvajoyê berî hilweşînê venegeriyaye nirxa pêwîst. Û sedemên li wir bi rastî di grafika jêrîn ya rastê de ne. Tê dîtin ku miqdarek bîrê li wir tê gerîn. Ango, ji bo dîtina rêza hewce, em çavkaniyên servera databasê winda dikin dema ku daneyên bêkêr vediqetînin. Hejmara danûstendinên di çirkeyê de stabîl bûye.
Bi tevayî baş e, lê rewş ji ya berê xirabtir e. Xerabûna databasê wekî encama serîlêdana me ya ku bi vê databasê re dixebite paqij bike.
Û ji bo ku hûn fêm bikin ka li wir çi diqewime, heke hûn ne di rapora berê de bûn, naha werin em teoriyek piçûk bistînin. Teoriya li ser pêvajoya navxweyî. Çima valahiya gerîdeyê û çi dike?
Bi kurtasî ji bo têgihiştinê. Di demekê de me tabloyek heye. Di tabloyê de rêzên me hene. Van rêzan dikarin çalak bin, zindî, û ya ku em niha hewce ne. Ew di wêneyê de bi kesk têne nîşankirin. Û xetên mirinê hene ku jixwe hatine xebitandin, nûve kirin, û navnîşên nû li ser wan xuya bûne. Û ew têne nîşankirin ku ew êdî ji databasê re ne balkêş in. Lê ew ji ber taybetmendiyek Postgres di tabloyê de ne.
Çima hûn hewceyê valahiya otomobîlê ne? Di demekê de, otovacuum tê, digihîje databasê û jê dipirse: "Ji kerema xwe nasnameya danûstendina herî kevn a ku niha di databasê de vekirî ye bide min." Database vê nasnameyê vedigerîne. Û otovacuum, xwe dispêre wê, di nav rêzên tabloyê de rêz dike. Û heke ew dibîne ku hin rêz bi danûstendinên pir kevntir hatine guheztin, wê hingê mafê wî heye ku wan wekî rêzikên ku em dikarin di pêşerojê de bi nivîsandina daneyên nû li wir ji nû ve bikar bînin nîşan bide. Ev pêvajoyek paşerojê ye.
Di vê demê de, em bi databasê re xebata xwe didomînin û li ser tabloyê hin guhertinan didomînin. Û li ser van rêzan, ku em dikarin ji nû ve bikar bînin, em daneyên nû dinivîsin. Û bi vî awayî em çerxekê distînin, ango her dem hin rêzikên kevn ên mirî li wir xuya dibin, li şûna wan em rêzikên nû yên ku ji me re hewce ne dinivîsin. Û ev rewşek normal e ku PostgreSQL bixebite.
Di dema qezayê de çi qewimî? Ev pêvajo li wir çawa bû?
Di hin rewşan de, hin zindî, hin xetên mirinê de nîşanek me hebû. Valahiya erebeyê hat. Wî ji databasê pirsî ka danûstendina meya herî kevn çi ye û nasnameya wê çi ye. Min ev nasname wergirt, ku dibe ku gelek demjimêr berê, dibe ku deh deqîqe berê be. Ew bi giraniya barê we li ser databasa we ve girêdayî ye. Û ew çû li rêzikên ku ew bikaribe wekî ji nû ve hatî bikar anîn nîşan bide geriya. Û min di tabloya me de rêzikên weha nedîtin.
Lê di vê demê de em xebatên bi tabloyê didomînin. Em tê de tiştek dikin, nûve dikin, daneyan diguherînin. Divê databas di vê demê de çi bike? Wê neçar e ku xetên nû li dawiya tabloya heyî zêde bike. Û bi vî awayî mezinahiya maseya me dest pê dike.
Di rastiyê de, em hewceyê xetên kesk in ku bixebitin. Lê di dema pirsgirêkek wusa de, derdikeve holê ku rêjeya xêzên kesk li seranserê tabloyê pir kêm e.
Û gava ku em pirsek pêk tînin, pêdivî ye ku databas di hemî rêzan de derbas bibe: hem sor û hem kesk, da ku rêza xwestinê bibîne. Û ji bandora felqkirina tabloyek bi daneyên bêkêr re "bloat" tê gotin, ku ev jî cîhê dîska me dixwe. Tê bîra te, bû 2 MB, bû 300 MB? Naha megabytes biguhezînin gigabytes û hûn ê zû hemî çavkaniyên dîska xwe winda bikin.
Dibe ku çi encam ji bo me hebin?
- Di mînaka min de, tablo û index 150 qat zêde bûn. Hin ji xerîdarên me dema ku wan bi tenê dest bi valakirina cîhê dîskê kir, bûyerên kujer zêdetir bûn.
- Mezinahiya tabloyan bi xwe qet kêm nabe. Ger tenê xetên mirinê hebin, di hin rewşan de otovacuum dikare dûvika maseyê bibire. Lê ji ber ku zivirînek domdar heye, dibe ku yek rêzek kesk di dawiyê de bicemide û neyê nûve kirin, dema ku hemî yên din dê li cîhek li destpêka plakê bêne nivîsandin. Lê ev bûyerek wusa ne mimkûn e ku tabloya we bixwe dê di mezinahiyê de piçûk bibe, ji ber vê yekê divê hûn li hêviya wê nebin.
- Pêdivî ye ku databas di nav komek xetên bêkêr de rêz bike. Û em çavkaniyên dîskê, em çavkaniyên pêvajoyê û elektrîkê winda dikin.
- Û ev rasterast bandorê li ser serlêdana me dike, ji ber ku heke di destpêkê de me 10 milî çirkeyan li ser daxwazê, 10 mîlîsantreyan li ser koda xwe xerc kir, wê hingê di dema têkçûnê de me dest bi saniyeyek li ser daxwazê û 10 milî çirkeyan li ser kodê kir, ango fermanek mezinahiya performansa serîlêdanê kêm bû. Û gava ku qeza çareser bû, me dest pê kir ku 20 millisecond li ser daxwazek, 10 milliseconds li ser kodek. Ev tê wê wateyê ku em hîn jî di hilberînê de yek û nîv carî daketin. Û ev hemî ji ber yek danûstendinê ye ku qeşa girt, dibe ku bi xeletiya me.
- Û pirs: "Em çawa dikarin her tiştî vegerînin?" Da ku her tişt bi me re baş be û daxwazî wekî berê qezayê zû werin.
Ji bo vê armancê xebatek diyarkirî heye ku tê meşandin.
Pêşî pêdivî ye ku em tabloyên bi pirsgirêk ên ku felq bûne bibînin. Em fêm dikin ku di hin tabloyan de tomar çalaktir e, di hinan de kêmtir çalak e. Û ji bo vê yekê em dirêjkirinê bikar tînin . Bi sazkirina vê pêvekê re, hûn dikarin pirsan binivîsin ku dê ji we re bibin alîkar ku hûn tabloyên ku têra xwe zirav in bibînin.
Dema ku we van tabloyan dît, hûn hewce ne ku wan bişkînin. Jixwe amûrên vê hene. Di pargîdaniya me de em sê amûran bikar tînin. Ya yekem VACUUM FULL-ya çêkirî ye. Ew zalim, hişk û bêrehm e, lê carinan pir bikêr e. и - Ev ji bo berhevkirina tabloyan karûbarên sêyemîn in. Û ew databasê bi baldarî derman dikin.
Ew li gorî tiştê ku ji we re hêsantir e têne bikar anîn. Lê ez ê di dawiyê de ji we re behsa vê yekê bikim. Ya sereke ev e ku sê amûr hene. Gelek hene ku ji wan hilbijêrin.
Piştî ku me her tişt rast kir û piştrast kir ku her tişt baş e, divê em zanibin ka meriv çawa di pêşerojê de pêşî li vê rewşê bigire:
- Ew bi hêsanî dikare were asteng kirin. Pêdivî ye ku hûn dirêjahiya danişînan li ser servera Master bişopînin. Di rewşa danûstendinê de bi taybetî danişînên xeternak ên bêkar. Vana yên ku tenê danûstendinek vekirine, tiştek kirine û derketine, an jî bi tenê daleqandî, di kodê de winda bûne.
- Û ji bo we, wekî pêşdebiran, girîng e ku hûn koda xwe biceribînin dema ku van rewşan çêdibin. Çêkirina wê ne zehmet e. Ev ê kontrolek kêrhatî be. Hûn ê ji hejmarek mezin ji pirsgirêkên "zarokî" yên ku bi danûstendinên dirêj ve girêdayî ne dûr bixin.
Di van grafikan de, min xwest ku nîşanî we bidim ka nîşan û tevgera databasê çawa guherî piştî ku ez di vê rewşê de bi nîşana VACUUM FULL re derbas bûm. Ev ji bo min ne hilberîn e.
Mezinahiya tabloyê tavilê vegeriya rewşa xweya xebata normal a çend megabyte. Vê yekê pir bandor li dema bersivdana navînî ya serverê nekir.
Lê bi taybetî ji bo nîşana testa me, ku me hevsengiyên hesabê nûve kir, em dibînin ku dema bersivê ya navînî ji bo daxwazek nûvekirina daneya di nîşanê de kêm bû heya astên pêş-acil. Çavkaniyên ku ji hêla pêvajoyê ve hatî xerc kirin da ku vê daxwazê biqedîne jî daket astên berî qezayê. Û grafika jêrîn ya rastê nîşan dide ku naha em tam rêza ku ji me re lazim e di cih de bibînin, bêyî ku em di nav hêlên xêzên mirî yên ku berî komkirina tabloyê de li wir bûn, bibînin. Û dema daxwaziya navîn hema hema di heman astê de ma. Lê li vir, di cîhana min de xeletiyek heye.
Li vir çîroka yekem bi dawî dibe. Ew ya herî gelemperî ye. Û ew ji her kesî re dibe, bêyî ku ezmûna xerîdar û bernamenûs çiqas jêhatî ne. Zû yan dereng ev yek dibe.
Çîroka duyemîn, ku tê de em barkirinê belav dikin û çavkaniyên serverê xweştir dikin
- Em jixwe mezin bûne û bûne xortên cidî. Û em fehm dikin ku kopiyek me heye û ji bo me baş e ku em bargiraniyê hevseng bikin: ji Mamoste re binivîsin û ji kopiyê bixwînin. Û bi gelemperî ev rewş dema ku em dixwazin hin raporan an ETL amade bikin derdikeve holê. Û karsaz ji vê yekê pir kêfxweş e. Ew bi rastî cûrbecûr raporên bi gelek analîtîkên tevlihev dixwaze.
- Rapor gelek demjimêran digirin, ji ber ku analîtîkên tevlihev di millisecon de nayên hesibandin. Em wek xortên wêrek kodê dinivîsin. Di serîlêdana têketinê de em tomarkirinê li ser Master çêdikin, û raporên li ser replikayê pêk tînin.
- Belavkirina barkirinê.
- Her tişt bêkêmasî dixebite. Em mezin in.
Û ev rewş çawa xuya dike? Bi taybetî li ser van grafîkan, min di heman demê de ji bo dema danûstendinê dirêjahiya danûstendinan ji replikayê jî zêde kir. Hemî grafikên din tenê ji servera Master re vedibêjin.
Di vê demê de, lijneya rapora min mezin bû. Ji wan zêdetir hene. Em dibînin ku dema bersivdana servera navîn aram e. Em dibînin ku li ser replica me danûstendinek dirêj-dirêj heye ku 2 demjimêran dimeşîne. Em operasyona bêdeng a otovacuumê, ku xetên mirinê pêvajoyê dike, dibînin. Û her tişt bi me re baş e.
Bi taybetî, li gorî plakaya ceribandinê, em nûvekirina hevsengiyên hesabê li wir berdewam dikin. Di heman demê de ji bo daxwaziyan, mezaxtina çavkaniyê ya bi îstîqrar jî demek bersivek aram heye. Her tişt bi me re baş e.
Her tişt baş e heya wê gavê ku ev rapor ji ber pevçûnek bi dubarekirinê re dest pê dikin. Û ew di navberên birêkûpêk de vedigerin.
Em diçin serhêl û dest bi xwendina çima ev diqewime. Û em çareseriyekê bibînin.
Çareseriya yekem zêdekirina derengiya dubarekirinê ye. Em dizanin ku rapora me 3 saetan didome. Me derengiya dubarekirinê 3 demjimêran destnîşan kir. Em dest bi her tiştî dikin, lê dîsa jî pirsgirêkên me bi raporên ku carinan têne betal kirin berdewam dikin.
Em dixwazin her tişt bêkêmasî be. Em hê bêtir hilkişin. Û me li ser Înternetê mîhengek xweş dît - hot_standby_feedback. Ka em wê vekin. Hot_standby_feedback destûrê dide me ku em otovacuumê li ser Master bihêlin. Bi vî rengî, em bi tevahî ji nakokiyên dubarekirinê xilas dibin. Û her tişt bi raporên me re baş dixebite.
Û di vê demê de bi servera Master re çi diqewime? Û em bi servera Master re bi tevahî pirsgirêk in. Naha dema ku min van her du mîhengan çalak kirine em grafiyan dibînin. Û em dibînin ku danişîna li ser replika me bi rengekî dest pê kir ku bandorê li ser rewşa servera Master bike. Wê bandorek heye ji ber ku wê otovacuumê rawestand, ku xetên mirinê paqij dike. Mezinahiya sifra me dîsa ezman bilind bûye. Dema darvekirina pirsê ya navînî li seranserê databasê jî ezman zêde bû. Otovacuums hinekî teng kirin.
Bi taybetî, ji plakaya me, em dibînin ku nûvekirina daneya li ser wê jî berbi ezmanan ve çûye. Xerca CPU bi heman rengî pir zêde bûye. Em dîsa di nav hejmareke mezin a mirî, xetên bêkêr re derbas dibin. Û dema bersivê ji bo vê nîşanê û hejmara danûstendinan daketiye.
Ger em nizanibin min berê qala çi dikir dê çawa xuya bike?
- Em dest bi lêgerîna pirsgirêkan dikin. Ger em di beşa yekem de rastî pirsgirêkan hatin, em dizanin ku ev dibe ku ji ber danûstendinek dirêj be û biçin cem Master. Pirsgirêka me li ser mamoste heye. Sosîsên wî. Germ dibe, Barkirina wê bi qasî sed e.
- Daxwazên li wir hêdî ne, lê em li wir ti danûstendinên demdirêj nabînin. Û em fêm nakin ka mesele çi ye. Em fêm nakin ku em li ku binêrin.
- Em amûrên serverê kontrol dikin. Dibe ku êrîşa me têk biçe. Dibe ku çîpa hafizeya me şewitiye. Erê, her tişt dikare bibe. Lê na, server nû ne, her tişt baş dixebite.
- Her kes dimeşe: rêvebir, pêşdebir û derhêner. Tiştek alîkarî nake.
- Û di demekê de her tişt ji nişkê ve dest pê dike ku xwe rast bike.
Di vê demê de, daxwaza li ser replica me hate pêvajo kirin û derket. Me rapor wergirt. Karsaz hîn jî kêfxweş e. Wekî ku hûn dibînin, nîşana me ji nû ve mezin bûye û naçe piçûk. Li ser grafiya bi danişînan, min perçeyek ji vê danûstendina dirêj ji kopiyek hişt, da ku hûn texmîn bikin ka çiqas dem digire heya ku rewş aram bibe.
Rûniştin bi dawî bû. Û tenê piştî demekê server kêm-zêde li rêzê tê. Û dema bersivdana navînî ji bo daxwazên li ser servera Master vedigere rewşa normal. Ji ber ku, di dawiyê de, otovacuumê xwedî derfet e ku van xetên mirinê paqij bike û nîşan bide. Û wî dest bi karê xwe kir. Û ew çiqas zû dike, ew qas zû em ê bi rê ve bibin.
Li gorî tabletê ceribandin, ku em hevsengiyên hesabê nûve dikin, em tam heman wêneyê dibînin. Dema nûvekirina hesabê navîn jî hêdî hêdî normal dibe. Çavkaniyên ku ji hêla pêvajoyê ve têne vexwarin jî kêm dibin. Û hejmara danûstendinên her çirke vedigere rewşa normal. Lê dîsa em vegeriyan rewşa asayî, ne wekî berê qezayê bûn.
Di her rewşê de, em kêmbûna performansê digirin, wekî di doza yekem de, yek û nîv-du carî, û carinan jî bêtir.
Dixuye ku me her tişt rast kiriye. Barê belav bikin. Amûr ne betal in. Me daxwazan li gor mejiyê xwe parve kir, lê dîsa jî her tişt xirab derket.
- hot_standby_feedback çalak nakî? Erê, nayê pêşniyar kirin ku wê bêyî sedemên taybetî yên bihêz vekin. Ji ber ku ev zirav rasterast bandorê li servera Master dike û xebata otovacuumê li wir rawestîne. Bi çalakkirina wê li ser hin kopiyek û jibîrkirina wê, hûn dikarin Master bikujin û bi serîlêdanê re pirsgirêkên mezin derxînin.
- Max_standby_streaming_delay zêde bike? Erê, ji bo raporan ev rast e. Ger we raporek sê-saetê heye û hûn naxwazin ew ji ber nakokiyên dubarekirinê têk bibe, wê hingê bi tenê derengiyê zêde bikin. Raporek demdirêj tu carî hewce nake ku daneyên ku niha gihîştine databasê. Ger we sê demjimêran hebe, wê hingê hûn wê ji bo demek daneya kevn dimeşînin. Û ji bo we, sê saetan dereng an jî şeş saetan dereng hebe, dê tu ferq nake, lê hûn ê raporên bi domdarî bistînin û bi ketina wan re ti pirsgirêk dernakeve.
- Bi xwezayî, hûn hewce ne ku danişînên dirêj li ser kopiyan kontrol bikin, nemaze heke hûn biryar bidin ku li ser kopiyek hot_standby_feedback çalak bikin. Ji ber ku her tişt dikare bibe. Me ev replica da pêşdebiran da ku ew bikaribe daxwazan biceribîne. Wî daxwazek dîn nivîsand. Wî ew dest pê kir û çû çayê vexwe, û me mamosteyê sazkirî wergirt. An jî dibe ku em serîlêdana xelet têxin wir. Rewş cuda ne. Divê danişînên li ser kopiyan bi qasî Masterê bi baldarî werin şopandin.
- Û heke we pirsên bilez û dirêj li ser kopiyan hebin, wê hingê di vê rewşê de çêtir e ku hûn wan parçe bikin da ku bar belav bikin. Ev lînka streaming_delay e. Ji bo yên bilez, yek replica bi dereng dubarekirina piçûk heye. Ji bo daxwazên raporkirina demdirêj, kopiyek heye ku dikare 6 demjimêr an rojek paşde bimîne. Ev rewşek bi tevahî normal e.
Em encaman bi heman awayî ji holê radikin:
- Em tabloyên ziravkirî dibînin.
- Û em wê bi amûra herî maqûl a ku li gorî me dişoxilînin.
Çîroka duyemîn li vir diqede. Em herin ser çîroka sêyemîn.
Di heman demê de ji bo me ku em tê de koçberiyê dikin jî pir hevpar e.
- Her hilberek nermalavê mezin dibe. Pêdiviyên wê diguherin. Di her rewşê de, em dixwazin pêşve bibin. Û diqewime ku em hewce ne ku daneyên di tabloyê de nûve bikin, ango ji bo fonksiyona nû ya ku em wekî beşek pêşkeftina xwe destnîşan dikin, nûvekirinek di warê koçberiya xwe de bimeşînin.
- Forma daneya kevn ne têrker e. Ka em bêjin em niha vedigerin tabloya duyemîn, ku li ser van hesaban danûstandinên min hene. Û em bêjin ku ew bi rubleyan bûn, û me biryar da ku rastbûnê zêde bikin û wê bi kopekan bikin. Û ji bo vê yekê divê em nûvekirinek çêbikin: zeviyê bi mîqdara danûstendinê re sed zêde bikin.
- Di cîhana îroyîn de, em amûrên kontrolkirina guhertoya databasa otomatîkî bikar tînin. Em bêjin . Em koça xwe li wir qeyd dikin. Em wê li ser bingeha ceribandina xwe ceribandin. Her tişt baş e. Nûvekirin derbas dibe. Ew ji bo demek kar asteng dike, lê em daneyên nûvekirî digirin. Û em dikarin li ser vê yekê fonksiyonek nû bidin destpêkirin. Her tişt hate ceribandin û kontrol kirin. Her tişt hate pejirandin.
- Me xebatên plansaz kirin û koçberî pêk anî.
Li vir koçberiya bi nûvekirina ku li pêşberî we hatî pêşkêş kirin heye. Ji ber ku ev danûstandinên hesabê min in, plakaya 15 GB bû. Û ji ber ku em her rêzê nûve dikin, me bi nûvekirinê re mezinahiya tabloyê ducar kir, ji ber ku me her rêzek ji nû ve dinivîsand.
Di dema koçê de, me nekarî bi vê plakaya re tiştek bikin, ji ber ku hemî daxwazên wê li rêzê bûn û li bendê bûn heya ku ev nûvekirin biqede. Lê li vir ez dixwazim bala we bikişînim ser hejmarên ku li ser eksê vertîkal in. Ango, heyama daxwaziya me ya navînî berî koçkirinê bi qasî 5 milîsaniyeyan û barkirina pêvajoyê heye, hejmara operasyonên blokê ji bo xwendina bîra dîskê ji 7,5 kêmtir e.
Me koç kir û dîsa pirsgirêk derketin.
Koçberî serketî bû, lê:
- Karbidestiya kevn naha ji bo temamkirina demek dirêjtir digire.
- Tablo dîsa mezin bû.
- Barkirina serverê dîsa ji berê mezintir bû.
- Û, bê guman, em hîn jî bi fonksiyona ku baş xebitî dişoxilînin, me ew piçek çêtir kiriye.
Û ev dîsa felq e, ku dîsa jiyana me wêran dike.
Li vir ez destnîşan dikim ku tablo, mîna du dozên berê, dê venegere mezinahiyên xwe yên berê. Barkirina serverê ya navîn têr xuya dike.
Û heke em li ser tabloya bi hesaban vegerin, em ê bibînin ku dema daxwaziya navîn ji bo vê tabloyê du qat zêde bûye. Barkirina li ser pêvajoyê û hejmara xêzên ku di bîranînê de hatine veqetandin ji 7,5-an derbas bû, lê kêmtir bû. Û di mijara pêvajokeran de 2 carî, di rewşa operasyonên blokê de 1,5 carî jorda çû, ango me di performansa serverê de xerabûnek dît. Û wekî encam - xirabkirina performansa serîlêdana me. Di heman demê de, hejmara telefonan hema hema di heman astê de ma.
Û ya sereke li vir ev e ku meriv fêm bike ka meriv çawa koçên weha rast dike. Û ew hewce ne ku bêne kirin. Em van koçberan pir bi domdarî dikin.
- Koçberiyên wisa mezin bixweber çênabin. Divê her tim di bin kontrolê de bin.
- Çavdêriya ji aliyê kesekî zana pêwîst e. Ger di tîmê we de DBA heye, wê hingê bila DBA wiya bike. Ew karê wî ye. Ger na, wê hingê bila kesê herî bi tecrube wiya bike, yê ku dizane çawa bi databasan re bixebite.
- Şemayek nû ya databasê, her çend em stûnek nûve bikin jî, em her gav di qonaxan de amade dikin, ango berî ku guhertoya nû ya serîlêdanê derkeve pêş:
- Zeviyên nû têne zêdekirin ku tê de em ê daneyên nûvekirî tomar bikin.
- Em daneyan ji zeviya kevn vediguhezînin qada nû di parçeyên piçûk de. Çima em vê yekê dikin? Ya yekem, em her gav pêvajoya vê pêvajoyê kontrol dikin. Em dizanin ku me ji niha ve ew qas beş veguheztiye û gelek ji me mane.
- Û bandora duyemîn a erênî ev e ku di navbera her komek wusa de em danûstendinê digirin, yekî nû vedikin, û ev dihêle ku otovacuum li gorî plakê bixebite, ji bo ji nû ve karanîna xetên mirinê nîşan bide.
- Ji bo xêzên ku dê dema ku serîlêdan dimeşîne xuya bibin (hîna me serîlêdana kevin dimeşe), em tetikek ku nirxên nû li qadên nû dinivîse zêde dikin. Di rewşa me de, ev bi sed nirxa kevin pirtir e.
- Ger em bi tevahî serhişk in û heman zeviyê dixwazin, wê hingê piştî qedandina hemî koçberan û berî ku guhertoyek nû ya serîlêdanê derxînin, em tenê navên qadan biguherînin. Yên kevin hin navên îcadkirî têne danîn, û zeviyên nû bi yên kevin têne guheztin.
- Û tenê piştî wê em guhertoyek nû ya serîlêdanê didin destpêkirin.
Û di heman demê de em ê di warê performansê de nehêlin û em ê zirarê nebînin.
Li vir çîroka sêyemîn diqede.
Û niha hinek hûrgulî li ser amûrên ku min di çîroka yekem de behs kir.
Berî ku hûn li bloat bigerin, divê hûn pêvekê saz bikin .
Ji bo ku hûn nebin pirsiyar, me berê van pirsan di xebata xwe de nivîsand. Hûn dikarin wan bikar bînin. Li vir du daxwaz hene.
- Yekem demek pir dirêj digire ku bixebite, lê ew ê ji sifrê nirxên tam bloatê nîşanî we bide.
- Ya duyemîn zûtir dixebite û pir bi bandor e dema ku hûn hewce ne ku zû binirxînin ka li gorî tabloyê felqek heye an na. Û divê hûn jî fêm bikin ku bloat her gav di tabloyek Postgres de heye. Ev taybetmendiyek modela wê ya MVCC ye.
- Û 20% bloat di pir rewşan de ji bo tabloyan normal e. Ango divê meriv xem neke û vê tabloyê bitepisîne.
Me fêhm kir ku meriv çawa tabloyên werimî nas dikin, û kengê ew bi daneyên bêkêr werimî ne.
Naha li ser meriv çawa bloatê rast dike:
- Ger tabletek piçûk û dîskên me yên baş hebin, ango li ser tabletek heya gigabaytekê, pir mimkun e ku em VACUUM FULL bikar bînin. Ew ê ji bo çend saniyeyan li ser masê kilîtek taybetî ji we bigire û baş e, lê ew ê her tiştî zû û bi tundî bike. VACUUM FULL çi dike? Ew li ser masê qeflek taybetî digire û rêzikên zindî ji tabloyên kevn di tabloya nû de ji nû ve dinivîse. Û di dawiyê de ew şûna wan digire. Ew pelên kevin jê dike û yên kevin bi yên nû vedigire. Lê ji bo dirêjahiya xebata xwe, ew li ser sifrê qeflek taybetî digire. Ev tê wê wateyê ku hûn nikarin tiştekî bi vê tabloyê bikin: ne jê re binivîsin, ne tê de bixwînin, ne jî biguherînin. Û VACUUM FULL ji bo nivîsandina daneyan cîhê dîskê hewce dike.
- tool Next . Di prensîba xwe de, ew pir dişibihe VACUUM FULL, ji ber ku ew di heman demê de daneyan ji pelên kevn ji nû ve dinivîse û wan di tabloyê de vedigire. Lê di heman demê de, ew di destpêka xebata xwe de li ser masê qeflek taybetî nagire, lê wê tenê di dema ku berê xwedan daneya amade ye da ku pelan biguhezîne digire. Pêdiviyên wê yên çavkaniya dîskê mîna yên VACUUM FULL ne. Pêdivî ye ku hûn cîhê dîskê zêde bikin, û ev carinan krîtîk e heke we tabloyên terabyte hebin. Û ew pir birçî-pêvajoyê ye ji ber ku ew bi aktîvî bi I/O re dixebite.
- Alîkariya sêyemîn e . Ew bi çavkaniyan re baldartir e ji ber ku ew li gorî prensîbên hinekî cûda dixebite. Fikra sereke ya pgcompacttable ev e ku ew bi karanîna nûvekirinên di tabloyê de hemî rêzikên zindî berbi destpêka tabloyê vediguhezîne. Û paşê ew li ser vê tabloyê valahiyek dimeşîne, ji ber ku em dizanin ku rêzên me yên zindî di destpêkê de û rêzên mirî di dawiyê de hene. Û valahiya xwe vê dûvikê qut dike, ango ew cîhê dîskê zêde hewce nake. Û di heman demê de, ew hîn jî dikare di warê çavkaniyan de were qut kirin.
Her tişt bi amûran.
Ger hûn mijara bloatê di warê hûrbûna hundurîn de balkêş dibînin, li vir çend girêdanên kêrhatî hene:
- - Ev raporta hevkarê min e. Ew gelemperî ye ku cîhê Postgres di dema kar û jiyana xwe de diçe ku derê. Û ji bo rêveberên databasê di derbarê bloat de perçeyek teknîkî ya pir mezin û berfireh heye.
- - ev lînka depoya me ye, ku em ji bo kontrolkirina rewşa databasê komek nivîsarên bikêr hilînin. Li wir hûn dikarin nivîsarên ku li bloat bigerin bibînin.
- и girêdan bi amûrên ku dê ji we re bibin alîkar ku hûn nîşanan piçûk bikin.
- - ev nivîsa hevkarê min e. Li wir ew bi ciddî û teknîkî bi hûrgulî di astek nêzî rêveberan de blotan analîz dike.
Min bêtir hewl da ku ji bo pêşdebiran çîrokek tirsnak nîşan bidim, ji ber ku ew xerîdarên me yên rasterast ên databasan in û divê fêm bikin ka çi û çi kiryar ber bi çi ve diçin. Ez hêvî dikim ku ez bi ser ketim. Spas ji bo baldariya we!
Pirsên
Spas ji bo raporê! We behsa wê yekê kir ku hûn çawa dikarin pirsgirêkan nas bikin. Çawa dikarin wan hişyar bikin? Ango, min rewşek hebû ku daxwaz ne tenê ji ber ku ew gihîştin hin karûbarên derveyî daliqandin. Ev tenê hinek tevlîheviyên hov bûn. Hin daxwazên piçûk, bê zerar hebûn ku rojekê li dora xwe sekinîn, û dûv re dest bi hin bêaqilan kirin. Ango, pir dişibihe ya ku hûn diyar dikin. Meriv çawa vê yekê bişopîne? Rûnin û bi domdarî temaşe bikin ka kîjan daxwaz asê maye? Çawa dikare pêşî li vê yekê bigire?
Di vê rewşê de, ev peywirek ji bo rêvebirên pargîdaniya we ye, ne hewce ne ji bo DBA.
Ez rêveber im.
PostgreSQL xwedan nêrînek bi navê pg_stat_activity heye ku lêpirsinên dangdar nîşan dide. Û hûn dikarin bibînin ku ew çiqas dirêj li wir daleqandî ye.
Ma divê ez her 5 hûrdeman herim hundur û binêrim?
Cron saz bikin û kontrol bikin. Ger daxwazek weya demdirêj hebe, nameyekê binivîsin û ew e. Ango, ne hewce ye ku hûn bi çavên xwe binihêrin, ew dikare bixweber bibe. Hûn ê nameyekê bistînin, hûn jê re bertek nîşan bidin. An jî hûn dikarin bixweber gulebaran bikin.
Ma sedemên eşkere hene ku çima ev dibe?
Min hinek navnîş kir. Mînakên din ên tevlihevtir. Û dikare ji bo demeke dirêj axaftinek hebe.
Spas ji bo raporê! Min xwest ku ez di derheqê amûra pg_repack de zelal bikim. Ger ew kilîtkirinek taybetî neke, wê ...
Ew kilîtkirinek taybetî dike.
... wê hingê ez potansiyel dikarim daneyan winda bikim. Ma divê serlêdana min di vê demê de tiştek tomar neke?
Na, ew bi tabloyê re bêkêmasî dixebite, ango pg_repack pêşî hemî xetên zindî yên ku hene vediguhezîne. Bi xwezayî, cûreyek ketina maseyê li wir çêdibe. Ew tenê vê dûvikê davêje derve.
Ango, ew bi rastî di dawiyê de dike?
Di dawiyê de, ew qeflek taybetî digire da ku van pelan biguhezîne.
Ma ew ê ji VACUUM FULL zûtir be?
VACUUM FULL, gava ku dest pê kir, tavilê qeflek taybetî girt. Û heta ku ew her tiştî neke, ew ê wê nehêle. Û pg_repack tenê di dema veguheztina pelê de kilîtek taybetî digire. Di vê gavê de hûn ê li wir nenivîsin, lê dane dê winda nebin, her tişt dê baş be.
Slav! We behsa xebata valahiya erebeyekê kir. Grafikek bi şaneyên tomar ên sor, zer û kesk hebû. Ango yên zer - wî ew wekî jêbirin nîşan kir. Û di encamê de, tiştek nû dikare di nav wan de were nivîsandin?
Erê. Postgres rêzan jê nake. Taybetmendiyek wî ya weha heye. Ger me rêzek nûve kir, me ya kevn wekî jêbirin nîşan kir. Nasnameya danûstendinê ya ku ev rêz guhertiye li wir xuya dike, û em rêzek nû dinivîsin. Û me danişînên ku potansiyel dikarin wan bixwînin hene. Di demekê de ew pir pîr dibin. Û cewhera ku otovacuum çawa dixebite ev e ku ew di van rêzan re derbas dibe û wan wekî nepêwist nîşan dide. Û hûn dikarin daneyan li wir binivîsin.
Ez dizanim. Lê pirs ne ev e. Min neqedand. Ka em bihesibînin ku tabloyek me heye. Ew zeviyên mezinahiya guhêrbar heye. Û heger ez hewl bidim ku tiştek nû têxim, dibe ku ew bi hêsanî nekeve hucreya kevn.
Na, di her rewşê de tevahiya rêzê li wir tê nûve kirin. Postgres du modelên hilanîna daneyê hene. Ew ji celebê daneyê hildibijêre. Daneyên ku rasterast di tabloyê de têne hilanîn hene, û daneyên tos jî hene. Ev mîqdarên mezin ên daneyê ne: nivîs, json. Ew di pelên cuda de têne hilanîn. Û li gor van tabletan jî heman çîroka bi felekê diqewime, yanî her tişt wek hev e. Ew tenê ji hev cuda têne navnîş kirin.
Spas ji bo raporê! Ma tê qebûl kirin ku ji bo sînorkirina demjimêrê lêpirsînên dema daxuyaniyê bikar bînin?
Pir meqbûl. Em vê li her derê bikar tînin. Û ji ber ku em ne karûbarên xwe ne, em piştgirîya dûr peyda dikin, gelek xerîdarên me hene. Û her kes bi tevahî ji vê yekê razî ye. Ango, karên me yên kronî hene ku kontrol dikin. Demjimêra danişînan bi tenê bi xerîdar re li hev tê, berî ku em li hev nakin. Dibe ku deqîqeyek be, dibe 10 deqe. Ew bi barkirina li ser bingehê û armanca wê ve girêdayî ye. Lê em hemî pg_stat_activity bikar tînin.
Spas ji bo raporê! Ez hewl didim ku rapora we li ser serlêdanên xwe bicîh bikim. Û wusa dixuye ku em li her deverê dest bi danûstendinê dikin, û bi eşkere wê li her deverê temam dikin. Ger hin îstîsna hebe, wê hingê vegerandin dîsa jî çêdibe. Û paşê min dest bi ramanê kir. Beriya her tiştî, dibe ku danûstandin bi eşkere dest pê neke. Dibe ku ev îşaretek ji keçikê re ye. Ger ez tenê tomarek nûve bikim, dê danûstandin di PostgreSQL de dest pê bike û tenê dema ku girêdan qut bibe biqede?
Ger hûn niha li ser asta serîlêdanê dipeyivin, wê hingê ew bi ajokera ku hûn bikar tînin ve girêdayî ye, bi ORM-ya ku tê bikar anîn ve girêdayî ye. Li wir gelek mîheng hene. Ger we pevrakirina otomatîkî çalak be, wê hingê danûstendinek li wir dest pê dike û tavilê diqede.
Ango, ew tavilê piştî nûvekirinê diqede?
Ew bi mîhengan ve girêdayî ye. Min navê yek mîhengê kir. Ev oto commit li ser e. Ew pir gelemperî ye. Ger çalak be, wê hingê danûstandin vekiriye û girtiye. Heya ku we bi eşkere negot "danûstandin dest pê bike" û "danûstandin bi dawî bibe", lê tenê daxwazek danişînê dest pê kir.
Slav! Spas ji bo raporê! Werin em bifikirin ku databasek me heye ku diwerime û diwerime û dûv re cîhê serverê diqede. Ma amûrên ku vê rewşê rast bikin hene?
Cihê li ser serverê pêdivî ye ku bi rêkûpêk were şopandin.
Mînakî, DBA çû çay, li seyrangehekê bû, hwd.
Dema ku pergalek pelê tê afirandin, bi kêmî ve cîhek paşvekêşanê ya ku dane nenivîsandiye tê afirandin.
Ger ew bi tevahî di binê sifirê de be?
Li wir jê re cîhê veqetandî tê gotin, ango ew dikare were azad kirin û li gorî ku ew çiqas mezin hatî afirandin, hûn cîhê belaş digirin. Bi xweber ez nizanim çend in. Û di rewşeke din de, dîskan radest bikin da ku cîhê we hebe ku hûn operasyonek nûavakirinê bikin. Hûn dikarin hin tabloyên ku hûn garantî ne hewce ne jêbikin.
Ma amûrên din hene?
Her tim bi destan e. Û li herêmê zelal dibe ku çêtirîn e ku meriv li wir çi bike, ji ber ku hin dane krîtîk in û hin jî ne krîtîk in. Û ji bo her databas û serîlêdana ku pê re dixebite, ew bi karsaziyê ve girêdayî ye. Her tim li herêmê biryar tê girtin.
Spas ji bo raporê! Du pirsên min hene. Pêşîn, we slaytên ku destnîşan dikin ku gava danûstendin sekinîne, hem mezinahiya cîhê sifrê û hem jî mezinahiya navnîşê mezin dibin. Û bêtir li ser raporê komek karûbarên ku tabletê pak dikin hene. Çi li ser index?
Wan jî pak dikin.
Lê valahiya îndeksê bandor nake?
Hin bi indexek dixebitin. Mînakî, pg_rapack, pgcompacttable. Valahî nîşaneyan ji nû ve diafirîne û bandorê li wan dike. Bi VACUUM FULL re fikir ev e ku meriv her tiştî binivîsîne, ango ew bi her kesî re dixebite.
Û pirsa duyemîn. Ez fam nakim çima raporên li ser kopiyan ew qas bi dubarekirinê ve girêdayî ne. Ji min re xuya bû ku rapor têne xwendin, û dubarekirin têne nivîsandin.
Çi dibe sedema pevçûnek dubarekirinê? Me Masterek heye ku pêvajo li ser diqewime. Vakûmeya erebeya me heye. Otovacuum bi rastî çi dike? Ew hin rêzikên kevn jê dike. Ger di vê demê de daxwazek me li ser kopyaya ku van rêzên kevn dixwîne, û li ser Mamoste rewşek çêbibe ku otovacuum van rêzan ji bo nivîsandinê wekî gengaz nîşan daye, wê hingê me ew li ser nivîsand. Û me pakêtek daneyê wergirt, gava ku em hewce bikin ku em wan rêzikên ku daxwazê li ser kopiyê hewce dike ji nû ve binivîsin, pêvajoya dubarekirinê dê li benda dema ku we mîheng kiriye bimîne. Û paşê PostgreSQL dê biryarê bide ka çi jê re girîngtir e. Û dubarekirin ji bo wî ji daxwazê girîngtir e, û ew ê daxwazê biavêje da ku van guhertinan li ser replikayê bike.
Andrey, pirsek min heye. Ev grafikên hêja yên ku we di dema pêşkêşiyê de nîşan dan, gelo ev encama xebata we ya cûreyek kêrhatî ne? Grafîk çawa hatine çêkirin?
Ev xizmetek e .
Ma ev hilberek bazirganî ye?
Erê. Ev hilberek bazirganî ye.
Source: www.habr.com