Hitilafu za kawaida katika programu ambazo husababisha uvimbe katika postgresql. Andrey Salnikov

Ninapendekeza usome nakala ya ripoti kutoka mwanzoni mwa 2016 na Andrey Salnikov "Makosa ya kawaida katika programu ambayo husababisha bloat kwenye postgresql"

Katika ripoti hii, nitachambua makosa kuu katika programu zinazotokea katika hatua ya kubuni na kuandika msimbo wa maombi. Na nitachukua makosa yale tu ambayo husababisha bloat katika Postgresql. Kama sheria, huu ni mwanzo wa mwisho wa utendakazi wa mfumo wako kwa ujumla, ingawa hapo awali hakuna sharti la hii lililoonekana.

Ninafurahi kuwakaribisha kila mtu! Ripoti hii sio ya kiufundi kama ile ya awali kutoka kwa mwenzangu. Ripoti hii inalenga zaidi wasanidi wa mfumo wa nyuma kwa sababu tuna idadi kubwa ya wateja. Na wote hufanya makosa sawa. Nitakuambia juu yao. Nitaelezea ni mambo gani mabaya na mabaya ambayo makosa haya husababisha.

Kwa nini makosa hufanywa? Zinafanywa kwa sababu mbili: kwa nasibu, labda itafanya kazi na kwa sababu ya ujinga wa mifumo fulani ambayo hufanyika katika kiwango kati ya hifadhidata na programu, na pia kwenye hifadhidata yenyewe.

Nitakupa mifano mitatu yenye picha za kutisha za jinsi mambo yalivyokuwa mabaya. Nitakuambia kwa ufupi juu ya utaratibu unaotokea hapo. Na jinsi ya kukabiliana nao, wakati walipotokea, na ni njia gani za kuzuia za kutumia ili kuzuia makosa. Nitakuambia kuhusu zana za msaidizi na kutoa viungo muhimu.

Nilitumia hifadhidata ya majaribio ambapo nilikuwa na meza mbili. Sahani moja yenye akaunti za wateja, nyingine ikiwa na miamala kwenye akaunti hizi. Na mara kwa mara tunasasisha salio kwenye akaunti hizi.

Data ya awali ya sahani: ni ndogo kabisa, 2 MB. Wakati wa kujibu kwa hifadhidata na haswa kwa ishara pia ni nzuri sana. Na mzigo mzuri - shughuli 2 kwa sekunde kulingana na sahani.

Na kupitia ripoti hii nitakuonyesha grafu ili uweze kuelewa vizuri kile kinachotokea. Siku zote kutakuwa na slaidi 2 zenye grafu. Slaidi ya kwanza ni kile kinachotokea kwa ujumla kwenye seva.

Na katika hali hii, tunaona kwamba kweli tuna ishara ndogo. Fahirisi ni ndogo kwa 2 MB. Hii ni grafu ya kwanza upande wa kushoto.

Muda wa wastani wa kujibu kwenye seva pia ni thabiti na mfupi. Hii ni grafu ya juu kulia.

Grafu ya chini kushoto inaonyesha shughuli ndefu zaidi. Tunaona kwamba shughuli zinakamilika haraka. Na otomatiki haifanyi kazi hapa bado, kwa sababu ilikuwa jaribio la kuanza. Itaendelea kufanya kazi na itakuwa na manufaa kwetu.

Slaidi ya pili itawekwa wakfu kwa sahani inayojaribiwa. Katika hali hii, tunasasisha mara kwa mara salio la akaunti ya mteja. Na tunaona kwamba muda wa wastani wa kujibu kwa operesheni ya sasisho ni nzuri kabisa, chini ya millisecond. Tunaona kwamba rasilimali za processor (hii ni grafu ya juu ya kulia) pia hutumiwa sawasawa na ndogo kabisa.

Grafu ya chini kulia inaonyesha ni kiasi gani cha kumbukumbu ya uendeshaji na diski tunayopitia katika kutafuta laini tunayotaka kabla ya kuisasisha. Na idadi ya shughuli kulingana na ishara ni 2 kwa sekunde, kama nilivyosema mwanzoni.

Na sasa tuna msiba. Kwa sababu fulani kuna shughuli iliyosahaulika kwa muda mrefu. Sababu kawaida ni banal:

• Moja ya kawaida ni kwamba tulianza kupata huduma ya nje katika msimbo wa maombi. Na huduma hii haitujibu. Hiyo ni, tulifungua shughuli, tulifanya mabadiliko katika hifadhidata na tukatoka kwa programu kusoma barua au kwenda kwa huduma nyingine ndani ya miundombinu yetu, na kwa sababu fulani haijibu kwetu. Na kikao chetu kimekwama katika hali ambayo haijulikani kitasuluhishwa lini.
• Hali ya pili ni wakati ubaguzi ulitokea katika nambari yetu kwa sababu fulani. Na isipokuwa hatukushughulikia kufungwa kwa shughuli hiyo. Na tuliishia na kikao cha kunyongwa na shughuli iliyo wazi.
• Na ya mwisho pia ni kesi ya kawaida. Huu ni msimbo wa ubora wa chini. Baadhi ya mifumo hufungua shughuli. Inaning'inia, na unaweza usijue katika programu kwamba unayo.

Mambo kama haya yanaongoza wapi?

Kwa uhakika kwamba meza zetu na indexes huanza kuvimba kwa kasi. Hii ni athari sawa ya bloat. Kwa hifadhidata, hii itamaanisha kuwa wakati wa majibu ya hifadhidata utaongezeka kwa kasi sana na mzigo kwenye seva ya hifadhidata utaongezeka. Na matokeo yake, maombi yetu yatateseka. Kwa sababu ikiwa ulitumia milisekunde 10 katika msimbo wako kwa ombi kwa hifadhidata, milisekunde 10 kwenye mantiki yako, basi chaguo lako la kukokotoa lilichukua milisekunde 20 kukamilika. Na sasa hali yako itakuwa ya kusikitisha sana.

Na tuone kitakachotokea. Grafu ya chini kushoto inaonyesha kwamba tuna muamala mrefu mrefu. Na ikiwa tunatazama grafu ya juu kushoto, tunaona kwamba ukubwa wa meza yetu umeruka ghafla kutoka megabytes mbili hadi 300 megabytes. Wakati huo huo, kiasi cha data kwenye jedwali hakijabadilika, i.e. kuna kiasi kikubwa cha taka huko.

