Mi proponas legi la transskribon de la raporto de la komenco de 2016 de Andrey Salnikov "Tipaj eraroj en aplikoj, kiuj kondukas al ŝvelaĵo en postgresql"
En ĉi tiu raporto, mi analizos la ĉefajn erarojn en aplikoj, kiuj okazas en la stadio de desegnado kaj skribo de aplika kodo. Kaj mi prenos nur tiujn erarojn, kiuj kondukas al ŝvelaĵo en Postgresql. Ĝenerale, ĉi tio estas la komenco de la fino de la funkciado de via sistemo entute, kvankam komence ne estis viditaj antaŭkondiĉoj por tio.
Mi ĝojas bonvenigi ĉiujn! Ĉi tiu raporto ne estas tiel teknika kiel la antaŭa de mia kolego. Ĉi tiu raporto celas programistojn de backend-sistemoj ĉefe ĉar ni havas sufiĉe grandan nombron da klientoj. Kaj ili ĉiuj faras la samajn erarojn. Mi rakontos al vi pri ili. Mi klarigos al kio fatala kaj malbona kondukas ĉi tiuj eraroj.
Kial oni faras erarojn? Ili estas faritaj pro du kialoj: hazarde, eble ĝi funkcios pro nescio pri iuj mekanismoj, kiuj okazas ĉe la nivelo inter la bazo kaj la aplikaĵo, same kiel en la bazo mem.
Mi donos al vi tri ekzemplojn kun teruraj bildoj pri kiel aferoj malboniĝis. Mi mallonge priskribos la mekanismon kiu okazas tie. Kaj kiel trakti ilin, kiam ili okazis, kaj kiajn preventajn metodojn uzi por malhelpi erarojn. Mi rakontos al vi pri helpaj iloj kaj donos utilajn ligilojn.
Mi uzis testan datumbazon kie mi havis du tabelojn. Unu telero kun klientkontoj, la alia kun operacioj sur ĉi tiuj kontoj. Kaj kun ioma periodeco, ni ĝisdatigas la saldojn de ĉi tiuj kontoj.
La komencaj datumoj de la plato: ĝi estas sufiĉe malgranda, 2 MB. La respondtempo por la datumbazo kaj specife por la telero ankaŭ estas tre bona. Kaj sufiĉe bona ŝarĝo - 2 operacioj sekundo sur la telero.
Kaj per ĉi tiu raporto, mi montros al vi grafikaĵojn por ke estu klare kio okazas. Ĉiam estos 2 diapozitivoj kun grafikaĵoj. La unua diapozitivo estas kio okazas ĝenerale sur la servilo.
Kaj en ĉi tiu situacio, ni vidas, ke ni vere havas malgrandan teleron. La indekso estas malgranda je 2 MB. Ĉi tiu estas la unua diagramo maldekstre.
La meza respondtempo tra la servilo ankaŭ estas stabila, malgranda. Ĉi tiu estas la supra dekstra grafikaĵo.
La malsupra maldekstra grafikaĵo estas la plej longaj transakcioj. Ni povas vidi, ke transakcioj estas kompletigitaj rapide. Kaj la aŭtomata vakuo ankoraŭ ne funkcias ĉi tie, ĉar - ĝi estis starttesto. Tiam ĝi funkcios kaj estos utila al ni.
La dua glito ĉiam estos dediĉita al la testplato. En ĉi tiu situacio, ni konstante ĝisdatigas la kontajn saldojn de la kliento. Kaj ni vidas, ke la meza respondtempo por la ĝisdatiga operacio estas sufiĉe bona, malpli ol milisekundo. Ni vidas, ke la procesoraj rimedoj (ĉi tio estas la supra dekstra grafikaĵo) ankaŭ estas konsumitaj egale kaj sufiĉe malgrandaj.
La malsupra dekstra grafikaĵo montras kiom da operacia kaj diskmemoro ni trapasas serĉante nian deziratan linion antaŭ ĝisdatigi ĝin. Kaj la nombro da operacioj sur la telero estas 2 000 sekundo, kiel mi diris komence.
Kaj nun ni havas tragedion. Ial, longe forgesita transakcio okazas. La kialoj estas kutime ĉiuj banalaj:
- Unu el la plej oftaj estas, ke ni komencis aliri eksteran servon en la aplika kodo. Kaj ĉi tiu servo ne respondas al ni. Tio estas, ni malfermis transakcion, faris ŝanĝon en la datumbazo kaj iris de la aplikaĵo por legi poŝton aŭ al alia servo ene de nia infrastrukturo, kaj ial ĝi ne respondas al ni. Kaj nia sesio pendis en stato - oni ne scias, kiam ĝi estos solvita.
- La dua situacio estas kiam escepto okazis en nia kodo ial. Kaj ni ne prilaboris la fermon de la transakcio en la escepto. Kaj ni ricevis kunsidon kun malfermita transakcio.
- Kaj la lasta ankaŭ estas sufiĉe ofta. Ĉi tio estas malbonkvalita kodo. Iuj kadroj malfermas transakcion. Ĝi pendas, kaj vi eble ne scias en la aplikaĵo, ke vi havas ĝin pendanta.
Kien kondukas tiaj aferoj?
Al la fakto, ke niaj tabeloj kaj indeksoj komencas draste ŝveliĝi. Ĉi tio estas ĝuste la sama ŝvela efiko. Por la datumbazo, ĉi tio estos esprimita en la fakto, ke ni havos tre akran pliiĝon en la responda tempo de la datumbazo, la ŝarĝo sur la datumbaza servilo pliiĝos. Kaj kiel rezulto, nia aplikaĵo suferos. Ĉar se en via kodo vi elspezis 10 milisekundojn por peto al la datumbazo, 10 milisekundojn por via logiko, tiam via funkcio funkciis 20 milisekundojn. Kaj nun via situacio estos tre malĝoja.
Kaj ni vidu kio okazas. La malsupra maldekstra grafikaĵo montras, ke ni havas longan longan transakcion. Kaj se ni rigardas la supran maldekstran grafikaĵon, ni vidas, ke la grandeco de la tablo saltis de du megabajtoj al 300 megabajtoj. Samtempe, la kvanto da datumoj en la tabelo ne ŝanĝiĝis, tio estas, estas sufiĉe granda kvanto da rubo.
La ĝenerala situacio laŭ la meza servila respondtempo ankaŭ ŝanĝiĝis je pluraj grandordoj. Tio estas, ĉiuj petoj sur la servilo komencis tute malkreski. Kaj samtempe estis lanĉitaj la internaj Postgres-procezoj fronte al aŭtomata vakuo, kiuj provas ion fari kaj konsumi rimedojn.
Kio okazas al nia telero? La sama. La averaĝa respondtempo sur la tablojdo saltis plurajn grandordojn. Se specife koncerne konsumitajn rimedojn, tiam ni vidas, ke la ŝarĝo sur la procesoro multe pliiĝis. Ĉi tiu estas la supra dekstra grafikaĵo. Kaj ĝi pliiĝis ĉar la procesoro devas trairi amason da senutilaj linioj serĉante tiun, kiun vi bezonas. Ĉi tiu estas la malsupra dekstra grafikaĵo. Kaj kiel rezulto, la nombro da vokoj por sekundo komencis tre malpliiĝi, ĉar la datumbazo ne havas tempon por prilabori la saman nombron da petoj.
Ni devas reveni al la vivo. Ni grimpas en Interreton kaj ekscias, ke longaj transakcioj kondukas al problemo. Ni trovas kaj mortigas ĉi tiun transakcion. Kaj ĉio iras bone por ni. Ĉio funkcias kiel ĝi devus.
Ni trankviliĝis, sed post iom da tempo ni komencas rimarki, ke la aplikaĵo ne funkcias kiel antaŭ la krizo. Petoj estas traktataj tamen pli malrapide, kaj multe pli malrapide. Unu kaj duono ĝis du fojojn pli malrapide specife en mia ekzemplo. La ŝarĝo sur la servilo ankaŭ estas pli alta ol ĝi estis antaŭ la akcidento.
Kaj la demando: "Kio okazas al la bazo ĉi-momente?". Kaj kun bazo estas sekva situacio. Sur la transakcia diagramo, vi povas vidi, ke ĝi ĉesis kaj vere ne ekzistas longdaŭraj transakcioj. Sed la dimensioj de la plato dum la akcidento kreskis mortige. Kaj ĝi ne malpliiĝis de tiam. La averaĝa tempo sur la bazo stabiliĝis. Kaj la respondoj ŝajnas iri adekvate kun akceptebla rapideco por ni. Aŭtomata vakuo fariĝis pli aktiva kaj komencis fari ion kun la tablojdo, ĉar ĝi bezonas ŝoveli pli da datumoj.
Specife, sur la testa poenttabulo, kie ni ŝanĝas la ekvilibrojn: la respondtempo por la peto ŝajnas esti normaliĝinta. Sed fakte ĝi estas unu kaj duono pli alta.
Kaj per la ŝarĝo sur la procesoro, ni vidas, ke la ŝarĝo sur la procesoro ne revenis al la dezirata valoro antaŭ la kraŝo. Kaj la kialoj tie kuŝas nur en la malsupra dekstra grafikaĵo. Oni povas vidi, ke estas serĉado de iom da memoro. Tio estas, por serĉi la deziratan linion, ni elspezas la rimedojn de la datumbaza servilo dum ordigo de senutilaj datumoj. La nombro da transakcioj por sekundo stabiliĝis.
Ĝenerale, bone, sed la situacio estas pli malbona ol ĝi estis. Eksplicita degenero de la datumbazo kiel konsekvenco de nia aplikaĵo, kiu funkcias kun ĉi tiu datumbazo.
Kaj por kompreni kio okazas tie, se vi ne estis ĉe la antaŭa raporto, do nun iom da teorio. Teorio pri la interna procezo. Kial aŭtomata vakuo kaj kion ĝi faras?
Laŭvorte mallonge por kompreno. En iu momento ni havas tablon. Ni havas vicojn en la tabelo. Ĉi tiuj linioj povas esti aktivaj, vivaj, ni bezonas nun. Ili estas markitaj verde en la bildo. Kaj estas mortaj linioj, kiuj jam funkciis, estis ĝisdatigitaj, novaj enskriboj aperis sur ili. Kaj ili estas markitaj, ke ili ne plu interesas la datumbazon. Sed ili kuŝas en la tablo pro la proprecoj de Postgres.
Kial vi bezonas aŭtomatan vakuon? Aŭtovakuo venas iam, vokas la datumbazon kaj demandas ĝin: "Bonvolu doni al mi la identigilon de la plej malnova transakcio, kiu estas nuntempe malfermita en la datumbazo." La datumbazo resendas ĉi tiun identigilon. Kaj la aŭtovakuo, fidante je ĝi, trairas la liniojn en la tablo. Kaj se li vidas, ke iuj linioj estis ŝanĝitaj de multe pli malnovaj transakcioj, tiam li rajtas marki ilin kiel liniojn, kiujn ni povos reuzi estonte skribante novajn datumojn tie. Ĉi tio estas fona procezo.
Nuntempe, ni daŭre laboras kun la datumbazo, ni daŭre faras iujn ŝanĝojn en la tabelo. Kaj sur ĉi tiuj linioj, kiujn ni povas reuzi, ni skribas novajn datumojn. Kaj tiamaniere ni ricevas ciklon, tio estas, iuj mortaj malnovaj linioj aperas tie la tutan tempon, anstataŭ ili ni skribas novajn liniojn, kiujn ni bezonas. Kaj ĉi tio estas la normala stato por ke PostgreSQL funkciu.
Kio okazis dum la akcidento? Kiel okazis ĉi tiu procezo?
Ni havis teleron en iu stato, iuj vivantaj, iuj mortaj linioj. La aŭtomata vakuo alvenis. Li demandis la datumbazon pri kio estas nia plej malnova transakcio, kio estas ĝia identigilo. Ricevis ĉi tiun identigilon, kiu povas aĝi multajn horojn, eble dek minutojn. Ĝi dependas de kiom peza la ŝarĝo vi havas sur la datumbazo. Kaj li iris serĉi liniojn, kiujn li povas marki kiel reuzitaj. Kaj tiajn liniojn mi ne trovis en nia tabelo.
Sed ĉi-momente ni daŭre laboras kun la tablo. Ni faras ion en ĝi, ĝisdatigas ĝin, ŝanĝas la datumojn. Kion devus fari la datumbazo ĉi-momente? Ŝi ne havas alian elekton ol aldoni novajn liniojn al la fino de la ekzistanta tablo. Kaj tiel ĉe ni la grandeco de la tablo komencas ŝveliĝi.
Ni vere bezonas verdajn liniojn por funkcii. Sed dum tia problemo, rezultas, ke la procento de verdaj linioj estas ekstreme malalta en la tuta volumo de la tablo.
Kaj kiam ni plenumas demandon, la datumbazo devas trairi ĉiujn liniojn, ambaŭ ruĝajn kaj verdajn, por trovi la ĝustan linion. Kaj la efiko de ŝveligi la tablon per senutilaj datumoj nomiĝas "bloat", kiu ankaŭ manĝas nian diskospacon. Memoru, ĝi estis 2 MB, nun ĝi estas 300 MB? Nun ŝanĝu megabajtojn al gigabajtoj kaj vi perdos ĉiujn viajn diskresursojn sufiĉe rapide.
Kio estas la implicoj por ni?
- En mia ekzemplo, la tabelo kaj indekso kreskis 150 fojojn. Kelkaj el niaj klientoj havis pli mortigajn kazojn kiam diskspaco simple komencis elĉerpi.
- Tabloj neniam ŝrumpos per si mem. Aŭtovakuo en iuj kazoj povas fortranĉi la voston de la tablo se estas nur mortaj linioj. Sed ĉar estas konstanta rotacio, unu verda linio povas pendi ĉe la fino kaj ne esti ĝisdatigita, kaj ĉio cetera ie ĉe la komenco de la plato estos registrita. Sed ĉi tio estas tiel neverŝajna evento, ke via tablo mem malpliiĝos en grandeco, do vi ne devus esperi pri ĝi.
- La datumbazo bezonas ordigi la tutan amason da senutilaj linioj. Kaj ni malŝparas diskajn rimedojn, malŝparas procesorajn rimedojn kaj elektron.
- Kaj ĉi tio rekte influas nian aplikaĵon, ĉar se komence ni elspezis 10 milisekundojn por peto, 10 milisekundojn por nia kodo, tiam dum la kraŝo ni komencis elspezi sekundon por peto kaj 10 milisekundojn por kodo, t.e., ordo de magnituda aplika rendimento malpliiĝis. Kaj kiam la akcidento estis solvita, ni komencis elspezi 20 milisekundojn per peto, 10 milisekundojn per kodo. Ĉi tio signifas, ke ni ankoraŭ unufoje kaj duono malleviĝis laŭ rendimento. Kaj ĉi tio estas ĉio pro unu transakcio kiu pendis, kaj, eble, pro nia kulpo.
- Kaj la demando: "Kiel mi povas rehavi ĉion?" Por ke ĉio estu en ordo ĉe ni kaj petoj kuru same rapide kiel antaŭ la akcidento.
Por ĉi tio, estas certa ciklo de laboro, kiu efektiviĝas.
Unue ni devas trovi la problemajn tabelojn, kiuj ŝvelis. Ni komprenas, ke iuj tabeloj registras pli aktive, iuj malpli aktive. Kaj por tio ni uzas la etendon . Instalante ĉi tiun etendon, vi povas skribi demandojn por helpi vin trovi tabelojn sufiĉe ŝvelintajn.
Post kiam vi trovis ĉi tiujn tabelojn, ili devas esti kunpremitaj. Jam ekzistas iloj por tio. En nia kompanio, ni uzas tri ilojn. La unua estas la enkonstruita VACUUM FULL. Li estas kruela, severa kaj senkompata, sed foje li estas tre utila. и estas triaj iloj por kunpremi tabelojn. Kaj ili pli zorgas pri la datumbazo.
Ili estas uzataj laŭ tio, kio estas pli oportuna por vi. Sed mi parolos pri tio ĉe la fino. La ĉefa afero estas, ke ekzistas tri iloj. Estas multe por elekti.
Post kiam ni korektis ĉion, certigante ke ĉio estas en ordo, ni devus scii kiel malhelpi ĉi tiun situacion en la estonteco:
- Estas sufiĉe facile malhelpi. Vi devas kontroli la daŭron de sesioj sur la Majstra servilo. Aparte danĝeraj kunsidoj en la neaktiva en transakcia stato. Ĉi tiuj estas tiuj, kiuj ĵus malfermis transakcion, faris ion kaj foriris, aŭ simple pendis, perdiĝis en la kodo.
- Kaj por vi, kiel programistoj, gravas testi la kodon kiam ĉi tiuj situacioj aperas. Ne estas malfacile fari. Ĉi tio estos utila kontrolo. Vi evitos multajn "infanajn" problemojn asociitajn kun longaj transakcioj.
Sur ĉi tiuj grafikaĵoj, mi volis montri al vi kiel la tabelo kaj la konduto de la datumbazo ŝanĝiĝis post kiam mi pasis VACUUM FULL sur la tablo en ĉi tiu kazo. Ĉi tio ne estas mia produktado.
La grandeco de la tabelo tuj revenis al sia normala funkcia stato de kelkaj megabajtoj. Ĉi tio ne multe influis la mezan respondtempon tra la servilo.
Sed specife en nia testa tabelo, kie ni ĝisdatigis la kontajn saldojn, ni vidas, ke la meza responda tempo al peto ĝisdatigi la datumojn en la tablojdo estis reduktita al la antaŭ-akcidento. La rimedoj konsumitaj de la procesoro por efektivigi ĉi tiun peton ankaŭ falis al antaŭ-kraŝo-niveloj. Kaj la malsupra dekstra grafeo montras, ke nun ni trovas ĝuste la linion, kiun ni bezonas tuj, sen trairi la amason da mortaj linioj, kiuj estis antaŭ ol la tablo estis kunpremita. Kaj la averaĝa demanda tempo restis proksimume je la sama nivelo. Sed ĉi tie mi havas, prefere, la eraron de mia aparataro.
Ĉi tie finiĝas la unua rakonto. Ŝi estas la plej ofta. Kaj okazas al ĉiuj, sendepende de la sperto de la kliento, kiom kvalifikitaj programistoj ekzistas. Pli aŭ malpli frue ĝi okazas.
La dua rakonto, en kiu ni distribuas la ŝarĝon kaj optimumigas servilojn
- Ni kreskis kaj fariĝis seriozaj uloj. Kaj ni komprenas, ke ni havas kopion kaj estus bone por ni ekvilibrigi la ŝarĝon: skribu al la Majstro, kaj legu el la kopio. Kaj kutime ĉi tiu situacio aperas kiam ni volas prepari ian raportojn aŭ ETL. Kaj komerco estas tre feliĉa pri ĝi. Li vere volas diversajn raportojn kun amaso da kompleksaj analizoj.
- Raportoj daŭras multajn horojn, ĉar kompleksa analizo ne povas esti kalkulita en milisekundoj. Ni, kiel kuraĝuloj, skribas kodon. Ni faras en la inserta aplikaĵo, kiun ni registras sur la Majstro, ni faras raportojn pri la kopio.
- Ni distribuas la ŝarĝon.
- Ĉio funkcias perfekte. Ni estas bonegaj.
Kaj kiel aspektas ĉi tiu situacio? Specife, sur ĉi tiuj leteroj, mi ankaŭ aldonis la daŭron de transakcioj de la kopio por la daŭro de la transakcio. Ĉiuj aliaj grafikaĵoj rilatas nur al la Majstra Servilo.
Ĝis tiu tempo, mia raporta tabulo kreskis. Estas pli da ili. Ni povas vidi, ke la meza servila respondtempo estas stabila. Ni povas vidi, ke ni havas longan transakcion pri la kopio, kiu funkcias dum 2 horoj. Ni vidas la trankvilan laboron de la aŭtomata vakuo, kiu prilaboras mortajn liniojn. Kaj ni ĉiuj estas bonaj.
Specife, laŭ la testa tablojdo, ni daŭre ĝisdatigas la saldojn sur la kontoj tie. Kaj ni ankaŭ havas stabilan respondtempon laŭ peto, stabilan konsumon de rimedoj. Ĉio estas en ordo ĉe ni.
Ĉio estas en ordo ĝis la momento, kiam ĉi tiuj raportoj komencas pafi kontraŭ ni kontraŭ konflikto kun reproduktado. Kaj ili pafas reen je regulaj intervaloj.
Ni enretas kaj komencas legi kial tio okazas. Kaj ni trovas solvon.
La unua solvo estas pliigi la reproduktan latentecon. Ni scias, ke nia raporto daŭras 3 horojn. Agordu la reproduktan prokraston al 3 horoj. Ni komencas ĉion, sed ni daŭre havas problemojn kun la fakto, ke raportoj foje estas repafitaj.
Ni volas, ke ĉio estu perfekta. Ni iru plu. Kaj ni trovas bonegan agordon en la Interreto - hot_standby_feedback. Ni ŝaltas ĝin. Hot_standby_feedback permesas al ni teni la aŭtomatan vakuon funkciantan sur la Majstro. Tiel, ni tute forigas reproduktajn konfliktojn. Kaj ni ĉiuj bone laboras kun raportoj.
Kaj kio okazas kun la Majstra servilo ĉi-momente? Kaj kun la Majstra servilo, ni havas tutan katastrofon. Ni nun vidas diagramojn kun ambaŭ ĉi tiuj agordoj ŝaltitaj. Kaj ni vidas, ke la sesio sur la kopio iel komencis influi la situacion sur la Majstra servilo. Ĝi faras efikon ĉar ĝi suspendis la aŭtomatan vakuon, kiu purigas la mortajn liniojn. Nia tablograndeco denove eksplodis. La averaĝa demanda ekzekuttempo tra la tuta datumbazo ankaŭ eksplodis. La aŭtovakuoj iomete streĉiĝis.
Specife, sur nia telero, ni vidas, ke la datuma ĝisdatigo sur ĝi ankaŭ saltis al la ĉielo. La konsumo de procesoraj rimedoj simile multe pliiĝis. Ni denove ripetas super granda nombro da mortintaj senutilaj linioj. Kaj la tempo de respondo sur ĉi tiu tablojdo, la nombro da transakcioj falis.
Kiel ĝi aspektos, se ni ne scias, pri kio mi antaŭe parolis?
- Ni komencas serĉi problemojn. Se ni renkontis problemojn en la unua parto, ni scias, ke ĉi tio povas esti la kialo de longa transakcio kaj ni grimpas sur la Majstron. La problemo estas ĉe la Majstro. Kolbasoj lin. Li varmiĝas, li havas Ŝarĝmezumon de malpli ol cent.
- Petoj malrapidiĝas tie, sed ni ne vidas longdaŭrajn transakciojn tie. Kaj ni ne komprenas kio okazas. Ni ne scias kien serĉi.
- Kontrolado de servila aparataro. Eble nia atako kolapsis. Eble ni forbrulis la memorstangon. Jes, ĉio povas esti. Sed ne, la serviloj estas novaj, ĉio funkcias bone.
- Ĉiuj kuras: administrantoj, programistoj kaj la direktoro. Nenio helpas.
- Kaj en iu momento, ĉio subite komencas korekti sin.
Sur la kopio, tiutempe, la peto funkciis kaj foriris. Ni ricevis raporton. La komerco ankoraŭ estas feliĉa. Kiel vi povas vidi, nia tablo denove kreskis kaj ne malpliiĝos. Sur la diagramo kun sesioj, mi lasis pecon de ĉi tiu longa transakcio de la kopio, por ke vi povu taksi kiom da tempo necesas ĝis la situacio stabiliĝos.
La sesio malaperis. Kaj nur post iom da tempo la servilo venas pli-malpli en ordo. Kaj la averaĝa respondtempo por petoj sur la Mastra servilo normaliĝas. Ĉar, finfine, la aŭtomata vakuo ricevis la ŝancon purigi, marki ĉi tiujn mortajn liniojn. Kaj li komencis fari sian laboron. Kaj kiel rapide li faras ĝin, tiel rapide ni estos en ordo.
Sur la testa tablo, kie ni ĝisdatigas la kontajn saldojn, ni vidas ĝuste la saman bildon. La meza konta ĝisdatigotempo ankaŭ normaliĝas iom post iom. La rimedoj konsumitaj de la procesoro ankaŭ estas reduktitaj. Kaj la nombro da transakcioj por sekundo revenas al normalo. Sed denove, reen al normalo, ne same kiel ni havis antaŭ la akcidento.
Ĉiukaze, ni ricevas malaltiĝon en rendimento, kiel en la unua kazo, unu kaj duono ĝis du fojojn, kaj foje eĉ pli.
Ŝajnas, ke ni faris ĉion ĝuste. Distribuu la ŝarĝon. La ekipaĵo ne estas neaktiva. Laŭ la menso, ili rompis la petojn, sed tamen ĉio rezultis malbone.
- Ne ebligas hot_standby_feedback? Jes, ne rekomendas ŝalti ĝin sen precipe fortaj kialoj. Ĉar ĉi tiu tordaĵo rekte influas la Majstran Servilon kaj suspendas la laboron de la aŭtomalvakuo tie. Enŝaltante ĝin en iu kopio kaj forgesante ĝin, vi povas mortigi la Majstron kaj akiri grandajn problemojn kun la aplikaĵo.
- Ĉu pliigi max_standby_streaming_delay? Jes, por raportoj ĝi estas. Se vi havas tri-horan raporton kaj vi ne volas, ke ĝi kraŝu pro reproduktaj konfliktoj, tiam simple pliigu la prokraston. Longa raporto neniam postulas datumojn kiuj eniris la datumbazon nun. Se vi havas ĝin dum tri horoj, tiam vi funkcias ĝin dum iu malnova datumperiodo. Kaj vi, tiu tri horoj da prokrasto, tiu ses horoj da prokrasto - ne ludos neniun rolon, sed vi ricevos raportojn konsekvence kaj ne konos la problemojn kun ilia falo.
- Kompreneble, vi devas kontroli longajn sesiojn pri kopioj, precipe se vi decidas ebligi hot_standby_feedback sur kopio. Ĉar ĝi povus esti io ajn. Ni donis ĉi tiun rimarkon al la programisto por ke li provu la petojn. Li skribis frenezan peton. Li komencis kaj iris trinki teon, kaj ni ricevis la establitan Majstron. Aŭ ni lanĉis la malĝustan aplikaĵon tie. La situacioj estas diversaj. Sesioj pri kopioj devas esti kontrolitaj same zorge kiel ĉe la Majstro.
- Kaj se vi havas rapidajn kaj longajn demandojn pri kopioj, tiam en ĉi tiu kazo estas pli bone dividi ilin por distribui la ŝarĝon. Ĉi tio estas ligilo al streaming_delay. Por rapide havi unu kopion kun malgranda replika prokrasto. Por longdaŭraj raportpetoj, havu kopion, kiu povas postresti je 6 horoj, je tago. Ĉi tio estas tute normala situacio.
Ni forigas la konsekvencojn de la sama maniero:
- Ni trovas ŝvelintajn tablojn.
- Kaj ni kunpremas per la plej oportuna ilo, kiu konvenas al ni.
La dua rakonto finiĝas ĉi tie. Ni transiru al la tria rakonto.
Ankaŭ sufiĉe ofta por ni, en kiu ni faras la migradon.
- Ajna programaro kreskas. Postuloj ŝanĝiĝas. Ĉiukaze ni volas disvolviĝi. Kaj okazas, ke ni devas ĝisdatigi la datumojn en la tabelo, nome ruli la ĝisdatigon laŭ nia migrado al la nova funkcio, kiun ni efektivigas kiel parto de nia evoluo.
- La malnova datumformato ne taŭgas. Ni diru, ke ni nun turnu vin al la dua tablo, kie mi havas operaciojn pri ĉi tiuj kontoj. Kaj, ni diru, ke ili estis en rubloj, kaj ni decidis pliigi la precizecon kaj fari ĝin en kopekoj. Kaj por tio ni devas fari ĝisdatigon: multobligu la kampon kun la kvanto de la operacio per cent.
- En la hodiaŭa mondo, ni uzas aŭtomatajn datumbazajn versionajn ilojn. Ni diru . Ni registras nian migradon tie. Ni testas ĝin sur nia testa bazo. Ĉio estas en ordo. La ĝisdatigo funkcias. Blokoj funkcias dum kelka tempo, sed ni ricevas ĝisdatigitajn datumojn. Kaj ni povas lanĉi novan funkciojn pri tio. Ĉiuj provitaj kaj kontrolitaj. Ĉio konfirmite.
- Faris planitan laboron, efektivigis migradon.
Jen la migrado kun la ĝisdatigo prezentita antaŭ vi. Ĉar mi havas operaciojn pri kontoj, la plato estis 15 GB. Kaj ĉar ni ĝisdatigas ĉiun linion, ni duobligis la grandecon de la tabelo ĉar ni anstataŭis ĉiun linion.
Dum la migrado, ni ne povis fari ion ajn kun ĉi tiu etikedo, ĉar ĉiuj petoj por ĝi estis vicigitaj kaj atendis ke ĉi tiu ĝisdatigo finiĝos. Sed ĉi tie mi volas atentigi vin pri la nombroj, kiuj estas sur la vertikala akso. Tio estas, ni havas averaĝan petotempon antaŭ migrado en la regiono de 5 milisekundoj kaj ŝarĝo sur la procesoro, la nombro da blokaj operacioj por legado de disko-memoro estas malpli ol 7,5.
Ni migris kaj denove ricevis problemojn.
La migrado estis sukcesa, sed:
- La malnova funkcieco komencis funkcii pli longe.
- La tablo denove kreskis en grandeco.
- La ŝarĝo sur la servilo denove fariĝis pli ol ĝi estis.
- Kaj, kompreneble, ni ankoraŭ ludas kun la funkcio, kiu bone funkciis, ni iomete plibonigis ĝin.
Kaj ĉi tio estas denove ŝvelaĵo, kiu denove difektas niajn vivojn.
Ĉi tie mi pruvas, ke la tablo, kiel la antaŭaj du kazoj, ne revenos al la antaŭaj grandecoj. La averaĝa ŝarĝo sur la servilo ŝajnas esti taŭga.
Kaj se ni turnos nin al la tablo kun kontoj, tiam ni vidos, ke la meza petotempo duobliĝis por ĉi tiu tablo. La ŝarĝo sur la procesoro kaj la nombro da linioj ordigotaj en memoro saltis super 7,5, sed ĝi estis pli malalta. Kaj saltis en la kazo de procesoroj je 2 fojojn, en la kazo de blokaj operacioj je 1,5 fojojn, t.e. ni ricevis degeneron en servila rendimento. Kaj kiel rezulto - la degenero de la agado de nia apliko. Samtempe, la nombro da vokoj restis proksimume je la sama nivelo.
Kaj ĉi tie la ĉefa afero estas kompreni kiel fari tiajn migradojn ĝuste. Kaj ili devas esti faritaj. Ni faras ĉi tiujn migradojn sufiĉe regule.
- Tiaj grandaj migradoj ne fariĝas aŭtomate. Ili ĉiam devas esti kontrolitaj.
- Bezonas superrigardon de sperta persono. Se vi havas DBA en la teamo, lasu la DBA fari ĝin. Estas lia tasko. Se ne, tiam lasu la plej sperta persono fari ĝin, kiu scias kiel labori kun datumbazoj.
- La nova datumbaza skemo, eĉ se ni ĝisdatigas unu kolumnon, ni ĉiam preparas en etapoj, t.e. anticipe antaŭ ol la nova versio de la aplikaĵo aperos:
- Novaj kampoj estas aldonitaj en kiuj ni skribos nur la ĝisdatigitajn datumojn.
- Ni transdonas datumojn de la malnova kampo al la nova kampo en malgrandaj partoj. Kial ni faras ĉi tion? Unue, ni ĉiam kontrolas la procezon de ĉi tiu procezo. Ni scias, ke ni jam transdonis tiom da aroj kaj restas al ni tiom da.
- Kaj la dua pozitiva efiko estas, ke inter ĉiu tia aro ni fermas transakcion, malfermas novan, kaj ĉi tio ebligas, ke la aŭtomata vakuo funkciu laŭ la plato, por marki mortajn liniojn por reuzo.
- Por la linioj, kiuj aperos dum la funkciado de la aplikaĵo (ni ankoraŭ havas la malnovan aplikaĵon), ni aldonas ellasilon, kiu skribas novajn valorojn al novaj kampoj. En nia kazo, ĉi tio estas multipliko je cento de la malnova valoro.
- Se ni estas tute obstinaj kaj volas la saman kampon, tiam post kompletigo de ĉiuj migradoj kaj antaŭ ol ruliĝi la novan version de la aplikaĵo, ni simple renomas la kampojn. La malnovaj en iun inventitan nomon, kaj ni renomas la novajn kampojn al la malnovaj.
- Kaj nur post tio ni lanĉas novan version de la aplikaĵo.
Kaj samtempe ni ne ŝveliĝos kaj ne malfortiĝos en rendimento.
Jen la fino de la tria rakonto.
Kaj nun iom pli pri la iloj, kiujn mi menciis en la unua rakonto.
Antaŭ serĉi ŝvelaĵon, vi devas instali la etendon .
Por ke vi ne elpensu petojn, ni jam skribis ĉi tiujn petojn en nia laboro. Vi povas uzi ilin. Estas du petoj ĉi tie.
- La unua daŭras sufiĉe da tempo, sed ĝi montros al vi la precizajn valorojn de ŝvelaĵo laŭ la tabelo.
- La dua funkcias pli rapide kaj estas tre efika kiam vi bezonas rapide taksi ĉu estas ŝvelaĵo aŭ ne en la tabelo. Kaj vi ankaŭ devus kompreni, ke ĉiam estas ŝvelaĵo en Postgres-tabelo. Ĉi tio estas trajto de lia MVCC-modelo.
- Kaj 20% ŝvelaĵo estas bona por tabloj en la plej multaj kazoj. Tio estas, vi ne devas zorgi kaj kunpremi ĉi tiun tablon.
Ni eltrovis kiel identigi tabelojn, kiuj estas ŝvelitaj kun ni, krome, kiam ili estas ŝvelitaj kun senutilaj datumoj.
Nun pri kiel ripari ŝvelaĵon:
- Se ni havas malgrandan teleron kaj bonajn diskojn, t.e. sur telero ĝis gigabajto, estas tute eble uzi VACUUM FULL. Li prenos ekskluzivan seruron de vi dum kelkaj sekundoj, kaj bone, sed li faros ĉion rapide kaj severe. Kion faras VACUUM FULL? Ĝi bezonas ekskluzivan seruron sur la tablo kaj reverkas la vivajn vicojn de la malnovaj tabloj al la nova tablo. Kaj fine li anstataŭigas ilin. Forigas malnovajn dosierojn, anstataŭigas novajn per malnovaj. Sed dum la daŭro de sia laboro, ĝi prenas ekskluzivan seruron sur la tablo. Ĉi tio signifas, ke vi ne povas fari ion ajn kun ĉi tiu tabelo: nek skribi al ĝi, nek legi en ĝi, nek modifi ĝin. Kaj VACUUM FULL postulas plian diskospacon por skribi datumojn.
- Sekva Ilo . Laŭ ĝia principo, ĝi estas tre simila al VAKUA PLENA, ĉar ĝi ankaŭ anstataŭigas datumojn de malnovaj dosieroj al novaj kaj anstataŭigas ilin en la tabelo. Sed samtempe ĝi ne prenas ekskluzivan seruron sur la tablo ĉe la komenco de sia laboro, sed prenas ĝin nur en la momento, kiam ĝi havas pretajn datumojn por anstataŭigi la dosierojn. Ĝi havas la samajn diskrimedpostulojn kiel VACUUM FULL. Vi bezonas kroman diskospacon, kaj ĉi tio foje estas kritika se vi havas terabajtajn tabelojn. Kaj li estas sufiĉe gluema pri la procesoro, ĉar li aktive laboras kun I/O.
- La tria utileco estas . Ĝi estas pli zorgema pri rimedoj, ĉar ĝi funkcias laŭ iomete malsamaj principoj. La ĉefa esenco de pgcompacttable estas, ke ĝi movas ĉiujn vivajn vicojn al la komenco de la tabelo kun ĝisdatigoj en la tabelo. Kaj tiam ĝi komencas la vakuon sur ĉi tiu tablo, ĉar ni scias, ke ni havas vivajn vicojn komence kaj mortajn vicojn ĉe la fino. Kaj la vakuo mem fortranĉas ĉi tiun voston, tio estas, ĝi ne postulas multe da plia diskospaco. Kaj samtempe, ĝi ankoraŭ povas esti elpremita de rimedoj.
Ĉio kun iloj.
Se vi trovas la bloat-temon interesa rilate al fosado pli enen, jen kelkaj utilaj ligiloj por vi:
- estas la raporto de mia kolego. Ĝi estas ĝenerala pri kie la loko de Postgres iras en la kurso de sia laboro kaj vivo. Kaj estas tre granda kaj detala teknika peco por DBA-oj pri ŝvelaĵo.
- estas ligilo al nia deponejo, kie ni konservas amason da utilaj skriptoj por kontroli la datumbazan staton. Tie vi povas trovi bloat-serĉajn skriptojn.
- и ligiloj al iloj, kiuj helpos vin kunpremi la platojn.
- Ĉi tio estas afiŝo de mia kolego. Tie li sufiĉe serioze kaj teknike analizas ŝvelaĵon detale jam je nivelo proksima al administrantoj.
Ĉi tie mi provis montri hororan historion por programistoj, ĉar ili estas niaj rektaj klientoj de datumbazoj kaj devas kompreni al kio kaj kiaj agoj kondukas. Mi esperas, ke mi sukcesis. Dankon pro via atento!
Viaj demandoj
Dankon pro la raporto! Vi parolis pri kiel oni povas identigi problemojn. Kiel oni povas averti ilin? Tio estas, mi havis situacion, kie petoj pendis ne nur ĉar ili turniĝis al iuj eksteraj servoj. Estis nur kelkaj sovaĝaj kuniĝoj. Estis kelkaj etaj, sendanĝeraj petoj kiuj pendis ĉirkaŭe dum tago, kaj poste komencis fari ian sensencaĵon. Tio estas, ĝi estas tre simila al tio, kion vi priskribas. Kiel spuri ĝin? Sidu kaj konstante rigardu, kiu peto estas blokita? Kiel oni povas tion malhelpi?
En ĉi tiu kazo, ĉi tio estas tasko por la administrantoj de via kompanio, ne nepre por la DBA.
Mi estas administranto.
PostgreSQL havas vidon nomatan pg_stat_activity, kiu montras pritraktatajn demandojn. Kaj vi povas vidi kiom longe ĝi pendas tie.
Mi devas enveni ĉiujn 5 minutojn kaj rigardi?
Agordu cron kaj kontrolu. Se vi havas longan peton, skribu leteron kaj jen. Tio estas, vi ne bezonas rigardi per viaj okuloj, ĉi tio povas esti aŭtomatigita. Vi ricevos leteron, vi respondas al ĝi. Aŭ vi povas pafi aŭtomate.
Ĉu estas klaraj kialoj kial tio okazas?
Mi listigis kelkajn. Aliaj pli kompleksaj ekzemploj. Kaj povas esti longa konversacio.
Dankon pro la raporto! Mi volis klarigi pri la pg_repack ilo. Se ĝi ne bezonas ekskluzivan seruron, tiam...
Ŝi faras ekskluzivan seruron.
... tiam mi eble povus perdi datumojn. Ĉu mia aplikaĵo ne devus registri ion ajn ĉi-momente?
Ne, ĝi funkcias kviete kun la tablo, t.e. pg_repack unue transdonas ĉiujn vivajn liniojn, kiuj estas tie. Nature, ekzistas ia rekordo en la tabelo daŭriĝanta. Li nur ĵetas ĉi tiun ĉevalvoston.
Tio estas, ĉu li ankoraŭ faras ĝin ĉe la fino?
Fine, necesas ekskluziva seruro por interŝanĝi ĉi tiujn dosierojn.
Ĉu ĝi estos pli rapida ol VACUUM FULL?
VACUUM FULL, kiel ĝi komenciĝis, tuj prenis ekskluzivan seruron. Kaj ĝis li faros ĉion, li ne forlasos ŝin. Kaj pg_repack prenas ekskluzivan seruron nur dum la anstataŭigo de dosieroj. Je ĉi tiu punkto, vi ne skribas tie, sed la datumoj ne perdiĝos, ĉio estos en ordo.
Saluton! Vi parolis pri la laboro de aŭtovakuo. Estis grafikaĵo kun ruĝaj, flavaj kaj verdaj ĉeloj de la rekordo. Tio estas, flavaj — li markis ilin kiel forigitaj. Kaj kiel rezulto, vi povas skribi ion novan en ili?
Jes. Postgres ne forigas vicojn. Li havas tian specifecon. Se ni ĝisdatigis la linion, ni markis la malnovan kiel forigita. La transakcia id kiu ŝanĝis ĉi tiun linion venas tie supre, kaj ni skribas novan linion. Kaj ni havas sesiojn kiuj eble povas legi ilin. Iam ili fariĝas sufiĉe maljunaj. Kaj la esenco de la aŭtovakuo estas, ke ĝi trairas ĉi tiujn liniojn kaj markas ilin kiel nenecesaj. Kaj tie vi povas anstataŭigi la datumojn.
Mi komprenas. Sed la demando ne temas pri tio. Mi ne konsentis. Ni diru, ke ni havas tablon. Ĝi havas variagrandajn kampojn. Kaj se mi provas enmeti ion novan, tiam ĝi eble simple ne taŭgas en la malnovan ĉelon.
Ne, tie ĉiukaze la tuta linio estas ĝisdatigita. Postgres havas du stokadmodelojn. Ĝi elektas el la datumtipo. Estas datumoj, kiuj estas konservitaj rekte en la tabelo, kaj estas ankaŭ tos-datumoj. Ĉi tiuj estas grandaj kvantoj da datumoj: teksto, json. Ili estas konservitaj en apartaj tabeloj. Kaj laŭ ĉi tiuj tabuletoj okazas la sama historio kun ŝvelaĵo, tio estas, ĉio samas. Ili estas nur listigitaj aparte.
Dankon pro la raporto! Kiom akcepteble estas uzi deklarojn-tempopetojn por limigi la daŭron?
Tre akceptebla. Ni uzas ĝin ĉie. Kaj ĉar ni ne havas niajn proprajn servojn, ni provizas malproksiman subtenon, ekzistas sufiĉe diversaj klientoj. Kaj ĉiuj estas sufiĉe kontentaj pri tio. Tio estas, ni havas laborpostenojn en cron tiu kontrolo. Estas nur, ke la daŭro de la kunsidoj estas intertraktata kun la kliento, antaŭ kiu ni ne najlas. Ĝi povus esti unu minuto, ĝi povus esti 10 minutoj. Ĝi dependas de la ŝarĝo sur la bazo kaj ĝia celo. Sed ni ĉiuj uzas pg_stat_activity.
Dankon pro la raporto! Mi provas provi vian raporton por miaj kandidatiĝoj. Kaj ŝajnas, ke ni komencas transakcion ĉie, kaj ni eksplicite kompletigas ĝin ĉie. Se iu escepto, tiam la sama restarigo okazas. Kaj tiam mi pensis. Post ĉio, la transakcio povas komenci ne eksplicite. Ĉi tio estas sugesto por la knabino, mi supozas. Se mi nur faras rekordan ĝisdatigon, ĉu la transakcio komenciĝos en PostgreSQL kaj nur finiĝos kiam la konekto estas malkonektita?
Se vi parolas nun pri la aplika nivelo, tiam ĝi dependas de la pelilo, kiun vi uzas, de la ORM, kiu estas uzata. Estas multaj agordoj tie. Se vi havas aŭtomatan transdonon ebligita, tiam transakcio komenciĝas tie kaj tuj fermiĝas.
Tio estas, ĝi fermiĝas tuj post la ĝisdatigo?
Ĝi dependas de la agordoj. Mi nomis unu agordon. Ĉi tio estas aŭtomata engaĝiĝo. Ŝi estas sufiĉe komuna. Se ĝi estas ebligita, tiam la transakcio estis malfermita kaj fermita. Krom se vi eksplicite diris "komenci transakcion" kaj "fini transakcion", sed simple lanĉis peton en la seancon.
Saluton! Dankon pro la raporto! Imagu, ke ni havas datumbazon, kiu ŝvelas kaj ŝveliĝas kaj tiam la servilo elĉerpigas spacon. Ĉu ekzistas iloj por ripari ĉi tiun situacion?
La loko sur la servilo en bona maniero devas esti monitorita.
Ekzemple, DBA iris por trinki teon, estis ĉe feriejo, ktp.
Kiam dosiersistemo estas kreita, almenaŭ iom da rezerva spaco estas kreita kie datumoj ne estas skribitaj.
Kio se ĝi estas tute nulo?
Tie ĝi nomiĝas rezervita spaco, tio estas, ĝi povas esti liberigita, kaj laŭ kiom granda ĝi estis kreita, vi ricevis liberan spacon. Defaŭlte, mi ne scias kiom da estas. Kaj en alia kazo, liveru diskojn, por ke vi havu lokon por fari restarigan operacion. Vi povas forigi iun tabelon, kiun vi garantias, ke vi ne bezonos.
Ĉu ne ekzistas aliaj iloj?
Ĝi ĉiam estas manfarita. Kaj en la loko estas malkaŝita, kio estas pli bone fari tie, ĉar estas datumoj, kiuj estas kritikaj, estas ne-kritikaj. Kaj por ĉiu datumbazo kaj aplikaĵo, kiu funkcias kun ĝi, ĝi dependas de la komerco. Ĉiam oni decidas surloke.
Dankon pro la raporto! Mi havas du demandojn. Unue, vi montris lumbildojn, kie estis montrite, ke en la kazo de penditaj transakcioj, kaj la kvanto de tabelspaco kaj la grandeco de la indekso kreskas. Kaj plu sur la raporto estis amaso da utilecoj kiuj pakas la tablojdon. Kaj kio pri la indekso?
Ili ankaŭ pakas ilin.
Sed la vakuo ne influas la indekson?
Iuj funkcias kun indekso. Ekzemple pg_rapack, pgcompacttable. Vakuo rekreas indeksojn, influas ilin. VACUUM FULL havas la esencon anstataŭi ĉion, t.e. ĝi funkcias kun ĉiuj.
Kaj la dua demando. Mi ne komprenis kial raportoj pri kopioj tiom dependas de reproduktado mem. Ŝajnis al mi, ke raportoj legas, kaj reproduktado skribas.
Kio kaŭzas reproduktan konflikton? Ni havas Majstron pri kiu procezoj okazas. Ni havas aŭtomatan vakuon. Aŭtovakuo fakte, kion ĝi faras? Li eltranĉas kelkajn malnovajn liniojn. Se en ĉi tiu tempo ni havas peton sur la kopio, kiu legas ĉi tiujn malnovajn liniojn, kaj sur la Majstro estis situacio, ke la aŭtomalplena markis ĉi tiujn liniojn kiel eble por reverki, tiam ni anstataŭis ilin. Kaj ni ricevis datumpakaĵon, kiam ni devas reverki la liniojn, kiujn la peto bezonas sur la kopio, tiam la replika procezo atendos la tempodaŭron, kiun vi agordis. Kaj poste PostgreSQL decidos kio estas pli grava por ĝi. Kaj reproduktado estas pli grava por li ol peto, kaj li pafos la peton fari ĉi tiujn ŝanĝojn sur la kopio.
Andreo, mi havas demandon. Ĉi tiuj mirindaj grafikaĵoj, kiujn vi montris dum la prezento, ĉu ĉi tio estas la rezulto de iu laboro de via utileco? Kiel estis faritaj la leteroj?
Ĉi tio estas servo .
Ĉu ĉi tio estas komerca produkto?
Jes. Ĉi tio estas komerca produkto.
fonto: www.habr.com