ProHoster > Blogs > Administrācija > Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Iesaku izlasÄ«t Andreja Saļņikova 2016. gada sākuma ziņojuma atÅ”ifrējumu ā€œTipiskas kļūdas lietojumprogrammās, kas noved pie uzpÅ«Å”anās postgresqlā€

Å ajā ziņojumā es analizÄ“Å”u galvenās lietojumprogrammu kļūdas, kas rodas lietojumprogrammas koda projektÄ“Å”anas un rakstÄ«Å”anas stadijā. Un es pieņemÅ”u tikai tās kļūdas, kas Postgresql izraisa uzpÅ«Å”anos. Parasti tas ir visas jÅ«su sistēmas veiktspējas beigu sākums, lai gan sākotnēji nebija redzami nekādi priekÅ”noteikumi tam.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Prieks visus sveikt! Å is ziņojums nav tik tehnisks kā iepriekŔējais mana kolēģa ziņojums. Å is pārskats galvenokārt ir paredzēts aizmugursistēmas izstrādātājiem, jo ā€‹ā€‹mums ir diezgan liels klientu skaits. Un viņi visi pieļauj vienas un tās paÅ”as kļūdas. Es jums pastāstÄ«Å”u par tiem. PaskaidroÅ”u, pie kā liktenÄ«gām un sliktām lietām noved Ŕīs kļūdas.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Kāpēc tiek pieļautas kļūdas? Tie tiek darÄ«ti divu iemeslu dēļ: nejauÅ”i, varbÅ«t tas izdosies, un dažu mehānismu nezināŔanas dēļ, kas rodas lÄ«menÄ« starp datu bāzi un lietojumprogrammu, kā arÄ« paŔā datu bāzē.

Es sniegÅ”u jums trÄ«s piemērus ar Å”ausmÄ«gām bildēm par to, cik slikti viss ir kļuvis. Es Ä«si pastāstÄ«Å”u par mehānismu, kas tur notiek. Un kā ar tām rÄ«koties, kad tās notikuÅ”as un kādas profilaktiskās metodes izmantot, lai nepieļautu kļūdas. Es jums pastāstÄ«Å”u par palÄ«grÄ«kiem un sniegÅ”u noderÄ«gas saites.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Es izmantoju testa datubāzi, kurā man bija divas tabulas. Viena plāksne ar klientu kontiem, otra ar darÄ«jumiem Å”ajos kontos. Ar zināmu biežumu mēs atjauninām Å”o kontu atlikumus.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Plāksnes sākotnējie dati: tā ir diezgan maza, 2 MB. ArÄ« reakcijas laiks datubāzei un tieÅ”i zÄ«mei ir ļoti labs. Un diezgan laba slodze - 2 operācijas sekundē pēc plāksnes.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un Å”ajā ziņojumā es jums parādÄ«Å”u grafikus, lai jÅ«s varētu skaidri saprast, kas notiek. Vienmēr bÅ«s 2 slaidi ar grafikiem. Pirmais slaids ir tas, kas kopumā notiek serverÄ«.

Un Å”ajā situācijā mēs redzam, ka mums patieŔām ir maza zÄ«me. Indekss ir mazs - 2 MB. Å is ir pirmais grafiks kreisajā pusē.

ArÄ« vidējais atbildes laiks serverÄ« ir stabils un Ä«ss. Å is ir augŔējais labais grafiks.

ApakŔējā kreisajā grafikā ir redzami visilgākie darÄ«jumi. Mēs redzam, ka darÄ«jumi tiek pabeigti ātri. Un autovakuums Å”eit vēl nedarbojas, jo tas bija sākuma tests. Tas turpinās darboties un mums noderēs.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Otrais priekÅ”mets vienmēr bÅ«s veltÄ«ts pārbaudāmajai plāksnei. Å ajā situācijā mēs pastāvÄ«gi atjaunojam klienta kontu atlikumus. Un mēs redzam, ka vidējais atbildes laiks atjaunināŔanas darbÄ«bai ir diezgan labs, mazāks par milisekundi. Mēs redzam, ka procesora resursi (Å”is ir augŔējā labajā grafikā) arÄ« tiek patērēti vienmērÄ«gi un diezgan maz.

ApakŔējā labajā grafikā ir parādÄ«ts, cik daudz darbÄ«bas un diska atmiņas mēs iztērējam, meklējot vēlamo lÄ«niju pirms tās atjaunināŔanas. Un operāciju skaits pēc zÄ«mes ir 2 sekundē, kā jau teicu sākumā.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un tagad mums ir traģēdija. Nez kāpēc ir sen aizmirsts darījums. Iemesli parasti ir banāli:

  • Viens no izplatÄ«tākajiem ir tas, ka mēs sākām piekļūt ārējam pakalpojumam lietojumprogrammas kodā. Un Å”is pakalpojums mums neatbild. Tas ir, mēs atvērām darÄ«jumu, veicām izmaiņas datu bāzē un pārgājām no lietojumprogrammas uz e-pasta lasÄ«Å”anu vai uz citu mÅ«su infrastruktÅ«ras pakalpojumu, un kāda iemesla dēļ tā mums neatbild. Un mÅ«su sesija ir iestrēgusi tādā stāvoklÄ«, ka nav zināms, kad tas tiks atrisināts.
  • Otrā situācija ir tad, kad mÅ«su kodā kāda iemesla dēļ ir noticis izņēmums. Un izņēmuma gadÄ«jumā mēs neapstrādājām darÄ«juma slēgÅ”anu. Un mēs beidzām ar pakarināŔanas sesiju ar atvērtu darÄ«jumu.
  • Un arÄ« pēdējais ir diezgan izplatÄ«ts gadÄ«jums. Å is ir zemas kvalitātes kods. Daži ietvari atver darÄ«jumu. Tas uzkaras, un jÅ«s, iespējams, lietojumprogrammā nezināt, ka tas ir pakārts.

Kur tādas lietas ved?

Tiktāl, ka mÅ«su tabulas un indeksi sāk dramatiski uzbriest. Tas ir tieÅ”i tāds pats uzpÅ«Å”anās efekts. AttiecÄ«bā uz datu bāzi tas nozÄ«mēs, ka ļoti strauji palielināsies datu bāzes reakcijas laiks un palielināsies datu bāzes servera slodze. Tā rezultātā cietÄ«s mÅ«su lietojumprogramma. Jo, ja kodā pavadÄ«jāt 10 milisekundes, pieprasot datu bāzei, bet 10 milisekundes izmantojāt loÄ£ikai, tad funkcijas izpildei bija nepiecieÅ”amas 20 milisekundes. Un tagad jÅ«su situācija bÅ«s ļoti bēdÄ«ga.

Un paskatÄ«simies, kas notiks. ApakŔējā kreisajā grafikā redzams, ka mums ir ilgs un ilgs darÄ«jums. Un, ja mēs paskatāmies uz augŔējo kreiso grafiku, mēs redzam, ka mÅ«su tabulas izmērs pēkŔņi ir pieaudzis no diviem megabaitiem lÄ«dz 300 megabaitiem. Tajā paŔā laikā datu apjoms tabulā nav mainÄ«jies, t.i., tur ir diezgan liels atkritumu daudzums.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