Hali ya jumla kuhusu muda wa wastani wa majibu ya seva pia imebadilika kwa maagizo kadhaa ya ukubwa. Hiyo ni, maombi yote kwenye seva yalianza kushuka kabisa. Na wakati huo huo, michakato ya ndani ya Postgres ilizinduliwa kwa njia ya autovacuum, ambayo inajaribu kufanya kitu na kutumia rasilimali.

Nini kinaendelea na ishara yetu? Sawa. Wakati wetu wa kujibu wastani kulingana na ishara umeruka juu ya maagizo kadhaa ya ukubwa. Hasa katika suala la rasilimali zinazotumiwa, tunaona kwamba mzigo kwenye processor umeongezeka sana. Hii ni grafu ya juu kulia. Na imeongezeka kwa sababu processor inapaswa kutatua rundo la mistari isiyo na maana katika kutafuta inayohitajika. Hii ni grafu ya chini kulia. Na kwa sababu hiyo, idadi yetu ya simu kwa sekunde ilianza kushuka sana, kwa sababu hifadhidata haikuwa na wakati wa kushughulikia idadi sawa ya maombi.

Tunahitaji kurudi kwenye uzima. Tunaenda mtandaoni na kujua kwamba shughuli za muda mrefu husababisha matatizo. Tunapata na kuua shughuli hii. Na kila kitu kinakuwa kawaida kwetu. Kila kitu hufanya kazi kama inavyopaswa.

Tulitulia, lakini baada ya muda tunaanza kugundua kuwa maombi hayafanyi kazi sawa na kabla ya dharura. Maombi bado yanachakatwa polepole, na polepole zaidi. Mara moja na nusu hadi mbili polepole haswa katika mfano wangu. Mzigo kwenye seva pia ni wa juu kuliko ilivyokuwa kabla ya ajali.

Na swali: "Ni nini kinatokea kwa msingi wakati huu?" Na hali ifuatayo hutokea kwa msingi. Kwenye chati ya muamala unaweza kuona kwamba imesimama na kwa kweli hakuna shughuli za muda mrefu. Lakini saizi ya ishara iliongezeka vibaya wakati wa ajali. Na tangu wakati huo hawajapungua. Wakati wa wastani kwenye msingi umetulia. Na majibu yanaonekana kuja vya kutosha kwa kasi inayokubalika kwetu. Autovacuum ikawa hai zaidi na ikaanza kufanya kitu na ishara, kwa sababu inahitaji kuchuja data zaidi.

Hasa, kwa mujibu wa sahani ya mtihani na akaunti, ambapo tunabadilisha mizani: wakati wa kukabiliana na ombi inaonekana kurudi kwa kawaida. Lakini kwa kweli ni mara moja na nusu ya juu.

Na kutoka kwa mzigo kwenye processor, tunaona kwamba mzigo kwenye processor haujarudi kwa thamani inayotakiwa kabla ya ajali. Na sababu ziko kwenye grafu ya chini kulia. Inaweza kuonekana kuwa kiasi fulani cha kumbukumbu kinatafutwa huko. Hiyo ni, kupata mstari unaohitajika, tunapoteza rasilimali za seva ya hifadhidata wakati wa kuchagua data isiyo na maana. Idadi ya miamala kwa sekunde imetulia.

Kwa ujumla ni nzuri, lakini hali ni mbaya zaidi kuliko ilivyokuwa. Futa uharibifu wa hifadhidata kama matokeo ya programu yetu inayofanya kazi na hifadhidata hii.

Na kuelewa kinachoendelea huko, ikiwa hukuwa kwenye ripoti ya awali, sasa hebu tupate nadharia kidogo. Nadharia juu ya mchakato wa ndani. Kwa nini utupu wa gari na hufanya nini?

Kwa ufupi kwa ufahamu. Kwa wakati fulani tuna meza. Tuna safu kwenye meza. Mistari hii inaweza kuwa hai, hai, na kile tunachohitaji sasa. Wamewekwa alama ya kijani kwenye picha. Na kuna mistari iliyokufa ambayo tayari imefanywa kazi, imesasishwa, na maingizo mapya yameonekana juu yao. Na zimewekwa alama kuwa hazivutii tena kwenye hifadhidata. Lakini wako kwenye jedwali kwa sababu ya kipengele cha Postgres.

Kwa nini unahitaji utupu wa gari? Wakati fulani, otomatiki huja, kufikia hifadhidata na kuiuliza: "Tafadhali nipe kitambulisho cha shughuli ya zamani zaidi ambayo imefunguliwa kwa sasa kwenye hifadhidata." Hifadhidata inarudisha kitambulisho hiki. Na otomatiki, ikitegemea, hupanga kupitia mistari kwenye jedwali. Na ikiwa ataona kuwa baadhi ya laini zilibadilishwa na shughuli za zamani zaidi, basi ana haki ya kuziweka alama kama laini ambazo tunaweza kutumia tena katika siku zijazo kwa kuandika data mpya hapo. Huu ni mchakato wa usuli.

Kwa wakati huu, tunaendelea kufanya kazi na hifadhidata na tunaendelea kufanya mabadiliko kadhaa kwenye jedwali. Na kwenye mistari hii, ambayo tunaweza kutumia tena, tunaandika data mpya. Na kwa hivyo tunapata mzunguko, i.e. wakati wote mistari ya zamani iliyokufa huonekana hapo, badala yake tunaandika mistari mpya ambayo tunahitaji. Na hii ni hali ya kawaida kwa PostgreSQL kufanya kazi.

Nini kilitokea wakati wa ajali? Mchakato huu ulifanyikaje huko?

Tulikuwa na ishara katika hali fulani, baadhi hai, baadhi ya mistari iliyokufa. Ombwe la gari limefika. Aliuliza hifadhidata shughuli yetu ya zamani zaidi ni nini na kitambulisho chake ni nini. Nilipokea kitambulisho hiki, ambacho kinaweza kuwa saa nyingi zilizopita, labda dakika kumi zilizopita. Inategemea jinsi mzigo ulio nao kwenye hifadhidata yako. Na akaenda kutafuta mistari ambayo angeweza kutia alama kama imetumika tena. Na sikupata mistari kama hii kwenye meza yetu.

Lakini kwa wakati huu tunaendelea kufanya kazi na meza. Tunafanya kitu ndani yake, kusasisha, kubadilisha data. Je, hifadhidata inapaswa kufanya nini wakati huu? Hana chaguo ila kuongeza mistari mipya hadi mwisho wa jedwali lililopo. Na hivyo ukubwa wa meza yetu huanza kuvimba.

Kwa kweli, tunahitaji mistari ya kijani kufanya kazi. Lakini wakati wa shida kama hiyo, zinageuka kuwa asilimia ya mistari ya kijani kibichi iko chini sana katika meza nzima.

Na tunapotekeleza swali, hifadhidata inapaswa kupitia mistari yote: nyekundu na kijani, ili kupata mstari unaotaka. Na athari ya bloating ya meza na data isiyo na maana inaitwa "bloat", ambayo pia inakula nafasi yetu ya disk. Kumbuka, ilikuwa 2 MB, ikawa 300 MB? Sasa badilisha megabytes kuwa gigabytes na utapoteza haraka rasilimali zako zote za diski.

Ni matokeo gani yanaweza kuwa kwetu?

• Katika mfano wangu, jedwali na faharisi zilikua mara 150. Baadhi ya wateja wetu wamekuwa na matukio mabaya zaidi walipoanza tu kukosa nafasi ya diski.
• Ukubwa wa meza yenyewe hautapungua kamwe. Autovacuum katika baadhi ya matukio inaweza kukata mkia wa meza ikiwa kuna mistari iliyokufa tu. Lakini kwa kuwa kuna mzunguko wa mara kwa mara, mstari mmoja wa kijani unaweza kufungia mwishoni na usisasishwe, wakati wengine wote wataandikwa mahali fulani mwanzoni mwa sahani. Lakini hii ni tukio lisilowezekana kwamba meza yako yenyewe itapungua kwa ukubwa, kwa hivyo usipaswi kutumaini.
• Hifadhidata inahitaji kupanga kupitia rundo zima la mistari isiyo na maana. Na tunapoteza rasilimali za disk, tunapoteza rasilimali za processor na umeme.
• Na hii inathiri moja kwa moja maombi yetu, kwa sababu ikiwa mwanzoni tulitumia milliseconds 10 kwa ombi, milliseconds 10 kwenye msimbo wetu, basi wakati wa ajali tulianza kutumia pili kwa ombi na milliseconds 10 kwenye kanuni, yaani amri ya Utendaji wa programu ulipungua. Na ajali ilipotatuliwa, tulianza kutumia milliseconds 20 kwa ombi, milliseconds 10 kwenye msimbo. Hii ina maana kwamba bado tulishuka kwa mara moja na nusu katika tija. Na hii yote ni kwa sababu ya shughuli moja ambayo ilikwama, labda kwa makosa yetu.
• Na swali: "Tunawezaje kurejesha kila kitu?" ili kila kitu kiwe sawa na sisi na maombi yanakuja haraka kama kabla ya ajali.

Kwa kusudi hili kuna mzunguko fulani wa kazi unaofanywa.

Kwanza tunahitaji kupata meza zenye shida ambazo zimevimba. Tunaelewa kuwa katika baadhi ya majedwali rekodi ni amilifu zaidi, nyingine haitumiki sana. Na kwa hili tunatumia ugani pgstattuple. Kwa kusakinisha kiendelezi hiki, unaweza kuandika maswali ambayo yatakusaidia kupata meza ambazo zimevimba kabisa.

Mara tu umepata meza hizi, unahitaji kuzikandamiza. Tayari kuna zana za hii. Katika kampuni yetu tunatumia zana tatu. Ya kwanza ni VACUUM iliyojengwa ndani FULL. Yeye ni mkatili, mkali na asiye na huruma, lakini wakati mwingine ni muhimu sana. Uk_weka upya и pgcompacttable - Hizi ni huduma za mtu wa tatu za kubana meza. Na wanashughulikia hifadhidata kwa uangalifu zaidi.

Zinatumika kulingana na kile ambacho kinafaa zaidi kwako. Lakini nitakuambia juu ya hii mwishoni kabisa. Jambo kuu ni kwamba kuna zana tatu. Kuna mengi ya kuchagua.

Baada ya kusahihisha kila kitu na kuhakikisha kuwa kila kitu kiko sawa, lazima tujue jinsi ya kuzuia hali hii katika siku zijazo:

• Inaweza kuzuiwa kwa urahisi kabisa. Unahitaji kufuatilia muda wa vipindi kwenye seva kuu. Vipindi hatari haswa katika hali ya kutofanya kitu katika hali ya muamala. Hawa ndio ambao wamefungua shughuli, wakafanya kitu na kuondoka, au kunyongwa tu, walipotea kwenye nambari.
• Na kwako, kama wasanidi, ni muhimu kujaribu nambari yako wakati hali hizi zinatokea. Si vigumu kufanya. Hii itakuwa hundi yenye manufaa. Utaepuka idadi kubwa ya matatizo ya "kitoto" yanayohusiana na shughuli za muda mrefu.

Katika grafu hizi, nilitaka kukuonyesha jinsi ishara na tabia ya hifadhidata ilibadilika baada ya kupitia ishara na VACUUM FULL katika kesi hii. Huu sio uzalishaji kwangu.

Saizi ya meza mara moja ilirudi kwa hali yake ya kawaida ya kufanya kazi ya megabytes kadhaa. Hii haikuathiri pakubwa muda wa wastani wa majibu kwa seva.

Lakini mahususi kwa ishara yetu ya majaribio, ambapo tulisasisha salio la akaunti, tunaona kwamba muda wa wastani wa kujibu ombi la kusasisha data katika ishara ulipunguzwa hadi viwango vya kabla ya dharura. Rasilimali zinazotumiwa na kichakataji kukamilisha ombi hili pia zilishuka hadi viwango vya kabla ya kuacha kufanya kazi. Na grafu ya chini ya kulia inaonyesha kwamba sasa tunapata mstari ambao tunahitaji mara moja, bila kupitia mirundo ya mistari iliyokufa ambayo ilikuwa hapo kabla ya kukandamizwa kwa meza. Na muda wa wastani wa ombi ulibaki katika takriban kiwango sawa. Lakini hapa nina, badala yake, kosa katika vifaa vyangu.