ArÄ« vispārējā situācija attiecÄ«bā uz vidējo servera reakcijas laiku ir mainÄ«jusies par vairākām kārtām. Tas ir, visi pieprasÄ«jumi serverÄ« sāka pilnÄ«bā samazināties. Un tajā paŔā laikā autovakuuma veidā tika iedarbināti iekŔējie Postgres procesi, kas cenÅ”as kaut ko darÄ«t un patērē resursus.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Kas notiek ar mÅ«su zÄ«mi? Tas pats. MÅ«su vidējais reakcijas laiks saskaņā ar zÄ«mi ir uzlēcis par vairākām kārtām. Konkrēti, runājot par patērētajiem resursiem, mēs redzam, ka procesora slodze ir ļoti pieaugusi. Å is ir augŔējais labais grafiks. Un tas ir palielinājies, jo procesoram ir jāŔķiro daudz nederÄ«gu rindu, meklējot vajadzÄ«go. Å is ir apakŔējā labajā pusē esoÅ”ais grafiks. Un tā rezultātā mÅ«su zvanu skaits sekundē sāka ļoti bÅ«tiski samazināties, jo datu bāzei nebija laika apstrādāt tikpat daudz pieprasÄ«jumu.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Mums ir jāatgriežas dzÄ«vē. Mēs ieejam tieÅ”saistē un uzzinām, ka ilgstoÅ”i darÄ«jumi rada problēmas. Mēs atrodam un nogalinām Å”o darÄ«jumu. Un mums viss kļūst normāli. Viss darbojas kā nākas.

Mēs nomierinājāmies, bet pēc kāda laika sākam pamanīt, ka aplikācija nedarbojas tāpat kā pirms ārkārtas situācijas. Pieprasījumi joprojām tiek apstrādāti lēnāk un ievērojami lēnāk. Manā piemērā pusotru līdz divas reizes lēnāk. Arī servera slodze ir lielāka, nekā tā bija pirms avārijas.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un jautājums: "Kas Å”obrÄ«d notiek ar bāzi?" Un ar bāzi rodas Ŕāda situācija. DarÄ«jumu diagrammā var redzēt, ka tas ir apstājies un Ä«sti nav ilgtermiņa darÄ«jumu. Bet negadÄ«juma laikā zÄ«mes izmērs nāvējoÅ”i palielinājās. Un kopÅ” tā laika tie nav samazinājuÅ”ies. Vidējais laiks uz bāzes ir stabilizējies. Un atbildes, Ŕķiet, nāk adekvāti mums pieņemamā ātrumā. Autovakuums kļuva aktÄ«vāks un sāka kaut ko darÄ«t ar zÄ«mi, jo tai ir jāizsijā vairāk datu.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Konkrēti, saskaņā ar testa plāksnÄ«ti ar kontiem, kur mēs mainām atlikumus: Ŕķiet, ka pieprasÄ«juma reakcijas laiks ir normalizējies. Bet patiesÄ«bā tas ir pusotru reizi lielāks.

Un no procesora slodzes mēs redzam, ka procesora slodze nav atgriezusies vajadzÄ«gajā vērtÄ«bā pirms avārijas. Un iemesli ir tieÅ”i apakŔējā labajā grafikā. Var redzēt, ka tur tiek meklēts noteikts atmiņas apjoms. Tas ir, lai atrastu vajadzÄ«go rindu, mēs iztērējam datu bāzes servera resursus, Ŕķirojot nederÄ«gos datus. DarÄ«jumu skaits sekundē ir stabilizējies.

Kopumā labi, bet situācija ir sliktāka nekā tā bija. Notīrīt datu bāzes degradāciju mūsu lietojumprogrammas, kas darbojas ar Ŕo datu bāzi, sekas.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un, lai saprastu, kas tur notiek, ja nebijāt pie iepriekŔējā ziņojuma, tagad iegÅ«sim nelielu teoriju. Teorija par iekŔējo procesu. Kāpēc auto putekļsÅ«cējs un ko tas dara?

Burtiski Ä«si, lai saprastu. Kādā brÄ«dÄ« mums ir galds. Mums tabulā ir rindas. Å Ä«s lÄ«nijas var bÅ«t aktÄ«vas, dzÄ«vas un tādas, kas mums tagad ir vajadzÄ«gas. Attēlā tie ir atzÄ«mēti zaļā krāsā. Un ir beiguŔās rindas, kas jau ir izstrādātas, atjauninātas, un tajās ir parādÄ«juÅ”ies jauni ieraksti. Un tie ir atzÄ«mēti, ka tie vairs nav interesanti datu bāzei. Bet tie ir tabulā Postgres funkcijas dēļ.

Kāpēc jums ir nepiecieÅ”ams automaŔīnas putekļsÅ«cējs? Kādā brÄ«dÄ« pienāk autovakuums, piekļūst datu bāzei un jautā: "LÅ«dzu, iedodiet man vecākā darÄ«juma ID, kas paÅ”laik ir atvērts datu bāzē." Datubāze atgriež Å”o ID. Un autovakuums, paļaujoties uz to, Ŕķiro tabulas rindas. Un, ja viņŔ redz, ka dažas rindas mainÄ«ja daudz senāki darÄ«jumi, tad viņam ir tiesÄ«bas tās atzÄ«mēt kā rindas, kuras turpmāk varēsim izmantot atkārtoti, ierakstot tur jaunus datus. Tas ir fona process.

Å obrÄ«d mēs turpinām strādāt ar datu bāzi un turpinām veikt dažas izmaiņas tabulā. Un Å”ajās rindās, kuras mēs varam atkārtoti izmantot, mēs ierakstām jaunus datus. Un lÄ«dz ar to mēs iegÅ«stam ciklu, t.i., visu laiku tur parādās kādas beigtas vecās rindas, to vietā pierakstām jaunas, kas mums vajadzÄ«gas. Un tas ir normāls PostgreSQL darba stāvoklis.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Kas notika avārijas laikā? Kā tur notika Ŕis process?

Mums bija zÄ«me kaut kādā stāvoklÄ«, dažas dzÄ«vas, dažas beigtas lÄ«nijas. Auto putekļu sÅ«cējs ir klāt. ViņŔ jautāja datubāzei, kas ir mÅ«su vecākais darÄ«jums un kāds ir tā ID. Es saņēmu Å”o ID, kas varētu bÅ«t pirms daudzām stundām, varbÅ«t pirms desmit minÅ«tēm. Tas ir atkarÄ«gs no tā, cik liela slodze ir jÅ«su datubāzei. Un viņŔ meklēja lÄ«nijas, kuras varētu atzÄ«mēt kā atkārtoti izmantotas. Un es neatradu Ŕādas rindas mÅ«su tabulā.

Bet Å”ajā laikā mēs turpinām strādāt ar tabulu. Mēs tajā kaut ko darām, atjaunojam, mainām datus. Kas datu bāzei Å”ajā laikā jādara? Viņai neatliek nekas cits kā esoŔās tabulas beigās pievienot jaunas rindas. Un lÄ«dz ar to mÅ«su galda izmērs sāk uzbriest.

PatiesÄ«bā mums ir vajadzÄ«gas zaļās lÄ«nijas, lai darbotos. Bet Ŕādas problēmas laikā izrādās, ka zaļo lÄ«niju procentuālais daudzums visā tabulā ir ārkārtÄ«gi zems.

Kad mēs izpildām vaicājumu, datu bāzei ir jāiet cauri visām rindām: gan sarkanajai, gan zaļajai, lai atrastu vajadzÄ«go rindiņu. Tabulas uzpÅ«Å”anās ar bezjēdzÄ«giem datiem tiek saukta par ā€œuzpÅ«Å”anosā€, kas arÄ« patērē mÅ«su diska vietu. Atcerieties, ka tas bija 2 MB, tas kļuva par 300 MB? Tagad mainiet megabaitus uz gigabaitiem, un jÅ«s ātri zaudēsit visus savus diska resursus.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Kādas sekas tas var atstāt uz mums?

  • Manā piemērā tabula un indekss pieauga 150 reizes. Dažiem mÅ«su klientiem ir bijuÅ”i vairāk letālu gadÄ«jumu, kad viņiem vienkārÅ”i sāka pietrÅ«kt vietas diskā.
  • PaÅ”u galdu izmērs nekad nesamazināsies. Autovakuums dažos gadÄ«jumos var nogriezt galda asti, ja ir tikai nedzÄ«vas lÄ«nijas. Bet, tā kā notiek nemitÄ«ga rotācija, viena zaļā lÄ«nija var sastingt beigās un netikt atjaunināta, bet visas pārējās tiks pierakstÄ«tas kaut kur plāksnes sākumā. Bet tas ir tik maz ticams notikums, ka jÅ«su galds pats samazināsies, tāpēc jums nevajadzētu uz to cerēt.
  • Datubāzei ir jāsakārto vesela virkne bezjēdzÄ«gu rindu. Un mēs izŔķērdējam diska resursus, tērējam procesora resursus un elektrÄ«bu.
  • Un tas tieÅ”i ietekmē mÅ«su lietojumprogrammu, jo, ja sākumā mēs pieprasÄ«jumam pavadÄ«jām 10 milisekundes, kodam ā€” 10 milisekundes, tad avārijas laikā mēs sākām tērēt sekundi pieprasÄ«jumam un 10 milisekundes kodam, t.i. lietojumprogrammu veiktspējas apjoms ir samazinājies. Kad negadÄ«jums tika atrisināts, mēs sākām tērēt 20 milisekundes pieprasÄ«jumam, 10 milisekundes kodam. Tas nozÄ«mē, ka produktivitāte joprojām ir kritusies pusotru reizi. Un tas viss ir viena darÄ«juma dēļ, kas iesaldēja, iespējams, mÅ«su vainas dēļ.
  • Un jautājums: ā€œKā mēs varam visu atgÅ«t?ā€, lai ar mums viss bÅ«tu kārtÄ«bā un lÅ«gumi ienāktu tikpat ātri kā pirms avārijas.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Šim nolūkam tiek veikts noteikts darba cikls.

Vispirms jāatrod problemātiskās tabulas, kas ir uzpÅ«stas. Mēs saprotam, ka dažās tabulās ieraksts ir aktÄ«vāks, citās mazāk aktÄ«vs. Un Å”im nolÅ«kam mēs izmantojam paplaÅ”inājumu pgstattuple. Instalējot Å”o paplaÅ”inājumu, varat rakstÄ«t vaicājumus, kas palÄ«dzēs atrast tabulas, kas ir diezgan uzpÅ«stas.

Kad esat atradis Ŕīs tabulas, tās ir jāsaspiež. Tam jau ir rÄ«ki. MÅ«su uzņēmumā mēs izmantojam trÄ«s rÄ«kus. Pirmais ir iebÅ«vētais VACUUM FULL. ViņŔ ir nežēlÄ«gs, skarbs un nežēlÄ«gs, bet dažreiz viņŔ ir ļoti noderÄ«gs. Pg_repack Šø pgcompacttable - Å Ä«s ir treÅ”o puÅ”u utilÄ«tas tabulu saspieÅ”anai. Un viņi rÅ«pÄ«gāk izturas pret datubāzi.

Tos izmanto atkarÄ«bā no tā, kas jums ir ērtāk. Bet par to es jums pastāstÄ«Å”u paŔās beigās. Galvenais ir tas, ka ir trÄ«s instrumenti. Ir daudz, no kā izvēlēties.

Pēc tam, kad esam visu izlabojuÅ”i un pārliecinājuÅ”ies, ka viss ir kārtÄ«bā, mums jāzina, kā novērst Å”o situāciju nākotnē:

  • To var diezgan viegli novērst. Jums jāuzrauga sesiju ilgums galvenajā serverÄ«. ÄŖpaÅ”i bÄ«stamas sesijas dÄ«kstāvē transakcijas stāvoklÄ«. Tie ir tie, kuri tikko atvēra darÄ«jumu, kaut ko izdarÄ«ja un aizgāja vai vienkārÅ”i pakārās, apmaldÄ«jās kodā.
  • Un jums kā izstrādātājiem ir svarÄ«gi pārbaudÄ«t savu kodu, kad rodas Ŕādas situācijas. To nav grÅ«ti izdarÄ«t. Å Ä« bÅ«s noderÄ«ga pārbaude. JÅ«s izvairÄ«sities no daudzām ā€œbērnÄ«gāmā€ problēmām, kas saistÄ«tas ar ilgstoÅ”iem darÄ«jumiem.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Å ajos grafikos es vēlējos jums parādÄ«t, kā mainÄ«jās zÄ«me un datu bāzes darbÄ«ba pēc tam, kad Å”ajā gadÄ«jumā izgāju cauri zÄ«mei ar VACUUM FULL. Man tā nav ražoÅ”ana.

Tabulas izmērs nekavējoties atgriezās normālā darbības stāvoklī pāris megabaitu apmērā. Tas būtiski neietekmēja servera vidējo atbildes laiku.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Taču Ä«paÅ”i attiecÄ«bā uz mÅ«su testa zÄ«mi, kurā mēs atjauninājām konta atlikumus, mēs redzam, ka vidējais atbildes laiks pieprasÄ«jumam atjaunināt datus zÄ«mē tika samazināts lÄ«dz lÄ«menim, kas bija pirms ārkārtas situācijas. Procesora patērētie resursi Ŕī pieprasÄ«juma izpildei arÄ« samazinājās lÄ«dz lÄ«menim pirms avārijas. Un apakŔējā labajā grafikā redzams, ka tagad mēs atrodam tieÅ”i to lÄ«niju, kas mums ir vajadzÄ«ga uzreiz, neizejot cauri miruÅ”o lÄ«niju kaudzēm, kas bija pirms tabulas saspieÅ”anas. Un vidējais pieprasÄ«juma laiks palika aptuveni tādā paŔā lÄ«menÄ«. Bet Å”eit drÄ«zāk manā aparatÅ«rā ir kļūda.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Šeit pirmais stāsts beidzas. Tas ir visizplatītākais. Un tas notiek ar visiem, neatkarīgi no klienta pieredzes un programmētāju kvalifikācijas. Agri vai vēlu tas notiek.