Hapa ndipo hadithi ya kwanza inaishia. Ni ya kawaida zaidi. Na hutokea kwa kila mtu, bila kujali uzoefu wa mteja na jinsi waandaaji wa programu walivyo na sifa. Hivi karibuni au baadaye hii hutokea.

Hadithi ya pili, ambayo tunasambaza mzigo na kuboresha rasilimali za seva

• Tayari tumekua na tumekuwa watu makini. Na tunaelewa kwamba tuna replica na itakuwa nzuri kwa sisi kusawazisha mzigo: kuandika kwa Mwalimu, na kusoma kutoka replica. Na kwa kawaida hali hii hutokea tunapotaka kuandaa baadhi ya ripoti au ETL. Na biashara ni furaha sana kuhusu hili. Anataka sana ripoti mbalimbali zenye uchanganuzi tata.
• Ripoti huchukua saa nyingi, kwa sababu uchanganuzi changamano hauwezi kuhesabiwa katika milisekunde. Sisi, kama watu jasiri, tunaandika nambari. Katika programu ya kuingiza tunafanya rekodi kwenye Mwalimu, na kutekeleza ripoti kwenye replica.
• Kusambaza mzigo.
• Kila kitu hufanya kazi kikamilifu. Sisi ni kubwa.

Na hali hii inaonekanaje? Hasa kwenye grafu hizi, niliongeza pia muda wa miamala kutoka kwa nakala kwa muda wa muamala. Grafu zingine zote hurejelea seva kuu pekee.

Kufikia wakati huu, bodi yangu ya ripoti ilikuwa imekua. Kuna zaidi yao. Tunaona kwamba muda wa wastani wa majibu ya seva ni thabiti. Tunaona kwamba kwenye nakala tuna muamala wa muda mrefu ambao hudumu kwa saa 2. Tunaona operesheni ya utulivu ya otomatiki, ambayo huchakata mistari iliyokufa. Na kila kitu kiko sawa na sisi.

Hasa, kulingana na sahani iliyojaribiwa, tunaendelea kusasisha salio la akaunti huko. Na pia tunayo wakati thabiti wa kujibu maombi, matumizi thabiti ya rasilimali. Kila kitu kiko sawa na sisi.

Kila kitu kiko sawa hadi wakati ripoti hizi zinapoanza kurudiwa kwa sababu ya mgongano na urudufishaji. Na huwasha moto mara kwa mara.

Tunaingia mtandaoni na kuanza kusoma kwa nini hii inafanyika. Na tunapata suluhisho.

Suluhisho la kwanza ni kuongeza latency ya kurudia. Tunajua kwamba ripoti yetu hudumu kwa saa 3. Tunaweka ucheleweshaji wa kurudia hadi masaa 3. Tunazindua kila kitu, lakini bado tunaendelea kuwa na matatizo na ripoti wakati mwingine kughairiwa.

Tunataka kila kitu kiwe kamili. Tunapanda zaidi. Na tulipata mpangilio mzuri kwenye Mtandao - hot_standby_feedback. Hebu tuwashe. Hot_standby_feedback huturuhusu kusimamisha otomatiki kwa Master. Kwa hivyo, tunaondoa kabisa migogoro ya kurudia. Na kila kitu hufanya kazi vizuri kwa ajili yetu na ripoti.

Na nini kinatokea kwa seva kuu kwa wakati huu? Na tuko kwenye shida kabisa na seva ya Mwalimu. Sasa tunaona grafu wakati mipangilio hii yote miwili imewashwa. Na tunaona kwamba kikao kwenye replica yetu kwa namna fulani kilianza kuathiri hali kwenye seva ya Mwalimu. Ana athari kwa sababu alisitisha otomatiki, ambayo huondoa makataa. Ukubwa wa meza yetu umeongezeka tena. Muda wa wastani wa utekelezaji wa hoja kwenye hifadhidata nzima pia uliongezeka sana. Autovacuums ziliimarishwa kidogo.

Hasa, kutoka kwa sahani yetu, tunaona kwamba sasisho la data juu yake pia liliruka mbinguni. Matumizi ya CPU vile vile yameongezeka sana. Tunapitia tena idadi kubwa ya mistari iliyokufa, isiyo na maana. Na wakati wa kujibu kwa ishara hii na idadi ya shughuli imeshuka.

Itakuwaje ikiwa hatujui nilichokuwa nikizungumza hapo awali?

• Tunaanza kutafuta shida. Ikiwa tulipata matatizo katika sehemu ya kwanza, tunajua kwamba hii inaweza kuwa kutokana na shughuli ndefu na kwenda kwa Mwalimu. Tuna tatizo juu ya Mwalimu. Soseji yeye. Inapata joto, Wastani wa Mzigo wake ni karibu mia moja.
• Maombi huko ni ya polepole, lakini hatuoni shughuli zozote za muda mrefu huko. Na hatuelewi ni jambo gani. Hatuelewi wapi pa kuangalia.
• Tunaangalia vifaa vya seva. Labda uvamizi wetu ulianguka. Labda fimbo yetu ya kumbukumbu imechomwa. Ndiyo, chochote kinaweza kutokea. Lakini hapana, seva ni mpya, kila kitu hufanya kazi vizuri.
• Kila mtu anaendesha: wasimamizi, watengenezaji na mkurugenzi. Hakuna kinachosaidia.
• Na wakati fulani kila kitu ghafla huanza kujirekebisha.

Kwa wakati huu, ombi kwenye nakala yetu lilichakatwa na kuondoka. Tumepokea ripoti. Biashara bado ina furaha. Kama unaweza kuona, ishara yetu imeongezeka tena na haitapungua. Kwenye grafu yenye vipindi, niliacha kipande cha muamala huu mrefu kutoka kwa nakala ili uweze kukadiria inachukua muda gani hadi hali itulie.

Kikao kimekwisha. Na tu baada ya muda fulani seva inakuja zaidi au chini kwa utaratibu. Na muda wa wastani wa kujibu maombi kwenye seva ya Mwalimu hurudi kwa kawaida. Kwa sababu, hatimaye, otomatiki ina fursa ya kusafisha na kuweka alama kwenye mistari hii iliyokufa. Na akaanza kufanya kazi yake. Na jinsi anavyofanya haraka, kwa haraka tutapata utaratibu.