Otrais stāsts, kurā sadalām slodzi un optimizējam servera resursus

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

  • Mēs jau esam pieauguÅ”i un kļuvuÅ”i par nopietniem puiÅ”iem. Un mēs saprotam, ka mums ir replika, un mums bÅ«tu labi sabalansēt slodzi: rakstÄ«t Meistaram un lasÄ«t no replika. Un parasti Ŕāda situācija rodas, kad mēs vēlamies sagatavot kaut kādas atskaites vai ETL. Un bizness par to ļoti priecājas. ViņŔ patieŔām vēlas dažādus pārskatus ar daudz sarežģītu analÄ«zi.
  • Pārskati aizņem daudzas stundas, jo sarežģītu analÄ«zi nevar aprēķināt milisekundēs. Mēs, tāpat kā drosmÄ«gi puiÅ”i, rakstām kodu. IevietoÅ”anas lietojumprogrammā mēs veicam ierakstu uz Master un izpildām ziņojumus par repliku.
  • Slodzes sadalÄ«Å”ana.
  • Viss strādā perfekti. Mēs esam lieliski.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un kā izskatās Ŕī situācija? Konkrēti Å”ajos grafikos es pievienoju arÄ« darÄ«jumu ilgumu no kopijas darÄ«juma ilgumam. Visas pārējās diagrammas attiecas tikai uz galveno serveri.

LÄ«dz tam laikam mana ziņojumu dēlis bija pieaudzis. Viņu ir vairāk. Mēs redzam, ka vidējais servera reakcijas laiks ir stabils. Mēs redzam, ka replikā mums ir ilgstoÅ”s darÄ«jums, kas ilgst 2 stundas. Mēs redzam klusu autovakuuma darbÄ«bu, kas apstrādā miruŔās lÄ«nijas. Un ar mums viss ir kārtÄ«bā.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Konkrēti, saskaņā ar pārbaudÄ«to plāksnÄ«ti turpinām atjaunināt kontu atlikumus. Un mums ir arÄ« stabils atbildes laiks uz pieprasÄ«jumiem, stabils resursu patēriņŔ. Pie mums viss ir kārtÄ«bā.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Viss ir kārtÄ«bā lÄ«dz brÄ«dim, kad Å”ie pārskati sāk aktivizēties konflikta ar replikāciju dēļ. Un tie Å”auj ar regulāriem intervāliem.

Mēs pārejam tieÅ”saistē un sākam lasÄ«t, kāpēc tas notiek. Un mēs atrodam risinājumu.

Pirmais risinājums ir palielināt replikācijas latentumu. Mēs zinām, ka mūsu pārskats ilgst 3 stundas. Mēs iestatījām replikācijas aizkavi uz 3 stundām. Mēs visu palaižam, taču joprojām pastāv problēmas ar ziņojumiem, kas dažkārt tiek atcelti.

Mēs vēlamies, lai viss bÅ«tu ideāli. Kāpjam tālāk. Un mēs atradām forÅ”u iestatÄ«jumu internetā - hot_standby_feedback. Ieslēdzam to. Hot_standby_feedback ļauj mums aizkavēt Master autovakuumu. Tādējādi mēs pilnÄ«bā atbrÄ«vojamies no replikācijas konfliktiem. Un ar atskaitēm mums viss darbojas labi.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un kas Å”obrÄ«d notiek ar galveno serveri? Un mums ir pilnÄ«gas problēmas ar galveno serveri. Tagad mēs redzam diagrammas, kad man ir iespējoti abi Å”ie iestatÄ«jumi. Un mēs redzam, ka sesija mÅ«su replikā kaut kā sāka ietekmēt situāciju galvenajā serverÄ«. Viņai ir ietekme, jo viņa apturēja autovakuumu, kas notÄ«ra miruŔās lÄ«nijas. MÅ«su galda izmērs atkal ir strauji pieaudzis. Vidējais vaicājumu izpildes laiks visā datu bāzē arÄ« strauji pieauga. Autovakuumi nedaudz nostiprinājās.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Konkrēti, no mÅ«su plāksnes mēs redzam, ka arÄ« datu atjauninājums uz tā uzlēca debesÄ«s. CPU patēriņŔ lÄ«dzÄ«gi ir ievērojami palielinājies. Mēs atkal ejam cauri lielam skaitam miruÅ”u, bezjēdzÄ«gu lÄ«niju. Un reakcijas laiks Å”ai zÄ«mei un darÄ«jumu skaits ir samazinājies.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Kā tas izskatÄ«sies, ja mēs nezinām, par ko es runāju iepriekÅ”?

  • Mēs sākam meklēt problēmas. Ja mēs saskārāmies ar problēmām pirmajā daļā, mēs zinām, ka tas var bÅ«t saistÄ«ts ar ilgstoÅ”u darÄ«jumu un dodieties uz Meistaru. Mums ir problēma ar Master. Desas viņam. Tas uzsilst, tā vidējā slodze ir aptuveni simts.
  • PieprasÄ«jumi tur notiek lēni, taču mēs neredzam nekādus ilgstoÅ”us darÄ«jumus. Un mēs nesaprotam, kas par lietu. Mēs nesaprotam, kur meklēt.
  • Pārbaudām servera aprÄ«kojumu. VarbÅ«t mÅ«su reids avarēja. VarbÅ«t mÅ«su atmiņas karte ir izdegusi. Jā, viss var notikt. Bet nē, serveri ir jauni, viss darbojas labi.
  • Visi darbojas: administratori, izstrādātāji un direktors. Nekas nepalÄ«dz.
  • Un kādā brÄ«dÄ« viss pēkŔņi sāk laboties.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Å obrÄ«d pieprasÄ«jums par mÅ«su repliku tika apstrādāts un atstāts. Mēs saņēmām ziņojumu. Bizness joprojām ir laimÄ«gs. Kā redzat, mÅ«su zÄ«me atkal ir augusi un negrasās sarukt. Diagrammā ar sesijām es atstāju daļu no Ŕī garā darÄ«juma no kopijas, lai jÅ«s varētu novērtēt, cik ilgs laiks nepiecieÅ”ams, lÄ«dz situācija stabilizējas.

Sesija ir beigusies. Un tikai pēc kāda laika serveris nāk vairāk vai mazāk kārtÄ«bā. Un vidējais atbildes laiks pieprasÄ«jumiem galvenajā serverÄ« atgriežas normālā stāvoklÄ«. Jo beidzot autovakuumam ir iespēja iztÄ«rÄ«t un iezÄ«mēt Ŕīs beigu lÄ«nijas. Un viņŔ sāka darÄ«t savu darbu. Un cik ātri viņŔ to izdara, tik ātri mēs sakārtosimies.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Saskaņā ar pārbaudÄ«to planÅ”etdatoru, kurā mēs atjaunojam kontu atlikumus, mēs redzam tieÅ”i tādu paÅ”u attēlu. ArÄ« vidējais konta atjaunināŔanas laiks pakāpeniski normalizējas. Tiek samazināti arÄ« procesora patērētie resursi. Un darÄ«jumu skaits sekundē atgriežas normālā stāvoklÄ«. Bet atkal esam atgriezuÅ”ies normālā stāvoklÄ«, nevis tādi paÅ”i kā pirms avārijas.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Jebkurā gadījumā mēs saņemam veiktspējas samazinājumu, tāpat kā pirmajā gadījumā, pusotru līdz divas reizes un dažreiz vairāk.

Å Ä·iet, ka visu esam izdarÄ«juÅ”i pareizi. Sadaliet slodzi. Iekārta nav dÄ«kstāvē. LÅ«gumus sadalÄ«jām pēc prāta, bet tik un tā viss sanāca slikti.

  • Vai neiespējot hot_standby_feedback? Jā, nav ieteicams to ieslēgt bez Ä«paÅ”i nopietniem iemesliem. Jo Å”is pagrieziens tieÅ”i ietekmē Master serveri un aptur tur esoŔā autovakuuma darbÄ«bu. Iespējojot to kādā replikā un aizmirstot par to, jÅ«s varat nogalināt Master un iegÅ«t lielas problēmas ar lietojumprogrammu.
  • Vai palielināt max_standby_streaming_delay? Jā, pārskatiem tā ir taisnÄ«ba. Ja jums ir trÄ«s stundu pārskats un nevēlaties, lai tas avarētu replikācijas konfliktu dēļ, vienkārÅ”i palieliniet aizkavi. Ilgtermiņa ziņojumam nekad nav nepiecieÅ”ami dati, kas ir nonākuÅ”i datu bāzē tieÅ”i tagad. Ja jums tas ir trÄ«s stundas, tad jÅ«s to izmantojat kādu vecu datu periodu. Un jums nebÅ«s nekādas nozÄ«mes tam, vai ir trÄ«s stundu kavÄ“Å”anās vai seÅ”u stundu kavÄ“Å”anās, bet jÅ«s saņemsiet ziņojumus konsekventi un nebÅ«s problēmu ar to kriÅ”anu.
  • Protams, jums ir jākontrolē ilgas sesijas ar replikām, it Ä«paÅ”i, ja nolemjat replikā iespējot hot_standby_feedback. Jo viss var notikt. Mēs nodevām Å”o kopiju izstrādātājam, lai viņŔ varētu pārbaudÄ«t pieprasÄ«jumus. ViņŔ uzrakstÄ«ja traku pieprasÄ«jumu. ViņŔ to palaida un devās dzert tēju, un mēs saņēmām iedibināto Skolotāju. Vai varbÅ«t mēs tur ievietojām nepareizu pieteikumu. Situācijas ir dažādas. Sesijas ar replikām ir jāuzrauga tikpat rÅ«pÄ«gi kā uz Master.
  • Un, ja jums ir ātri un gari vaicājumi par replikām, tad Å”ajā gadÄ«jumā labāk tos sadalÄ«t, lai sadalÄ«tu slodzi. Å Ä« ir saite uz streaming_delay. Ātrām versijām ir jābÅ«t vienai kopijai ar nelielu replikācijas aizkavi. IlgstoÅ”iem pārskatu pieprasÄ«jumiem izmantojiet kopiju, kas var aizkavēties par 6 stundām vai dienu. Tā ir pilnÄ«gi normāla situācija.

Mēs novērÅ”am sekas tādā paŔā veidā:

  • Atrodam uzpÅ«stus galdus.
  • Un mēs to saspiežam ar ērtāko rÄ«ku, kas mums ir piemērots.

Otrais stāsts beidzas Ŕeit. Pāriesim pie treŔā stāsta.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Arī mums ir diezgan izplatīts, kurā mēs veicam migrāciju.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

  • JebkurÅ” programmatÅ«ras produkts aug. PrasÄ«bas tai mainās. Jebkurā gadÄ«jumā mēs vēlamies attÄ«stÄ«ties. Un gadās, ka mums ir jāatjaunina dati tabulā, proti, lai palaistu atjauninājumu attiecÄ«bā uz mÅ«su migrāciju jaunajai funkcionalitātei, ko mēs ievieÅ”am kā daļu no mÅ«su izstrādes.
  • Vecais datu formāts nav apmierinoÅ”s. Teiksim, tagad pārejam pie otrās tabulas, kur man ir darÄ«jumi Å”ajos kontos. Un pieņemsim, ka tie bija rubļos, un mēs nolēmām palielināt precizitāti un darÄ«t to kapeikās. Un Å”im nolÅ«kam mums ir jāveic atjauninājums: reiziniet lauku ar darÄ«juma summu ar simtu.
  • MÅ«sdienu pasaulē mēs izmantojam automatizētus datu bāzes versiju kontroles rÄ«kus. Teiksim Liquibase. Mēs tur reÄ£istrējam savu migrāciju. Mēs to pārbaudām savā testu bāzē. Viss ir kārtÄ«bā. AtjaunināŔana tiek veikta. Tas kādu laiku bloķē darbu, bet mēs saņemam atjauninātus datus. Un mēs varam ieviest jaunu funkcionalitāti Å”ajā jomā. Viss tika pārbaudÄ«ts un pārbaudÄ«ts. Viss tika apstiprināts.
  • Veicām plānveida darbus un veicām migrāciju.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Å eit ir parādÄ«ta migrācija ar jÅ«su priekŔā parādÄ«to atjauninājumu. Tā kā tie ir mana konta darÄ«jumi, tad plate bija 15 GB. Un tā kā mēs atjauninām katru rindiņu, mēs dubultojām tabulas izmēru ar atjauninājumu, jo mēs pārrakstÄ«jām katru rindiņu.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Migrācijas laikā mēs nevarējām neko darÄ«t ar Å”o plati, jo visi pieprasÄ«jumi tai tika salikti rindā un gaidÄ«ja, lÄ«dz Å”is atjauninājums tiks pabeigts. Bet Å”eit es gribu pievērst jÅ«su uzmanÄ«bu skaitļiem, kas atrodas uz vertikālās ass. Tas ir, mÅ«su vidējais pieprasÄ«juma laiks pirms migrācijas ir aptuveni 5 milisekundes un procesora slodze, diska atmiņas lasÄ«Å”anas bloku operāciju skaits ir mazāks par 7,5.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Mēs veicām migrāciju un atkal radās problēmas.