Kulingana na kompyuta kibao iliyojaribiwa, ambapo tunasasisha salio la akaunti, tunaona picha sawa. Muda wa wastani wa kusasisha akaunti pia unabadilika polepole. Rasilimali zinazotumiwa na processor pia hupunguzwa. Na idadi ya shughuli kwa sekunde inarudi kawaida. Lakini tena tumerudi katika hali ya kawaida, si kama tulivyokuwa kabla ya ajali.

Kwa hali yoyote, tunapata mteremko wa utendaji, kama katika kesi ya kwanza, kwa mara moja na nusu hadi mbili, na wakati mwingine zaidi.

Tunaonekana tumefanya kila kitu sawa. Sambaza mzigo. Vifaa havifanyi kazi. Tuligawanya maombi kulingana na akili zetu, lakini bado kila kitu kilienda vibaya.

• Je, usiwashe_hot_standby_feedback? Ndio, haipendekezi kuiwasha bila sababu kali sana. Kwa sababu twist hii huathiri moja kwa moja seva ya Mwalimu na kusimamisha utendakazi wa otomatiki huko. Kwa kuiwezesha kwenye nakala fulani na kuisahau, unaweza kumuua Mwalimu na kupata matatizo makubwa na programu.
• Ungependa kuongeza ucheleweshaji_wa_kusubiri_wa_kutiririsha? Ndiyo, kwa ripoti hii ni kweli. Ikiwa una ripoti ya saa tatu na hutaki ivunjike kwa sababu ya mizozo ya urudufishaji, basi ongeza tu ucheleweshaji. Ripoti ya muda mrefu haihitaji kamwe data ambayo imefika kwenye hifadhidata hivi sasa. Ikiwa unayo kwa saa tatu, basi unaiendesha kwa kipindi cha zamani cha data. Na kwako, ikiwa kuna kuchelewa kwa saa tatu au kuchelewa kwa saa sita hakutafanya tofauti yoyote, lakini utapokea ripoti mara kwa mara na hautakuwa na matatizo yoyote na wao kuanguka.
• Kwa kawaida, unahitaji kudhibiti vipindi virefu kwenye nakala, haswa ikiwa utaamua kuwezesha hot_standby_feedback kwenye nakala. Kwa sababu chochote kinaweza kutokea. Tulitoa nakala hii kwa msanidi programu ili aweze kujaribu maombi. Aliandika ombi la kichaa. Akaizindua na kwenda kunywa chai, tukampata Mwalimu aliyeimarika. Au labda tumeweka maombi yasiyo sahihi hapo. Hali ni tofauti. Vikao kwenye nakala lazima vifuatiliwe kwa uangalifu kama vile kwa Mwalimu.
• Na ikiwa una maswali ya haraka na ya muda mrefu kwenye replicas, basi katika kesi hii ni bora kugawanyika ili kusambaza mzigo. Hiki ni kiungo cha kutiririsha_kuchelewa. Kwa zile za haraka, uwe na nakala moja iliyochelewa kunakiliwa kidogo. Kwa maombi ya kuripoti ya muda mrefu, uwe na nakala ambayo inaweza kuchelewa kwa saa 6 au siku. Hii ni hali ya kawaida kabisa.

Tunaondoa matokeo kwa njia ile ile:

• Tunapata meza zilizojaa.
• Na tunaikandamiza na zana inayofaa zaidi ambayo inafaa kwetu.

Hadithi ya pili inaishia hapa. Hebu tuendelee hadi hadithi ya tatu.

Pia ni kawaida kwa ajili yetu ambayo sisi kufanya uhamiaji.

• Bidhaa yoyote ya programu inakua. Mahitaji yake yanabadilika. Kwa hali yoyote, tunataka kuendeleza. Na hutokea kwamba tunahitaji kusasisha data iliyo kwenye jedwali, yaani kufanya sasisho kulingana na uhamishaji wetu kwa utendakazi mpya tunaoanzisha kama sehemu ya maendeleo yetu.
• Fomati ya zamani ya data hairidhishi. Wacha tuseme sasa tunageukia jedwali la pili, ambapo nina shughuli kwenye akaunti hizi. Na tuseme kwamba walikuwa katika rubles, na tuliamua kuongeza usahihi na kuifanya kwa kopecks. Na kwa hili tunahitaji kufanya sasisho: kuzidisha shamba na kiasi cha manunuzi kwa mia moja.
• Katika ulimwengu wa kisasa, tunatumia zana za udhibiti wa toleo la hifadhidata otomatiki. Hebu tuseme Liquibase. Tunasajili uhamiaji wetu huko. Tunaijaribu kwa msingi wetu wa mtihani. Kila kitu kiko sawa. Sasisho linapitia. Inazuia kazi kwa muda, lakini tunapata data iliyosasishwa. Na tunaweza kuzindua utendakazi mpya kwenye hili. Kila kitu kilijaribiwa na kuchunguzwa. Kila kitu kilithibitishwa.
• Tulifanya kazi iliyopangwa na kufanya uhamiaji.

Huu hapa ni uhamishaji na sasisho lililowasilishwa mbele yako. Kwa kuwa hizi ni shughuli za akaunti yangu, sahani ilikuwa 15 GB. Na kwa kuwa tunasasisha kila mstari, tuliongeza ukubwa wa jedwali mara mbili na sasisho, kwa sababu tuliandika upya kila mstari.

Wakati wa uhamiaji, hatukuweza kufanya chochote na sahani hii, kwa sababu maombi yote kwake yamewekwa kwenye foleni na kusubiri hadi sasisho hili likamilike. Lakini hapa nataka kuteka mawazo yako kwa nambari ambazo ziko kwenye mhimili wima. Hiyo ni, tuna muda wa ombi la wastani kabla ya uhamiaji wa karibu milliseconds 5 na mzigo wa processor, idadi ya shughuli za kuzuia kwa kusoma kumbukumbu ya disk ni chini ya 7,5.

Tulifanya uhamiaji na tukapata shida tena.

Uhamiaji ulifanikiwa, lakini:

• Utendaji wa zamani sasa unachukua muda mrefu kukamilika.
• meza ilikua kwa ukubwa tena.
• Mzigo kwenye seva tena ukawa mkubwa kuliko hapo awali.
• Na, bila shaka, bado tunachezea utendakazi uliofanya kazi vizuri, tumeuboresha kidogo.

Na hii ni bloat tena, ambayo inaharibu tena maisha yetu.

Hapa ninaonyesha kuwa jedwali, kama kesi mbili zilizopita, haitarudi kwa saizi zake za zamani. Upakiaji wa wastani wa seva unaonekana kuwa wa kutosha.

Na ikiwa tunageuka kwenye meza na akaunti, tutaona kwamba muda wa ombi la wastani umeongezeka mara mbili kwa meza hii. Mzigo kwenye kichakataji na idadi ya mistari iliyopangwa kwenye kumbukumbu iliruka juu ya 7,5, lakini ilikuwa chini. Na iliruka mara 2 katika kesi ya wasindikaji, mara 1,5 katika kesi ya shughuli za kuzuia, i.e. tulipata uharibifu katika utendaji wa seva. Na matokeo yake - uharibifu wa utendaji wa maombi yetu. Wakati huo huo, idadi ya simu ilibaki takriban kwa kiwango sawa.

Na jambo kuu hapa ni kuelewa jinsi ya kufanya uhamiaji kama huo kwa usahihi. Na zinahitaji kufanywa. Tunafanya uhamiaji huu mara kwa mara.

• Uhamiaji mkubwa kama huo haufanyiki kiatomati. Wanapaswa kuwa chini ya udhibiti kila wakati.
• Uangalizi wa mtu mwenye ujuzi unahitajika. Ikiwa una DBA kwenye timu yako, basi acha DBA ifanye hivyo. Ni kazi yake. Ikiwa sivyo, basi wacha mtu mwenye uzoefu zaidi afanye, ambaye anajua jinsi ya kufanya kazi na hifadhidata.
• Ratiba mpya ya hifadhidata, hata ikiwa tutasasisha safu wima moja, tunatayarisha kila mara kwa hatua, yaani mapema kabla toleo jipya la programu kutekelezwa:
• Sehemu mpya zinaongezwa ambamo tutarekodi data iliyosasishwa.
• Tunahamisha data kutoka kwa uwanja wa zamani hadi uwanja mpya katika sehemu ndogo. Kwa nini tunafanya hivi? Kwanza, sisi daima kudhibiti mchakato wa mchakato huu. Tunajua kwamba tayari tumehamisha bechi nyingi na tumebakisha nyingi.
• Na athari chanya ya pili ni kwamba kati ya kila kundi kama hilo tunafunga shughuli, kufungua mpya, na hii inaruhusu autovacuum kufanya kazi kulingana na sahani, alama mistari iliyokufa kwa matumizi tena.
• Kwa mistari ambayo itaonekana wakati programu inaendelea (bado tunayo programu ya zamani inayofanya kazi), tunaongeza kichochezi ambacho huandika maadili mapya kwa sehemu mpya. Kwa upande wetu, hii ni kuzidisha kwa mia moja ya thamani ya zamani.
• Ikiwa sisi ni wakaidi kabisa na tunataka uga sawa, basi baada ya kukamilisha uhamiaji wote na kabla ya kutoa toleo jipya la programu, tunabadilisha jina la sehemu. Wale wa zamani hupewa jina la zuliwa, na uwanja mpya hupewa jina la zamani.
• Na tu baada ya hapo tunazindua toleo jipya la programu.

Na wakati huo huo hatutapata bloat na hatutateseka katika suala la utendaji.

Hapa ndipo hadithi ya tatu inapoishia.

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

Na sasa maelezo zaidi juu ya zana ambazo nilitaja katika hadithi ya kwanza kabisa.

Kabla ya kutafuta bloat, lazima usakinishe ugani pgstattuple.

Ili usihitaji kuja na maswali, tayari tumeandika maswali haya katika kazi yetu. Unaweza kuzitumia. Kuna maombi mawili hapa.

• Ya kwanza inachukua muda mrefu sana kufanya kazi, lakini itakuonyesha maadili halisi ya bloat kutoka kwa meza.
• Ya pili inafanya kazi kwa kasi na inafaa sana wakati unahitaji kutathmini haraka ikiwa kuna bloat au la kulingana na meza. Na unapaswa pia kuelewa kwamba bloat daima iko kwenye meza ya Postgres. Hii ni kipengele cha mfano wake wa MVCC.
• Na 20% bloat ni kawaida kwa meza katika hali nyingi. Hiyo ni, unapaswa kuwa na wasiwasi na compress meza hii.

Tuligundua jinsi ya kutambua meza ambazo zimevimba na data isiyo na maana.

Sasa kuhusu jinsi ya kurekebisha bloat:

• Ikiwa tuna kibao kidogo na disks nzuri, yaani, kwenye kibao hadi gigabyte, inawezekana kabisa kutumia VACUUM FULL. Atachukua lock ya kipekee kutoka kwako kwenye meza kwa sekunde chache na sawa, lakini atafanya kila kitu haraka na kwa ukali. VACUUM FULL hufanya nini? Inahitaji kufuli ya kipekee kwenye jedwali na kuandika upya safu mlalo za moja kwa moja kutoka kwa jedwali kuu hadi kwenye jedwali jipya. Na mwisho anachukua nafasi yao. Inafuta faili za zamani na kubadilisha zile za zamani na mpya. Lakini kwa muda wa kazi yake, inachukua lock ya kipekee kwenye meza. Hii ina maana kwamba huwezi kufanya chochote na meza hii: wala kuandika kwa hilo, wala kusoma ndani yake, wala kurekebisha. Na VACUUM FULL inahitaji nafasi ya ziada ya diski ili kuandika data.
• Zana inayofuata pg_repack. Kwa kanuni yake, ni sawa na VACUUM FULL, kwa sababu pia huandika tena data kutoka kwa faili za zamani hadi mpya na kuzibadilisha kwenye meza. Lakini wakati huo huo, haichukui lock ya kipekee kwenye meza mwanzoni mwa kazi yake, lakini inachukua tu wakati ambapo tayari ina data tayari ili kuchukua nafasi ya faili. Mahitaji yake ya rasilimali ya diski ni sawa na yale ya VACUUM FULL. Unahitaji nafasi ya ziada ya diski, na hii wakati mwingine ni muhimu ikiwa una meza za terabyte. Na ina njaa ya kusindika kwa sababu inafanya kazi kikamilifu na I/O.
• Huduma ya tatu ni pgcompacttable. Ni makini zaidi na rasilimali kwa sababu inafanya kazi kulingana na kanuni tofauti kidogo. Wazo kuu la pgcompacttable ni kwamba inasonga safu zote za moja kwa moja hadi mwanzo wa jedwali kwa kutumia sasisho kwenye jedwali. Na kisha inaendesha ombwe kwenye jedwali hili, kwa sababu tunajua kwamba tuna safu mlalo hai mwanzoni na safu zilizokufa mwishoni. Na utupu yenyewe hukata mkia huu, i.e. hauitaji nafasi nyingi za ziada za diski. Na wakati huo huo, inaweza bado kubanwa katika suala la rasilimali.