Migrācija bija veiksmīga, taču:

  • Tagad vecās funkcionalitātes pabeigÅ”ana prasa ilgāku laiku.
  • Galds atkal pieauga.
  • Servera slodze atkal kļuva lielāka nekā iepriekÅ”.
  • Un, protams, mēs joprojām čakarējam to funkcionalitāti, kas darbojās labi, esam to nedaudz uzlabojuÅ”i.

Un tas atkal ir uzpūŔanās, kas atkal sabojā mūsu dzīvi.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Å eit es parādu, ka tabula, tāpat kā iepriekŔējie divi gadÄ«jumi, neatgriezÄ«sies pie iepriekŔējiem izmēriem. Å Ä·iet, ka vidējā servera slodze ir atbilstoÅ”a.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un, ja mēs pievērsÄ«simies tabulai ar kontiem, mēs redzēsim, ka vidējais pieprasÄ«juma laiks Å”ai tabulai ir dubultojies. Procesora slodze un atmiņā sakārtoto rindu skaits uzlēca virs 7,5, taču bija mazāks. Un tas uzlēca 2 reizes procesoru gadÄ«jumā, 1,5 reizes bloku operāciju gadÄ«jumā, t.i., mēs saņēmām servera veiktspējas pasliktināŔanos. Un rezultātā - mÅ«su lietojumprogrammas veiktspējas pasliktināŔanās. Tajā paŔā laikā zvanu skaits saglabājās aptuveni tādā paŔā lÄ«menÄ«.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Un galvenais Å”eit ir saprast, kā pareizi veikt Ŕādas migrācijas. Un tie ir jādara. Mēs veicam Ŕīs migrācijas diezgan konsekventi.

  • Tik lielas migrācijas nenotiek automātiski. Viņiem vienmēr jābÅ«t kontrolētiem.
  • NepiecieÅ”ama zinoÅ”a cilvēka uzraudzÄ«ba. Ja jÅ«su komandā ir DBA, ļaujiet to darÄ«t DBA. Tas ir viņa darbs. Ja nē, tad lai to dara pieredzējuŔākais cilvēks, kurÅ” prot strādāt ar datu bāzēm.
  • Jauna datu bāzes shēma, pat ja mēs atjauninām vienu kolonnu, mēs vienmēr sagatavojam pakāpeniski, t.i., iepriekÅ”, pirms tiek izlaista jaunā lietojumprogrammas versija:
  • Tiek pievienoti jauni lauki, kuros ierakstÄ«sim atjauninātos datus.
  • Mēs pārsÅ«tām datus no vecā lauka uz jauno lauku mazās daļās. Kāpēc mēs to darām? Pirmkārt, mēs vienmēr kontrolējam Ŕī procesa procesu. Mēs zinām, ka esam jau nodevuÅ”i tik daudz partiju un mums ir palikuÅ”as tik daudz.
  • Un otrs pozitÄ«vais efekts ir tas, ka starp katru Ŕādu partiju mēs noslēdzam darÄ«jumu, atveram jaunu, un tas ļauj autovakuumam strādāt atbilstoÅ”i plāksnÄ«tei, iezÄ«mēt termiņus atkārtotai izmantoÅ”anai.
  • Rindām, kas parādÄ«sies lietojumprogrammas darbÄ«bas laikā (mums joprojām darbojas vecā lietojumprogramma), mēs pievienojam trigeri, kas raksta jaunas vērtÄ«bas jaunos laukos. MÅ«su gadÄ«jumā tas ir reizinājums ar simtu no vecās vērtÄ«bas.
  • Ja esam pilnÄ«gi spÄ«tÄ«gi un vēlamies vienu un to paÅ”u lauku, tad pēc visu migrÄ“Å”anas pabeigÅ”anas un pirms jaunas lietojumprogrammas versijas izlaiÅ”anas mēs vienkārÅ”i pārdēvējam laukus. Vecajiem tiek dots kaut kāds izdomāts nosaukums, un jaunie lauki tiek pārdēvēti par vecajiem.
  • Un tikai pēc tam mēs palaižam jaunu lietojumprogrammas versiju.

Un tajā paŔā laikā mēs nesaņemsim uzpÅ«Å”anos un necietÄ«sim snieguma ziņā.

Šeit beidzas treŔais stāsts.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

Un tagad nedaudz sÄ«kāk par rÄ«kiem, kurus minēju paŔā pirmajā stāstā.

Pirms uzpÅ«Å”anās meklÄ“Å”anas ir jāinstalē paplaÅ”inājums pgstattuple.

Lai jums nebÅ«tu jānāk klajā ar jautājumiem, mēs jau esam ierakstÄ«juÅ”i Å”os vaicājumus savā darbā. JÅ«s varat tos izmantot. Å eit ir divi pieprasÄ«jumi.

  • Pirmā darbÄ«ba aizņem diezgan ilgu laiku, taču tā parādÄ«s precÄ«zas uzpÅ«Å”anās vērtÄ«bas no tabulas.
  • Otrais iedarbojas ātrāk un ir ļoti iedarbÄ«gs, ja pēc tabulas ātri jānovērtē, vai ir vai nav vēdera uzpÅ«Å”anās. Un jums vajadzētu arÄ« saprast, ka uzpÅ«Å”anās vienmēr ir klāt Postgres tabulā. Å Ä« ir tā MVCC modeļa iezÄ«me.
  • Un 20% vēdera uzpÅ«Å”anās vairumā gadÄ«jumu ir normāli galdiem. Tas ir, jums nevajadzētu uztraukties un saspiest Å”o tabulu.

Mēs izdomājām, kā identificēt tabulas, kas ir pietÅ«kuÅ”as, un kad tās ir pietÅ«kuÅ”as ar nederÄ«giem datiem.