Kila kitu na zana.

Ikiwa unaona mada ya bloat ya kuvutia katika suala la kutafakari zaidi ndani, hapa kuna viungo muhimu:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - Hii ni ripoti kutoka kwa mwenzangu. Ni jumla kuhusu mahali ambapo nafasi ya Postgres huenda wakati wa kazi na maisha yake. Na kuna sehemu kubwa ya kiufundi na ya kina kwa wasimamizi wa hifadhidata kuhusu bloat.
• https://github.com/dataegret/pg-utils - hiki ni kiunga cha hazina yetu, ambapo tunahifadhi rundo la hati muhimu kwa kuangalia hali ya hifadhidata. Huko unaweza kupata hati za kutafuta bloat.
• Tatu и nne viungo vya zana ambazo zitakusaidia kupunguza ishara.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - hii ni chapisho kutoka kwa mwenzangu. Huko kwa umakini na kitaalam anachambua bloat kwa undani katika kiwango cha karibu na wasimamizi.

Nilijaribu zaidi kuonyesha hadithi ya kutisha kwa wasanidi programu, kwa sababu wao ni wateja wetu wa moja kwa moja wa hifadhidata na lazima waelewe ni nini na hatua gani husababisha. Natumai nimefaulu. Asante kwa umakini wako!

maswali

Asante kwa ripoti! Ulizungumza juu ya jinsi unavyoweza kutambua shida. Wanawezaje kuonywa? Hiyo ni, nilikuwa na hali ambapo maombi yalipachikwa sio tu kwa sababu walipata huduma zingine za nje. Hizi zilikuwa ni baadhi tu ya viungo vya porini. Kulikuwa na maombi madogo, yasiyo na madhara ambayo yalikaa kwa siku, na kisha kuanza kufanya upuuzi. Yaani inafanana sana na unavyoeleza. Jinsi ya kufuatilia hii? Keti na kutazama kila wakati ni ombi gani ambalo limekwama? Je, jambo hili linaweza kuzuiwaje?

Katika kesi hii, hii ni kazi kwa wasimamizi wa kampuni yako, sio lazima kwa DBA.

Mimi ni msimamizi.

PostgreSQL ina mwonekano unaoitwa pg_stat_activity ambao unaonyesha maswali yanayoning'inia. Na unaweza kuona ni muda gani hutegemea hapo.

Je, ni lazima niingie na kuangalia kila baada ya dakika 5?

Sanidi cron na uangalie. Ikiwa una ombi la muda mrefu, andika barua na ndivyo. Hiyo ni, huna haja ya kuangalia kwa macho yako, inaweza kuwa automatiska. Utapokea barua, unaitikia. Au unaweza kupiga moja kwa moja.

Je, kuna sababu zozote za wazi kwa nini hii hutokea?

Nimeorodhesha baadhi. Mifano nyingine ngumu zaidi. Na kunaweza kuwa na mazungumzo kwa muda mrefu.

Asante kwa ripoti! Nilitaka kufafanua juu ya matumizi ya pg_repack. Ikiwa hatafunga kufuli ya kipekee, basi...

Anafunga kufuli ya kipekee.

... basi ningeweza kupoteza data. Je, maombi yangu hayapaswi kurekodi chochote wakati huu?

Hapana, inafanya kazi vizuri na jedwali, yaani pg_repack kwanza huhamisha njia zote za moja kwa moja zilizopo. Kwa kawaida, aina fulani ya kuingia kwenye meza hutokea pale. Anatupa tu mkia huu wa farasi.

Hiyo ni, anafanya hivyo mwishowe?

Mwishowe, anachukua kufuli ya kipekee ili kubadilisha faili hizi.

Je, itakuwa haraka kuliko VACUUM FULL?

VACUUM FULL, mara tu ilipoanza, mara moja ilichukua kufuli ya kipekee. Na mpaka afanye kila kitu, hatamwacha aende zake. Na pg_repack inachukua kufuli ya kipekee wakati wa uingizwaji wa faili. Kwa wakati huu hutaandika hapo, lakini data haitapotea, kila kitu kitakuwa sawa.

Habari! Ulizungumza juu ya operesheni ya utupu wa gari. Kulikuwa na grafu yenye seli nyekundu, njano na kijani za kurekodi. Hiyo ni, za manjano - aliziweka alama kama zimefutwa. Na matokeo yake, kitu kipya kinaweza kuandikwa ndani yao?

Ndiyo. Postgres haifuti mistari. Ana sifa kama hiyo. Ikiwa tulisasisha laini, tulitia alama ya zamani kuwa imefutwa. Kitambulisho cha shughuli iliyobadilisha laini hii inaonekana hapo, na tunaandika laini mpya. Na tuna vipindi ambavyo vinaweza kuvisoma. Wakati fulani wanakuwa wazee kabisa. Na kiini cha jinsi autovacuum inavyofanya kazi ni kwamba inapitia mistari hii na kuashiria kuwa sio lazima. Na unaweza kubatilisha data hapo.

Naelewa. Lakini hilo sio swali linalohusu. sikumaliza. Wacha tuchukue kuwa tunayo meza. Ina mashamba ya ukubwa kutofautiana. Na ikiwa nitajaribu kuingiza kitu kipya, kinaweza kutoshea kwenye seli ya zamani.

Hapana, kwa hali yoyote mstari mzima unasasishwa hapo. Postgres ina mifano miwili ya kuhifadhi data. Inachagua kutoka kwa aina ya data. Kuna data ambayo imehifadhiwa moja kwa moja kwenye jedwali, na pia kuna data ya tos. Hizi ni kiasi kikubwa cha data: maandishi, json. Wao huhifadhiwa katika sahani tofauti. Na kwa mujibu wa vidonge hivi, hadithi sawa na bloat hutokea, yaani kila kitu ni sawa. Wameorodheshwa tu tofauti.

Asante kwa ripoti! Je, inakubalika kutumia hoja za kuisha kwa taarifa ili kupunguza muda?

Inakubalika sana. Tunatumia hii kila mahali. Na kwa kuwa hatuna huduma zetu wenyewe, tunatoa usaidizi wa mbali, tuna wateja mbalimbali. Na kila mtu ameridhika kabisa na hii. Hiyo ni, tuna kazi za cron ambazo huangalia. Muda wa vikao unakubaliwa tu na mteja, kabla ambayo hatukubaliani. Inaweza kuwa dakika, inaweza kuwa dakika 10. Inategemea mzigo kwenye msingi na madhumuni yake. Lakini sote tunatumia pg_stat_activity.

Asante kwa ripoti! Ninajaribu kutumia ripoti yako kwa maombi yangu. Na inaonekana kama tunaanza shughuli kila mahali, na kuikamilisha kwa uwazi kila mahali. Ikiwa kuna ubaguzi, basi kurudi nyuma bado kunatokea. Na kisha nikaanza kufikiria. Baada ya yote, shughuli inaweza kuanza kwa uwazi. Labda hii ni kidokezo kwa msichana. Ikiwa nitasasisha rekodi tu, muamala utaanza katika PostgreSQL na utakamilika tu wakati muunganisho umekatishwa?

Ikiwa unasema sasa juu ya kiwango cha maombi, basi inategemea dereva unayotumia, kwenye ORM ambayo inatumiwa. Kuna mipangilio mingi huko. Ikiwa umewasha ahadi ya kiotomatiki, basi shughuli itaanzia hapo na kufungwa mara moja.

Hiyo ni, inafunga mara moja baada ya sasisho?

Inategemea mipangilio. Nilitaja mpangilio mmoja. Hii ni ahadi ya kiotomatiki. Ni kawaida kabisa. Ikiwa imewezeshwa, basi shughuli imefunguliwa na kufungwa. Isipokuwa umesema kwa uwazi "anza muamala" na "malizia muamala", lakini umezindua ombi kwenye kipindi.

Habari! Asante kwa ripoti! Wacha tufikirie kuwa tuna hifadhidata ambayo ni uvimbe na uvimbe na kisha nafasi kwenye seva inaisha. Je, kuna zana zozote za kurekebisha hali hii?

Nafasi kwenye seva inahitaji kufuatiliwa vizuri.

Kwa mfano, DBA ilikwenda kwa chai, ilikuwa kwenye mapumziko, nk.

Wakati mfumo wa faili umeundwa, angalau aina fulani ya nafasi ya hifadhi huundwa ambapo data haijaandikwa.

Nini ikiwa iko chini ya sifuri kabisa?

Huko inaitwa nafasi iliyohifadhiwa, i.e. inaweza kuachiliwa na kulingana na jinsi ilivyokuwa kubwa, unapata nafasi ya bure. By default sijui ni wangapi. Na katika kesi nyingine, toa diski ili uwe na nafasi ya kufanya operesheni ya kuunda upya. Unaweza kufuta baadhi ya jedwali ambalo umehakikishiwa kuwa hutahitaji.

Je, kuna zana nyingine yoyote?

Imetengenezwa kwa mikono kila wakati. Na ndani ya nchi inakuwa wazi ni nini bora kufanya huko, kwa sababu data zingine ni muhimu na zingine sio muhimu. Na kwa kila hifadhidata na programu inayofanya kazi nayo, inategemea biashara. Daima huamuliwa ndani ya nchi.

Asante kwa ripoti! Nina maswali mawili. Kwanza, ulionyesha slaidi zilizoonyesha kwamba wakati shughuli za malipo zimekwama, ukubwa wa meza na ukubwa wa faharasa hukua. Na zaidi kwenye ripoti hiyo kulikuwa na rundo la huduma zinazofunga kompyuta kibao. Vipi kuhusu index?

Wanazipakia pia.

Lakini utupu hauathiri index?

Baadhi hufanya kazi na faharasa. Kwa mfano, pg_rapack, pgcompacttable. Utupu huunda upya fahirisi na kuziathiri. Kwa VACUUM FULL wazo ni kufuta kila kitu, yaani, inafanya kazi na kila mtu.

Na swali la pili. Sielewi kwa nini ripoti za nakala zinategemea sana urudufishaji wenyewe. Ilionekana kwangu kuwa ripoti zinasomwa, na nakala ni kuandika.

Ni nini husababisha mzozo wa kurudia? Tuna Mwalimu ambaye michakato inafanyika. Tuna utupu wa gari unaendelea. Je, otomatiki hufanya nini hasa? Anakata mistari ya zamani. Ikiwa kwa wakati huu tuna ombi kwenye replica ambayo inasoma mistari hii ya zamani, na juu ya Mwalimu hali ilitokea kwamba autovacuum iliweka alama ya mistari hii iwezekanavyo kwa kufuta, basi tunaifuta. Na tulipokea pakiti ya data, tunapohitaji kuandika upya mistari hiyo ambayo ombi linahitaji kwenye nakala, mchakato wa kurudia utasubiri kuisha kwa muda uliosanidi. Na kisha PostgreSQL itaamua ni nini muhimu zaidi kwake. Na replication ni muhimu zaidi kwake kuliko ombi, na atapiga ombi ili kufanya mabadiliko haya kwenye replica.

Andrey, nina swali. Grafu hizi za ajabu ulizoonyesha wakati wa uwasilishaji, je, hizi ni matokeo ya kazi ya aina fulani ya matumizi yako? Je, grafu zilitengenezwaje?

Hii ni huduma Okmeter.

Je, hii ni bidhaa ya kibiashara?

Ndiyo. Hii ni bidhaa ya kibiashara.

Chanzo: mapenzi.com