Tagad par to, kā novērst vēdera uzpÅ«Å”anos:

  • Ja mums ir maza planÅ”ete un labi diski, tas ir, planÅ”etdatorā lÄ«dz gigabaitam, ir pilnÄ«gi iespējams izmantot VACUUM FULL. ViņŔ uz dažām sekundēm paņems no jums ekskluzÄ«vu slēdzeni uz galda un labi, bet viņŔ visu izdarÄ«s ātri un skarbi. Ko dara VACUUM FULL? Tas aizņem ekskluzÄ«vu slēdzeni uz galda un pārraksta reāllaika rindas no vecajām tabulām jaunajā tabulā. Un beigās viņŔ tos aizstāj. Tas izdzÄ“Å” vecos failus un aizstāj vecos ar jauniem. Bet uz tā darbÄ«bas laiku tas aizņem ekskluzÄ«vu slēdzeni uz galda. Tas nozÄ«mē, ka jÅ«s nevarat neko darÄ«t ar Å”o tabulu: ne rakstÄ«t tajā, ne lasÄ«t, ne pārveidot. Un VACUUM FULL ir nepiecieÅ”ama papildu vieta diskā, lai ierakstÄ«tu datus.
  • Nākamais rÄ«ks pg_repack. Savā principā tas ir ļoti lÄ«dzÄ«gs VACUUM FULL, jo arÄ« pārraksta datus no vecajiem failiem uz jauniem un aizstāj tos tabulā. Bet tajā paŔā laikā tas neuzņem ekskluzÄ«vu slēdzeni uz galda paŔā darba sākumā, bet gan tikai tajā brÄ«dÄ«, kad tam jau ir gatavi dati, lai aizstātu failus. Tās diska resursu prasÄ«bas ir lÄ«dzÄ«gas VACUUM FULL prasÄ«bām. Jums ir nepiecieÅ”ama papildu vieta diskā, un dažreiz tas ir ļoti svarÄ«gi, ja jums ir terabaitu tabulas. Un tas ir diezgan izsalcis procesoru, jo tas aktÄ«vi darbojas ar I/O.
  • TreŔā lietderÄ«ba ir pgcompacttable. Tas ir uzmanÄ«gāks ar resursiem, jo ā€‹ā€‹darbojas pēc nedaudz atŔķirÄ«giem principiem. Pgcompacttable galvenā ideja ir tāda, ka tas pārvieto visas reāllaika rindas uz tabulas sākumu, izmantojot tabulas atjauninājumus. Un tad tas uz Å”o tabulu iedarbina vakuumu, jo mēs zinām, ka mums ir dzÄ«vās rindas sākumā un miruŔās rindas beigās. Un vakuums pats nogriež Å”o asti, t.i., tas neprasa daudz papildu vietas diskā. Un tajā paŔā laikā to joprojām var saspiest resursu ziņā.

Viss ar instrumentiem.

Tipiskas lietojumprogrammu kļūdas, kas izraisa postgresql uzpÅ«Å”anos. Andrejs Saļņikovs

Ja jums Ŕķiet, ka uzpÅ«Å”anās tēma ir interesanta plaŔākai iedziļināŔanās ziņā, Å”eit ir dažas noderÄ«gas saites:

Vairāk centos parādÄ«t Å”ausmu stāstu izstrādātājiem, jo ā€‹ā€‹viņi ir mÅ«su tieÅ”ie datu bāzu klienti un jāsaprot, pie kā un kādas darbÄ«bas noved. Ceru, ka man izdevās. Paldies par jÅ«su uzmanÄ«bu!

jautājumi

Paldies par ziņojumu! JÅ«s runājāt par to, kā identificēt problēmas. Kā viņus var brÄ«dināt? Tas ir, man bija situācija, kad pieprasÄ«jumi karājās ne tikai tāpēc, ka tie piekļuva dažiem ārējiem pakalpojumiem. Tie bija tikai daži savvaļas pievienoÅ”anās. Bija daži niecÄ«gi, nekaitÄ«gi lÅ«gumi, kas pastāvēja vienu dienu un pēc tam sāka darÄ«t kādas muļķības. Tas ir, ļoti lÄ«dzÄ«gs jÅ«su aprakstÄ«tajam. Kā tam izsekot? Sēdēt un pastāvÄ«gi skatÄ«ties, kurÅ” pieprasÄ«jums ir iestrēdzis? Kā to var novērst?

Šajā gadījumā tas ir jūsu uzņēmuma administratoru uzdevums, nevis obligāti DBA.

Esmu administrators.

PostgreSQL ir skats, ko sauc par pg_stat_activity, kas parāda mainīgos vaicājumus. Un jūs varat redzēt, cik ilgi tas tur karājas.

Vai man ir jāienāk un jāskatās ik pēc 5 minūtēm?

Iestatiet cron un pārbaudiet. Ja jums ir ilgtermiņa pieprasījums, uzrakstiet vēstuli un viss. Tas ir, jums nav jāskatās ar acīm, to var automatizēt. Tu saņemsi vēstuli, tu uz to reaģēsi. Vai arī varat fotografēt automātiski.

Vai ir kādi acīmredzami iemesli, kāpēc tas notiek?

Esmu uzskaitījis dažus. Citi sarežģītāki piemēri. Un saruna var būt ilgi.

Paldies par ziņojumu! Es gribēju precizēt par pg_repack utilītu. Ja viņa netaisa ekskluzīvu slēdzeni, tad...

Viņa veic ekskluzīvu slēdzeni.

... tad es varētu zaudēt datus. Vai manā lietojumprogrammā Å”ajā laikā nevajadzētu ierakstÄ«t neko?

Nē, tas darbojas nevainojami ar tabulu, t.i., pg_repack vispirms pārsÅ«ta visas esoŔās dzÄ«vās rindas. Dabiski, ka tur notiek sava veida iekļūŔana tabulā. ViņŔ vienkārÅ”i met ārā Å”o zirgaste.

Tas ir, viņŔ tieŔām to dara galu galā?

Galu galā viņŔ izmanto ekskluzÄ«vu slēdzeni, lai apmainÄ«tu Å”os failus.

Vai tas būs ātrāk nekā VACUUM FULL?

VACUUM FULL, tiklÄ«dz sākās, uzreiz paņēma ekskluzÄ«vu slēdzeni. Un, kamēr viņŔ visu neizdarÄ«s, viņŔ viņu nelaidÄ«s vaļā. Un pg_repack izmanto ekskluzÄ«vu bloÄ·Ä“Å”anu tikai faila aizstāŔanas laikā. Å obrÄ«d jÅ«s tur nerakstÄ«sit, bet dati nepazudÄ«s, viss bÅ«s kārtÄ«bā.

Sveiki! JÅ«s runājāt par automaŔīnas putekļsÅ«cēja darbÄ«bu. Bija grafiks ar sarkanām, dzeltenām un zaļām ieraksta Ŕūnām. Tas ir, dzeltenās ā€“ viņŔ atzÄ«mēja tās kā dzēstas. Un rezultātā tajos var ierakstÄ«t kaut ko jaunu?

Jā. Postgres nedzÄ“Å” rindas. Viņam ir tāda specifika. Ja mēs atjauninājām rindiņu, mēs atzÄ«mējām veco kā dzēstu. Tur parādās darÄ«juma ID, kas mainÄ«ja Å”o rindu, un mēs rakstām jaunu rindu. Un mums ir sesijas, kurās tās varētu lasÄ«t. Kādā brÄ«dÄ« viņi kļūst diezgan veci. Un autovakuuma darbÄ«bas bÅ«tÄ«ba ir tāda, ka tas iet caur Ŕīm lÄ«nijām un atzÄ«mē tās kā nevajadzÄ«gas. Un tur var pārrakstÄ«t datus.

Es saprotu. Bet jautājums nav par to. Es nepabeidzu. Pieņemsim, ka mums ir galds. Tam ir mainÄ«ga izmēra lauki. Un, ja es mēģinu ievietot kaut ko jaunu, tas var vienkārÅ”i neiederēties vecajā Ŕūnā.

Nē, jebkurā gadÄ«jumā tur tiek atjaunināta visa rinda. Postgres ir divi datu uzglabāŔanas modeļi. Tas izvēlas no datu veida. Ir dati, kas tiek glabāti tieÅ”i tabulā, un ir arÄ« tos dati. Tie ir lieli datu apjomi: teksts, json. Tos uzglabā atseviŔķās plāksnēs. Un pēc Ŕīm tabletēm notiek tas pats stāsts ar vēdera uzpÅ«Å”anos, t.i., viss ir pa vecam. Tie ir tikai uzskaitÄ«ti atseviŔķi.

Paldies par ziņojumu! Vai ir pieņemami izmantot izraksta noildzes vaicājumus, lai ierobežotu ilgumu?

Ä»oti pieņemami. Mēs to izmantojam visur. Un tā kā mums nav savu pakalpojumu, mēs sniedzam attālinātu atbalstu, mums ir diezgan dažādi klienti. Un visi ar to ir pilnÄ«bā apmierināti. Tas ir, mums ir cron darbi, kas pārbauda. Seansu ilgums vienkārÅ”i tiek saskaņots ar klientu, pirms kura mēs nevienojamies. Tā varētu bÅ«t minÅ«te, tā varētu bÅ«t 10 minÅ«tes. Tas ir atkarÄ«gs no pamatnes slodzes un tā mērÄ·a. Bet mēs visi izmantojam pg_stat_activity.

Paldies par ziņojumu! Es mēģinu piemērot jÅ«su ziņojumu saviem pieteikumiem. Un Ŕķiet, ka mēs sākam darÄ«jumu visur un skaidri to pabeidzam visur. Ja ir kāds izņēmums, tad atcelÅ”ana joprojām notiek. Un tad es sāku domāt. Galu galā darÄ«jums var nesākties tieÅ”i. Tas, iespējams, ir mājiens meitenei. Ja es tikai atjaunināŔu ierakstu, vai transakcija sāksies programmā PostgreSQL un tiks pabeigta tikai tad, kad savienojums tiks atvienots?

Ja jÅ«s tagad runājat par lietojumprogrammas lÄ«meni, tas ir atkarÄ«gs no izmantotā draivera, no izmantotā ORM. Tur ir daudz iestatÄ«jumu. Ja esat iespējojis automātisko apņemÅ”anos, darÄ«jums sākas tur un nekavējoties tiek aizvērts.

Tas ir, tas tiek aizvērts tÅ«lÄ«t pēc atjaunināŔanas?

Tas ir atkarÄ«gs no iestatÄ«jumiem. Es nosaucu vienu iestatÄ«jumu. Å Ä« ir automātiska apņemÅ”anās. Tas ir diezgan bieži. Ja tas ir iespējots, darÄ«jums ir atvērts un aizvērts. Ja vien jÅ«s nepārprotami teicāt ā€œsākt darÄ«jumuā€ un ā€œbeigt darÄ«jumuā€, bet vienkārÅ”i palaidāt pieprasÄ«jumu sesijā.

Sveiki! Paldies par ziņojumu! Iedomāsimies, ka mums ir datubāze, kas uzbriest un uzbriest, un tad vieta serverÄ« beidzas. Vai ir kādi rÄ«ki Ŕīs situācijas laboÅ”anai?

Vieta serverī ir pareizi jāuzrauga.

Piemēram, DBA devās dzert tēju, bija kūrortā utt.

Kad tiek izveidota failu sistēma, tiek izveidota vismaz sava veida rezerves vieta, kur dati netiek rakstīti.

Ko darīt, ja tas ir pilnīgi zem nulles?

Tur to sauc par rezervēto vietu, t.i., to var atbrÄ«vot un atkarÄ«bā no tā, cik liela tā tika izveidota, tiek iegÅ«ta brÄ«va vieta. Pēc noklusējuma es nezinu, cik to ir. Un citā gadÄ«jumā piegādājiet diskus, lai jums bÅ«tu vieta rekonstruktÄ«vas operācijas veikÅ”anai. Varat izdzēst kādu tabulu, kas jums garantēti nebÅ«s vajadzÄ«ga.

Vai ir kādi citi rīki?

Tas vienmēr ir roku darbs. Un lokāli kļūst skaidrs, ko tur vislabāk darīt, jo daži dati ir kritiski un daži nav kritiski. Un katrai datubāzei un lietojumprogrammai, kas ar to darbojas, tas ir atkarīgs no uzņēmuma. Tas vienmēr tiek izlemts uz vietas.

Paldies par ziņojumu! Man ir divi jautājumi. Pirmkārt, jÅ«s parādÄ«jāt slaidus, kuros tika parādÄ«ts, ka tad, kad darÄ«jumi ir iestrēguÅ”i, palielinās gan tabulas laukuma, gan indeksa lielums. Un tālāk ziņojumā bija virkne utilÄ«tu, kas iepako planÅ”etdatoru. Kā ar indeksu?

Viņi arī tos iesaiņo.

Bet vakuums neietekmē indeksu?

Daži strādā ar indeksu. Piemēram, pg_rapack, pgcompacttable. Vakuums atjauno indeksus un ietekmē tos. Ar VACUUM FULL ideja ir pārrakstīt visu, t.i., tas darbojas ar visiem.

Un otrais jautājums. Es nesaprotu, kāpēc pārskati par replikām ir tik ļoti atkarÄ«gi no paÅ”as replikācijas. Man Ŕķita, ka atskaites tiek lasÄ«tas, bet replikācija ir rakstÄ«ta.

Kas izraisa replikācijas konfliktu? Mums ir Meistars, kurā notiek procesi. Mums notiek auto putekļu sÅ«cējs. Ko Ä«sti dara autovakuums? ViņŔ izgriež dažas vecas lÄ«nijas. Ja Å”obrÄ«d mums ir pieprasÄ«jums pēc kopijas, kas nolasa Ŕīs vecās rindas, un Master radās situācija, ka autovakuums atzÄ«mēja Ŕīs rindas kā pārrakstÄ«Å”anas iespējas, tad mēs tās pārrakstÄ«jām. Un mēs saņēmām datu paketi, kad mums replikā jāpārraksta pieprasÄ«jumam nepiecieÅ”amās rindas, replikācijas process gaidÄ«s jÅ«su konfigurēto taimautu. Un tad PostgreSQL izlems, kas tam ir svarÄ«gāks. Un replikācija viņam ir svarÄ«gāka par pieprasÄ«jumu, un viņŔ izpildÄ«s pieprasÄ«jumu, lai veiktu Ŕīs izmaiņas replikā.

Andrej, man ir jautājums. Šie brīniŔķīgie grafiki, kurus parādījāt prezentācijas laikā, vai tie ir kāda jūsu lietderības darba rezultāts? Kā tika izveidoti grafiki?

Å is ir pakalpojums Okmeter.

Vai tas ir komerciāls produkts?

Jā. Šis ir komerciāls produkts.

Avots: www.habr.com

Pievieno komentāru