Tüüpilised vead rakendustes, mis viivad bloat'i tekkimiseni PostgreSQL-is. Andrei Salnikovi

Soovitan tutvuda Andrei Salnikovi 2016. aasta alguses esitatud ettekande "Tüüpilised vead rakendustes, mis viivad bloat'i tekkimiseni PostgreSQL-is" kokkuvõttega.

Selles ettekandes käsitlen peamisi vigu rakendustes, mis tekivad rakenduse projekteerimise ja kodeerimise etapis. Keskendun vaid neile vigadele, mis viivad bloat'i tekkimiseni PostgreSQL-is. Reeglina on see teie süsteemi jõudluse languse algus, kuigi algselt ei olnud mingeid näiliselt halbu märke.

Tere tulemast! See ettekande ei ole nii tehniline kui eelmine minu kolleegi esitlus. See ettekande on suunatud peamiselt tagaplaneedi süsteemide arendajatele, kuna meil on piisavalt palju kliente. Ja kõik nad teevad samu vigu. Nendest räägin ma teile. Selgitan, millistele fataalsetele ja halbadele tagajärgedele need vead viivad.

Miks tekivad vead? Need tekivad kahe põhjusel: mõnikord lootuses, et äkki läheb õnneks, ja teadmatusest mehhanismide osas, mis toimuvad andmebaasi ja rakenduse vahel, samuti andmebaasi enda sees.

Toon teile kolm näidet koos kohutavate piltidega, kuidas kõik halvemaks läheb. Räägin lühidalt mehhanismist, mis seal toimub. Ja kuidas nendega toime tulla, kui nad juhtuvad, ja milliseid ennetavaid meetodeid kasutada vigade vältimiseks. Räägin abistavatest tööriistadest ja annan kasulikke linke.

Kasutasin testandmebaasi, kus mul oli kaks tabelit. Üks tabel klientide arvetega, teine nende arvete tehingutega. Ja teatud perioodilisusega uuendame nende arvetel olevaid jääke.

Tabeli algandmed: see on piisavalt väike, 2 MB. Andmebaasi ja konkreetselt tabeli vastuse aeg on samuti väga hea. Ja päris hea koormus – 2000 tehingut sekundis tabeli kohta.

Ja kogu selle ettekande jooksul näitan teile graafikuid, et oleks selge, mis toimub. Alati on 2 slaidi graafikut. Esimene slaid – see, mis toimub serveris üldiselt.

Ja antud olukorras näeme, et meie tabel on tõeliselt väike. Indeks on väike, 2 MB. See on esimene graafik vasakul.

Keskmine vastuse aeg serveris on samuti stabiilne, väikene. See on ülemises paremas graafikus.

Vasaku alumise diagrammi peal on kõige pikemad tehingud. Näeme, et tehingud täidetakse kiiresti. Ja automaatne vaakum ei tööta veel, kuna see oli starditest. Edasi hakkab see tööle ja on meile kasulik.

Teine slaid on alati pühendatud katsetatavale tabelile. Selles olukorras uuendame pidevalt kliendi kontode jääke. Ja me näeme, et keskmine reageerimisaeg uuendustegevuses on piisavalt hea, vähem kui millisekund. Näeme, et protsessori ressursid (see on paremas ülanurgas olev diagramm) on samuti tasakaalustatult ja piisavalt väikesed.

Paremas alumises diagrammis näitab, kui palju operatiivset ja kettamälu me otsime meie vajaliku rida, enne kui selle uuendame. Ja tabeli operatsioonide arv – 2000 sekundis, nagu ma ütlesin alguses.

Ja nüüd toimub meil tragöödia. Mingil põhjusel tekib pikk unustatud tehing. Põhjused on tavaliselt kõik banaalsed:

• Üks levinumaid põhjusi on see, et me rakenduse koodis alustasime välisesse teenusesse pöördumist. Ja see teenus ei vasta meile. St avasime tehingu, tegime muudatuse andmebaasis ja läksime rakendusest e-kirju lugema või mõnda teise teenusesse meie infrastruktuuris, ja see ei vasta meile mingil põhjusel. Ja meil jäi seanss seisundisse – ei ole teada, millal see lahtiseks saab.
• Teine olukord, kui meie koodis mingil põhjusel tekkis erand. Ja me ei töötanud välja tehingu sulgemist erandi korral. Ja meil tekkis rippuv seanss avatud tehinguga.
• Ja viimane – see on ka üsna levinud juhtum. See on kehva kvaliteediga kood. Mõned raamistikud avavad tehingu. See ripub ja te ei pruugi rakenduses teada, et see on riputatud.

Kuhu need asjad viivad?

Sellest tulenevalt hakkavad meie tabelid ja indeksid järsult paisuma. See on just see bloati efekt. Andmebaasi jaoks väljendub see selles, et meie andmebaasi reageerimisaeg suureneb järsult, koormus andmebaasi serverile tõuseb. Ja tulemuseks hakkab rakendus kannatama. Sest kui te kulutasite koodis 10 millisekundit andmebaasi päringule, 10 millisekundit oma loogika jaoks, siis teie funktsioon töötas 20 millisekundit. Ja nüüd on teie olukord täiesti kurb.

Ja vaatame, mis toimub. Vasak alammõõtja näitab, et meil on pikad tehingud. Ja kui vaatame vasakut ülemist graafikut, siis näeme, et meie kahe megabaidi suurune tabel on järsku tõusnud 300 megabaidini. Samas andmete hulk tabelis ei muutunud, st seal on palju rämpsu.

Üldine olukord keskmise serveri vastuseaja osas on samuti muutunud mitmes järjestikus. St kõik serveripäringud on tõsiselt kasvanud. Ja samal ajal on käima läinud Postgresi sisemised protsessid autovakuumi näol, mis üritavad midagi teha ja võtavad ressursse.

Mis meie tabeliga juhtub? Täpselt sama asi. Keskmine vastuseaeg tabeli jaoks on tõusnud mitmes järjestikus. Kui rääkida ressursside tarbimisest, siis näeme, et protsessorile on koormus järsult suurenenud. See on paremal ülemisel graafikul. Ja see suurenemine toimub, kuna protsessor peab otsima palju kasutut rida ühe vajaliku leidmiseks. See on paremal alumisel graafikul. Ja tulemuseks on see, et meie päringute arv sekundis hakkas järsult vähenema, kuna andmebaas ei suuda töödelda sama palju päringuid.

Peame uuesti ellu ärkama. Uurime internetist, et pikad tehingud toovad probleeme. Leiame ja lõpetame selle tehingu. Ja siis muutub kõik normaalseks. Kõik töötab nagu peab.

Me rahunesime, kuid mõne aja pärast hakkame märkama, et rakendus ei tööta enam nagu oli enne avariid. Päringud töödeldakse siiski aeglasemalt, oluliselt aeglasemalt. Ükskõik kui poolteist kuni kaks korda aeglasemalt, mis puudutab minu näidet. Serveri koormus on samuti kõrgem kui avariieelsel ajal.

Küsimus on: „Mis toimub andmebaasiga sel hetkel?“. Andmebaasis toimub järgnev olukord. Tehingute graafikul näete, et see on peatunud ja seal tõepoolest ei ole pikki tehinguid. Kuid tabeli suurus avarii ajal on saanud fataalselt suureks. Ja sellest ajast alates ei ole see vähenenud. Keskmine aeg andmebaasi jaoks on stabiliseerunud. Ja vastused tunduvad liikuvat normaalselt, meie jaoks vastuvõetava kiirusena. Autovakuum on muutunud aktiivsemaks ja hakkas tegema midagi tabeliga, kuna tal on vaja töödelda suuremat hulka andmeid.

Konkreetsete arve tabeli osas, kus me muudame jääke: päringu vastusaeg on näiliselt naasnud normaalsusesse. Kuid tegelikult on see poolteise korra võrra kõrgem.

Ja protsessori koormuse osas näeme, et protsessori koormus ei ole naasnud enne avariid vajaliku tasemeni. Põhjused peituvad just paremas alanurgas olevas graafikus. On näha, et seal toimub teatud koguse mälu ületamine. See tähendab, et vajaliku rea leidmiseks kulutame andmebaasi serveri ressursse mõttetu andmete töötlemise tõttu. Tehingute arv sekundis on stabiliseerunud.

Üldiselt on kõik hästi, aga olukord on halvem kui enne. Selge andmebaasi deklareerimine meie rakenduse tagajärjel, mis töötab selle andmebaasiga.

Ja et aru saada, mis seal toimub, kui te ei olnud eelmisel ettekandel, siis nüüd natuke teooriat. Teooria sisemisest protsessist. Miks on autovakuum ja mida see teeb?

Lühidalt arusaamiseks. Teatud hetkel on meil tabel. Tabelis on meil read. Need read võivad olla aktiivsed, elavad, meie jaoks vajalikud. Joonisel on nad rohelise värviga märgitud. Ja on surnud read, mis on juba tööd teinud, on uuendatud, millele on lisatud uusi kirjeid. Ja need on märgitud, et nad ei ole andmebaasile enam huvitavad. Kuid nad jäävad tabelisse Postgresi eripära tõttu.

Miks on vajalik autovakuum? Autovakuum tuleb teatud hetkel, pöördub andmebaasi poole ja küsib: "Palun anna mulle kõige vanema tehingu id, mis on praegu andmebaasis avatud." Andmebaas tagastab selle id. Ja autovakuum tuginedes sellele läbib tabeli read. Ja kui ta näeb, et teatud read on muutunud palju vanemate tehingute tõttu, siis on tal õigus neid märgistada ridadena, mida saame tulevikus uuesti kasutada, kirjutades sinna uusi andmeid. See on taustprotsess.

Selle ajal jätkame andmebaasiga töötamist, jätkame tabelis muudatuste tegemist. Ja nendele ridadele, mida saame uuesti kasutada, kirjutame uusi andmeid. Nii et meil tekib ringkäik, st seal tekib pidevalt mõningaid vanu surnud ridad, mille asemel kirjutame uusi ridu, mis meile vajalikud. Ja see on PostgreSQL-i töötamise normaalne seisund.

Mis juhtus avarii ajal? Kuidas see protsess seal toimus?

Meil oli mingisugune tabel, mõned read olid elavad ja mõned surnud. Siis tuli automaatne vaakum. See küsis andmebaasist, milline on meie vanim tehing ja mis on selle ID. Ta sai selle ID, mis võib olla mitu tundi vana või kümme minutit vana. See sõltub sellest, kui suur on koormus teie andmebaasis. Ja ta läks otsima ridu, mida ta saaks märgistada taaskasutatavateks. Ja ta ei leidnud meie tabelis selliseid ridu.

Aga samal ajal jätkame me tabeliga töötamist. Teeme seal midagi, uuendame, muudame andmeid. Ja mida andmebaas sel ajal teeb? Tal ei jää muud üle, kui kirjutada uusi ridu olemasoleva tabeli lõppu. Ja seeläbi meie tabeli suurus hakkab paisuma.

Tegelikult vajame me töötamiseks rohelisi ridu. Aga sellise probleemi ajal on meil nii, et roheliste ridade protsent kogu tabeli mahus on äärmiselt madal.

Ja kui me sooritame päringu, peab andmebaas läbi käima kõik read: nii punased kui ka rohelised, et leida vajalik rida. Ja tabeli paisumise mõju, mis sisaldab kasutu teavet, nimetatakse "bloat", mis sööb ära meie kettaruumi. Kas mäletate, oli 2 MB, nüüd on 300 MB? Nüüd vahetage megabaitide asemel gigabaitide ja te võite kiiresti kaotada kogu oma kettaruumi.

Millised tagajärjed võivad meile olla?

• Minu näites kasvas tabel ja indeks 150 korda. Mõnel meie kliendil on olnud isegi tõsisemaid juhtumeid, kui kettaruumi hakkas otsa saama.
• Tabelite suurus ei vähene kunagi iseenesest. Automaatne vaakum võib mõnel juhul tabeli sabajupi ära lõigata, kui seal on ainult surnud read. Aga kuna toimub pidev rotatsioon, võib üks roheline rida lõpus jääda seisma ja mitte uuenduda, samas kui kõik teised kirjutatakse kuskil tabeli algusesse. Aga see on nii ebatõenäoline sündmus, et teie tabel ise mingil määral väheneks, mis ei ole midagi, millele tasuks loota.
• Andmebaas peab läbi töötama kogu hulga mõttetuid ridu. Ja me kulutame kettaruumi, kulutame protsessori ressursse ja elektrit.
• Ja see mõjutab otseselt meie rakendust, kuna kui alguses kulutasime päringule 10 millisekundit ja meie koodile samuti 10 millisekundit, siis avarii ajal hakkasime kulutama päringule ühe sekundi ja koodile 10 millisekundit, st rakenduse jõudlus vähenes oluliselt. Kui avarii lõpetati, kulus meil 20 millisekundit päringule ja 10 millisekundit koodile. See tähendab, et meie jõudlus langes endiselt 1,5 korda. Ja see kõik oli tingitud ühest tehingust, mis jäi pidama, ilmselt meie enda süül.
• Ja küsimus on: 'Kuidas kõik tagasi saada?', et meie süsteem toimiks taas sama kiiresti nagu enne avariid.

Selleks on olemas kindel töötsükkel, mida tuleb järgida.

Esiteks peame leidma probleemsed tabelid, mis on paisunud. Me mõistame, et teatud tabelitesse toimub aktiivsem kirjutamine, teistesse aga vähem. Selleks kasutatakse laiendust pgstattuple. Pärast selle laienduse installimist saate kirjutada päringuid, mis aitavad leida piisavalt paisunud tabeleid.

Pärast nende tabelite leidmist tuleb need kokku võtta. Selleks on olemas tööriistad. Meie ettevõttes kasutame kolme tööriista. Esimene on sisseehitatud VACUUM FULL. See on karm, range ja halastamatu, kuid mõnikord on see väga kasulik. Pg_repack ja pgcompacttable – need on kolmandate osapoolte utiliidid tabelite kokku pakkumiseks. Need on andmebaasi suhtes õrnemad.

Neid kasutatakse sõltuvalt sellest, mis teile mugavam on. Kuid sellest räägin ma lõpupoole. Peamine on see, et meil on kolm tööriista. On, mida valida.

Pärast kõigi parandamist ja veendumist, et kõik on hästi, peame teadma, kuidas tulevikus selliseid olukordi ära hoida:

• Seda on üsna lihtne vältida. Tuleb jälgida seansside kestvust Master-serveris. Eriti ohtlikud seansid on olukorras idle in transaction. Need on need, kus avati tehing, tehti midagi ja mindi minema või lihtsalt jäi pidama, kadus koodi sisse.
• Ja teie, kui arendajad, peate oma koodi testima selliste olukordade tekkimise hetkel. See ei ole keeruline. See on kasulik kontroll. Te vältite paljusid 'laste' probleeme, mis on seotud pikemate tehingutega.

Nendel graafikutes soovisin näidata, kuidas tabel ja andmebaasi käitumine muutusid pärast seda, kui ma läksin selles konkreetses juhul VACUUM FULL tabelis. See pole mul tootmisserver.

Tabeli suurus naasis kohe normaalsesse tööolekusse paariks megabaitiks. See ei avaldanud keskmisele serveri vastusajale suurt mõju.

Kuid meie katsetatava tabeli puhul, kus uuendasime kontode jääke, näeme, et keskmine vastusaja andmete uuendamise päringus on vähenenud enne avariide taset. Protsessori ressursid, mida selle päringu täitmiseks tarbiti, on samuti langenud enne avariide taset. Ja paremal alumises graafikus näeme, et nüüd leiame kohe täpselt selle rea, mida vajame, ilma et peaksime läbi käima hulk surnud reasid, mis olid enne tabeli tihendamist. Ja keskmine päringute aeg on peaaegu samal tasemel püsinud. Aga siin on mul pigem minu seadme viga.

Sellega esimene lugu lõppes. See on kõige levinum. Ja see juhtub kõigil, sõltumata kliendi kogemusest või kui kvalifitseeritud programmistid seal on. Varem või hiljem see juhtub.

Teine lugu, kus jagame koormust ja optimeerime serveri ressursse.

• Me oleme juba kasvanud ja saanud tõsisteks mängijateks. Ja mõistame, et meil on replikatsioon ja oleks hea koormust tasakaalustada: kirjutades Meistrile ja lugedes replikatsioonilt. See olukord tekib tavaliselt, kui soovime koostada mõningaid aruandeid või ETL. Ja äri on selle üle väga rõõmus. Nad soovivad väga erinevaid aruandeid koos keeruka analüütikaga.
• Aruanded on mitu tundi, kuna keerukat analüüsi ei saa sekundite jooksul arvutada. Me, kui julged poisid, kirjutame koodi. Teeme rakenduses sisestusi, et me kirjutame Meistrile, aruandeid teeme replikatsioonilt.
• Jagame koormust.
• Kõik töötab suurepäraselt. Me oleme tublid.

Kuidas see olukord välja näeb? Konkreetselt nendel graafikutel lisasin ma veel replikatsiooniga tehingute kestuse. Kõik ülejäänud graafikud kuuluvad ainult Meistriserverile.

Raportide tabel minu käesoleval hetkel on kasvanud. Neid on rohkem. Näeme, et serveri keskmine reageerimisaeg on stabiilne. Näeme, et replika peal on meil pikaajaline tehing, mis kestab juba 2 tundi. Näeme rahulikku automaatvõrgu tööd, mis töötleb surnud ridu. Ja meie olukord on hea.

Konkreetselt katsetatava tabeli osas jätkame seal kontode jääkide värskendamist. Ja meil on samuti stabiilne reageerimisaeg päringutele, stabiilne ressursi tarbimine. Meie olukord on hea.

Kõik on hästi seni, kuni meie raportid ei hakka pihta replikeerimise konfliktiga. Ja nad põrkavad kokku pideva perioodilisusega.

Uurime internetti ja hakkame lugema, miks see juhtub. Ja leiame lahenduse.

Esimene lahendus on suurendada replikeerimise viivitust. Me teame, et meie raport töötab 3 tundi. Seame replikeerimise viivituseks 3 tundi. Käivitame kõik, kuid meil on siiski jätkuvalt probleeme, et raportid mõnikord katkestatakse.

Soovime, et kõik oleks täiuslik. Uurime edasi. Ja leiame internetist suurepärase seadistuse – hot_standby_feedback. Lülitame selle sisse. Hot_standby_feedback võimaldab meil peatada automaatvõrgu töö Masteris. Seega saame täielikult vabaneda replikeerimise konfliktidest. Ja meie raportid toimivad kõik hästi.

Aga mis toimub sel ajal meie Master-serveriga? Master-serveris on täielik katastroof. Praegu vaatame graafikuid, kui lülitasin sisse mõlemad seadistused. Ja näeme, et sessioon replika peal hakkas mingil moel mõjutama olukorda Master-serveris. Ta tõepoolest mõjutab, sest see peatas automaatvõrgu, mis puhastab surnud ridu. Meie tabeli suurus on taas tõusnud. Keskmine päringute täitmise aeg kogu andmebaasis on samuti tõusnud. Automaatvõrgud on natuke pingestunud.

Konkreetselt meie tabeli osas näeme, et andmete värskendamine on samuti tõusnud. Protsessori ressursi tarbimine on samuti väga palju suurenenud. Meie käest on tagasi sonteerunud suur hulk surnud ja kasutut rida. Ja vastuse aeg selle tabeli osas, tehingute arv on langenud.

Kuidas see välja näeks, kui me ei tea, millest ma seni rääkisin?

• Alustame probleemide otsimist. Kui me kohtasime probleeme esimese osaga, siis teame, et see võib olla seotud pika tehinguga ja uurime Masterit. Probleem on meil Masteris. See järelpõrutab. See kuumeneb, selle koormuse keskmine on saja ringis.
• Seal tõkked päringud, kuid me ei näe seal mingeid pikaajalisi tehinguid. Ja ei saa aru, mis toimub. Ei saa aru, kus otsida.
• Kontrollime serveri riistvara. Võib-olla on meil raid purunenud. Võib-olla on meil mälukaart tuksis. Midagi võib juhtuda. Aga ei, serverid on uued, kõik töötab suurepäraselt.
• Kõik jooksevad ringi: administraatorid, arendajad ja direktor. Miski ei aita.
• Ja mingil hetkel hakkab kõik ootamatult iseenesest taastuma.

Meil on replika ajal seal päring töötatud ja lahkunud. Saime aruande. Äri on endiselt rahul. Nagu näeme, on meie tabel taas kasvanud ja ei plaani väheneda. Seansside graafikul jätsin tüki sellest pikast tehingust replikast, et saaksite hinnata, kui kaua aega kulub, kuni olukord stabiliseerub.

Seanss lahkus. Ja alles mõne aja pärast tuleb server enam-vähem korras tagasi. Ja päringute keskmine vastusaeg Master-serveris normaliseerub. Sest lõpuks sai autovakumeerimine võimaluse surnud read puhastada ja märgistada. Ja ta hakkas oma tööd tegema. Ja nii kiiresti kui ta seda teeb, nii kiiresti me saame end korda.

Testitavas tabelis, kus me uuendame kontode jääke, näeme täiesti sama pilti. Keskmine konto uuendamise aeg normaliseerub ka järk-järgult. Protsessori tarbimisressursid vähenevad samuti. Ja tehingute arv sekundis naaseb normaali. Kuid taas ei normaliseeru see selliseks, nagu oli enne katastroofi.

Juhul, kui me saame ikka tootmisvõimekuse languse, nagu esimesel juhul, poolteise kuni kahe korra võrra, mõnikord isegi rohkem.

Me paistame, et oleme kõik õigesti teinud. Jaotame koormust. Riistvara ei seisa. Oleme arukalt jaganud päringud, aga ikkagi läks kõik halvasti.

• Kas on soovitatav mitte lubada hot_standby_feedback? Jah, seda ei soovitata ilma heade põhjusteta lubada. Sest see seade mõjutab otseselt Peaseeni ja peatab seal automaatse vakuumi töö. Kui te jätate selle lubatuks mingisuguses koopias ja unustate selle, võite tappa Peaseeni ning tekitada suuri probleeme rakenduses.
• Kas on soovitatav suurendada max_standby_streaming_delay? Jah, see on tõsi aruannete puhul. Kui teil on kolm tundi kestnud aruanne ja te ei soovi, et see kukuks replikatsioonide konfliktide tõttu, suurendage lihtsalt viivitust. Pikad aruanded ei vaja kunagi andmeid, mis on just nüüd andmebaasi jõudnud. Kui tegemist on kolm tundi kestva aruandega, siis käivitate selle vanade andmete ajavahemiku kohta. Ja kas teil on kolm tundi viivitust või kuus tundi viivitust – ei oma mingit tähtsust, aga te saate stabiilselt aruandeid ja ei koge nende äkilisi kukkumisi.
• Loomulikult tuleb kontrollida pikki sessioone koopiatel, eriti kui olete otsustanud lubada hot_standby_feedback koopial. Sest juhtuda võib ükskõik, mis. Andsite selle koopia arendajale, et ta testiks päringuid. Ta kirjutas meeletu päringu. Käivitas ja läks teed jooma, samas kui meie saime Peaseeni ülekoormuse. Või lubasime sinna vale rakenduse. Situatsioonid on mitmekesised. Sessioone koopiatel tuleb kontrollida sama hoolikalt nagu Peaseeni puhul.
• Ja kui teil on kiireid ja pikki päringuid koopiatel, siis on sel juhul parem koormuse jaotamiseks need jagada. See viitab streaming_delay'le. Kiirete jaoks on soovitatav kasutada ühte koopiat väikese replikatsiooniviivitusega. Pikemate aruannete päringute jaoks on soovitatav kasutada koopiat, mis võib viibida 6 tundi või kuni terve päeva. See on täiesti normaalne olukord.

Eemaldame tagajärjed ikka sama viisi kaudu:

• Otsime üles paisutatud tabelid.
• Ja surume need kokku sobivama tööriistaga, mis meile meeldib.

Teine lugu on selles lõppenud. Lähme kolmandasse lugu.

Küllaltki tavaline meie jaoks, kus me teeme migratsiooni.

• Iga tarkvaratoode kasvab. Nõudmised muutuvad. Me tahame alati areneda. Ja juhtub, et meil on vaja andmeid tabelis uuendada, just teha uuendust seoses meie migreerimisega uue funktsionaalsuse osas, mida rakendame meie arengu raames.
• Vana andmevorming ei sobi. Oletame, et pöördume nüüd teise tabeli poole, kus mul on need kontode tehingud. Ja oletame, et need olid rubla, kuid me otsustasime suurendada täpsust ja teha neid kopeekades. Selleks peame tegema uuenduse: tehingu summaarv korrutada sajaga.
• Kaasaegses maailmas kasutame andmebaasi versioonihalduse automatiseeritud vahendeid. Oletame, Liquibase. Kirjutame sinna meie migreerimise. Testime seda meie testandmebaasis. Kõik on suurepärane. Uuendus läheb läbi. See blokeerib töö mõneks ajaks, kuid saame värskendatud andmed. Ja saame sellel põhinedes uusi funktsioone käivitada. Oleme kõik testinud, kontrollinud. Kõik on kinnitatud.
• Teostasime kavandatud tööd, viisime läbi migreerimise.

Siin on teie ees esitatud migreerimine koos uuendusega. Kuna mul on tehingud kontode lõikes, oli tabeli suurus 15 GB. Ja kuna me uuendame iga rida, paisus tabel uuenduse tõttu kaks korda, sest me kirjutasime iga rea üle.

Migreerimise ajal ei saanud me sellega midagi teha, kuna kõik päringud sellele seisis järjekorras ja ootasid, kuni see uuendus lõppeb. Kuid siinkohal tahan juhtida teie tähelepanu vertikaalsel teljel olevatele numbritele. See tähendab, et meil oli keskmine päringu aeg enne migreerimist umbes 5 millisekundit ja protsessori koormus, mäludiskilt loetud blokeerimise operatsioonide arv on väiksem kui 7,5.

Viisime läbi migreerimise ja saime jälle probleeme.

Migreerimine läks edukalt, kuid:

• Vana funktsionaalsus hakkas töötama aeglasemalt.
• Tabel kasvas taas suuruse poolest.
• Serveri koormus on taas suurem kui oli.
• Ja loomulikult, seni kuni me veel tegeleme heade töödega, oleme seda veidi parandanud.

Ja see on jälle bloat, mis rikub meie elu.

Siin demonstreerin, et tabel, nagu ka eelnevatel juhtudel, ei kavatse naasta eelmistele suurustele. Serveri keskmine koormus tundub olevat vastuvõetav.

Kui me vaatame arve tabelit, siis näeme, et meie päringu keskmine aeg on kahekordistunud. Protsessori koormus ja mälus läbi vaadatud ridade arv on tõusnud üle 7,5, kuigi see oli alla. Protsessorite puhul tõusis see kaks korda, plokkoperatsioonide puhul aga 1,5 korda, st oleme saanud serveri jõudluse languse. Ja selle tagajärjel - meie rakenduse jõudluse languse. Samuti jäi kutsete arv ligikaudu samale tasemele.

Siinkohal on oluline mõista, kuidas õigesti selliseid migreerimise protsesse teha. Ja neid on oluline teha. Teeme neid üsna regulaarselt.

• Selliseid suures mahus migreerimisi ei tehta automaatselt. Need peavad alati olema kontrolleeritud.
• Kontroll peab olema teadliku inimese poolt. Kui teie meeskonnas on andmebaasi administraator (DBA), siis las teeb seda tema. See on tema töö. Kui ei, siis las teeb seda kõige kogenum inimene, kes teab, kuidas andmebaasidega töötada.
• Uus andmebaasi skeem, isegi kui uuendame ainult ühte veergu, valmistame me alati ette etappide kaupa, st enne, kui rakenduse uus versioon välja viiakse:
• Lisatakse uued väljad, kuhu salvestame just uuendatud andmed.
• Kandame andmed vanast väljast uude vähehaaval. Miks me seda teeme? Esiteks kontrollime me alati selle protsessi kulgu. Teame, et oleme juba üle kandnud teatud hulga ja meil on veel nii palju üle kandmata.
• Teiseks positiivne efekt on see, et iga sellise erandi vahel sulgeme tehingu, avame uue ja see võimaldab automaatvakumeerida tabelis, märgistades surnud read taaskasutamiseks.
• Ridade puhul, mis ilmuvad rakenduse töö käigus (meie vana rakendus töötab veel), lisame katse, mis salvestab uued väärtused uuteks väljadeks. Meie puhul - see on vana väärtuse korrutamine saja.
• Kui me oleme täiesti jonnakad ja tahame sama väli, siis kõigi migreerimiste lõppedes ja enne uue rakenduse versiooni väljalaskmist, lihtsalt muutame väljade nimed. Vanad saame mingi välja mõeldud nimeks, uued väljad muutume jälle vanadeks.
• Ja alles seejärel käivitame uue rakenduse versiooni.

Sellega me ei saa bloat'i ja meie jõudlus ei lange.

Selle lõppes kolmas lugu.

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

Ja nüüd pisut põhjalikumalt tööriistadest, millest ma esimeses loos rääkisin.

Enne kui bloat'i otsima hakkate, peate kindlasti paigaldama laienduse. pgstattuple.

Et te ei peaks päringute loomisega vaevama, oleme oma töös juba need päringud kirja pannud. Saate neid kasutada. Siin on esitatud kaks päringut.

• Esimene töötab üsna kaua, kuid see näitab teile bloat'i täpseid väärtusi tabelis.
• Teine töötab kiiremini ja on väga tõhus, kui on vaja kiiresti hinnata – kas tabelis on bloat või mitte. Ja peaksite aru saama, et Postgres'i tabelites on bloat alati. See on tema MVCC mudeli eripära.
• Ja 20% bloat on enamikul juhtudel tabelite jaoks normaalne. S.t. te ei pea muretsema ja seda tabelit kokku suruma.

Kuidas tuvastada tabelid, mis on meie jaoks paisunud, oleme juba aru saanud, sealhulgas, kui need on paisunud kasutud andmed.

Nüüd räägime bloat'i parandamisest:

• Kui meil on väike tabel ja head kettad, s.t. kui tabeli suurus on alla gigabaidi, on täiesti võimalik kasutada VACUUM FULL-i. See võtab eksklusiivse lukustuse tabelil paariks sekundiks ja see on okei, kuna see teeb kiiresti ja tõhusalt kõik vajalikud toimingud. Mida teeb VACUUM FULL? See võtab eksklusiivse lukustuse tabelil ja kirjutab elavad read uude tabelisse vanadest tabelitest. Ja lõpuks vahetab nad omavahel kohad. Vanad failid kustutab, uued asendab vanadega. Kuid oma töö ajal võtab ta eksklusiivse lukustuse tabelist. See tähendab, et te ei saa selle tabeliga mitte midagi teha: ei saa kirjutada, ei saa lugeda, ei saa muuta. Ja VACUUM FULL nõuab lisaruumi kettal, et andmeid salvestada.
• Järgmine tööriist pg_repack. Oma põhimõttelt on see väga sarnane VACUUM FULL-ile, kuna see kirjutab samuti andmed vanadest failidest uutesse ja asendab need tabelis. Kuid see ei võta alguses eksklusiivset lukustust tabelil, vaid võtab selle alles siis, kui tal on juba valmis andmed failidega asendamiseks. Temaga seotud kettaressursside nõuded on VACUUM FULL-iga sarnased. Teil on vaja kettal lisaruumi, mis võib mõnikord olla kriitiline, kui teil on terabaiti suuruseid tabeleid. Ja ta on ka üsna ressursinõudlik protsessorilt, kuna tegeleb aktiivselt sisendi-väljundi tööga.
• Kolmas utiliit on pgcompacttable. Ta on ressursse säästvam, kuna töötab natuke erinevatel põhimõtetel. Pgcompacttable peamine idee on see, et see uuendustega viib kõik elavad read tabeli algusesse. Ja siis käivitab selle tabeli ülevaatuse, kuna me teame, et meil on alguses elavad ja lõpus surnud read. Ülevaatus lõikab selle saba ära, st see ei vaja palju täiendavat kettaruumi. Ja lisaks on seda veel võimalik ressursside osas vähendada.

Tööriistadega on kõik.

Kui teema bloat tundub teile huvitav ja soovite sügavamale minna, siis siin on mõned kasulikud lingid:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres – see on minu kolleegi ettekande pealkiri. See on üldine ülevaade sellest, kuhu Postgres'is ruum kaob tema töö ja elu jooksul. Seal on väga suur ja detailselt tehniline osa andmebaasihalduritele bloat'i kohta.
• https://github.com/dataegret/pg-utils – see on link meie hoidlasse, kus hoiame hulga kasulikke skripte andmebaasi seisundi kontrollimiseks. Seal leiate skripte bloat'i otsimiseks.
• Kolmas ja neljas linkide kohta, mis aitavad teil tabelite suurust vähendada.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html – see on minu kolleegi postitus. Seal käsitleb ta üsna põhjalikult ja tehniliselt bloat'i just haldurite tasemel.

Ma püüdsin siin rohkem näidata hirmutust arendajatele, kuna nad on meie andmebaaside otsesed kliendid ja peavad mõistma, millised on teod ja nende tagajärjed. Loodan, et mul õnnestus. Aitäh tähelepanu eest!

Küsimused

Aitäh ettekande eest! Te rääkisite, kuidas probleeme tuvastada. Kuidas neid ennetada? Mul oli olukord, kus päringud jäid seisma mitte ainult seetõttu, et need kasutasid mõnda välist teenust. Seal olid lihtsalt mõned tobedad liitmise päringud. Seal oli mõni üsna kahjutu mikropäring, mis jäi päevaks seisma ja seejärel hakkas toimetama mingit jama. See on väga sarnane sellele, mida te kirjeldasite. Kuidas seda jälgida? Kas peaksin pidevalt vaatama, milline päring on seisma jäänud? Kuidas seda ennetada?

Sel juhul – see on ülesanne teie ettevõtte halduritele, mitte tingimata DBA-dele.

Ma olen haldur.

PostgreSQL'is on selline vaade nagu pg_stat_activity, kus kuvatakse seisma jäänud päringud. Ja te saate näha, kui kaua need seal olnud on.

Kas ma pean iga 5 minuti tagant sisse logima ja vaatama?

Seadke cron töö ja kontrollige. Kui teil on pikk päring, saatke kiri ja kõik. T. e. teil ei ole vaja silmadega vaadata, see on automatiseeritav. Te saate kirja, millele reageerite. Võite ka automaatselt vastata.

Kas on ilmsed põhjused, miks see juhtub?

Mõned neist olen ära nimetanud. Teised on keerulisemad näited. Ja seal võib jutt pikaks minna.

Aitäh ettekande eest! Soovin täpsustada utiliiti pg_repack. Kui see ei tee eksklusiivset lukku, siis...

See teeb eksklusiivset lukku.

… siis ma võin potentsiaalselt andmeid kaotada. Minu rakendus ei tohi sel ajal midagi kirjutada?

Ei, see töötab rahulikult tabeliga, t. e. pg_repack tõstab esimesena üles kõik elavread, mis seal on. Loomulikult toimub seal mingisugune kirjutamine tabelisse. Ta lihtsalt lisab selle saba juurde.

T. e. ta siiski teeb lõpus?

Lõpus võtab ta eksklusiivse lukustuse, et neid faile omavahel vahetada.

Kas see on kiirem kui VACUUM FULL?

VACUUM FULL, kui see käivitub, võtab kohe eksklusiivse lukustuse. Ja seni, kuni ta kõike ei tee, ei vabasta ta seda. Ja pg_repack võtab eksklusiivse lukustuse ainult failide asendamise hetkel. Sel ajal te ei saa sinna kirjutada, kuid andmed ei kao, kõik on korras.

Tere! Rääkisite automaatse vakumeerimise tööst. Seal oli graafik punaste, kollaste ja roheliste rakkudega. T. e. kollased – ta märkis need kustutatuks. Ja seetõttu võib neisse midagi uut kirjutada?

Jah. Postgres ei kustuta ridu. Tal on selline eripära. Kui me rida uuendame, märgime vana kustutatuks. Seal tuleb id tehingu, mis selle rida muutis, ja me kirjutame uue rea. Ja meil on sessioonid, mis potentsiaalselt võivad neid lugeda. Teatud hetkel muutuvad need väga vanaks. Ja automaatse vakumeerimise eesmärk on see, et ta läbib need read ja märgib need kui mittevajalikud. Ja sinna saab andmeid taas kirjutada.

Sain aru. Kuid küsimus ei ole täiesti selles. Ma ei lõpetanud. Oletame, et meil on tabel. Seal on muutuva suurusega väljad. Ja kui ma püüan midagi uut sisestada, siis see ei pruugi lihtsalt vanasse rakku mahtuda.

Ei, seal igal juhul uuendatakse kogu rida. Postgres'el on kaks andmeid salvestamise mudelit. See valib andmete tüübi järgi. On andmeid, mis salvestatakse otse tabelisse, ja on ka tos-andmed. Need on suured andmemahtud: tekst, json. Need salvestatakse eraldi tabelitesse. Ja nende tabelitega on sama lugu bloat'iga, s.t. kõik on sama. Lihtsalt on need eraldi välja tõstetud.

Aitäh ettekande eest! Kui mõistlik on kasutada päringute kestuse piiramiseks statement timeout'i?

See on väga vastuvõetav. Me kasutame seda igal pool. Kuna meil pole oma teenuseid, pakume eemalt tuge, on klientuur üsna mitmekesine. Ja kõik on selle peale täiesti rahul. S.t. meil on ülesanded cron'is, mis kontrollivad seda. Lihtsalt kliendiga lepime kokku seansside kestuse, millest varem me ei katkesta. See võib olla minut, see võib olla 10 minutit. See sõltub andmebaasi koormusest ja selle eesmärgist. Kuid kõik kasutavad pg_stat_activity't.

Aitäh ettekande eest! Püüan teie ettekannet oma rakendustele kohandada. Tundub, et me alustame kõikjal tehingut, lõpetame selle selgelt. Kui mingi exception toimub, siis rollback ikkagi toimub. Ja siis ma mõtlesin. Sest tehing võib alata ka mitte selgelt. See on ilmselt vihje tüdrukule. Kui ma lihtsalt uuendan kirjet, kas tehing algab PostgreSQL'is ja lõpetatakse alles siis, kui ühendus katkeb?

Kui räägite praegu rakenduse tasemest, siis see sõltub kasutatavast draiverist, sellest ORM'ist, mida kasutatakse. Seal on palju seadeid. Kui teil on auto commit sisse lülitatud, siis tehing algab kohe ja sulgub kohe.

S.t. see sulgub kohe pärast uuendamist?

See sõltub seadetest. Ühe seade, mida ma mainisin. See on auto commit on. See on üsna levinud. Kui see on sisse lülitatud, avatakse tehing ja suletakse. Kui te ei ole selgelt öelnud 'start transaction' ja 'end transaction', vaid lihtsalt käivitasite sessioonis päringu.

Tere! Aitäh ettekande eest! Kujutame ette, et meil on andmebaas, mis paisub ja paisub ja siin serveris lõpeb ruum. Kas on mingeid tööriistu, et seda olukorda parandada?

Serveri ruumi tuleks tõepoolest jälgida.

Näiteks DBA läks teed jooma, oli puhkuse ajal jne.

Kui failisüsteem luuakse, siis seal luuakse vähemalt mingit reserveeritud ruumi, kuhu andmeid ei kirjutata.

Aga kui kõik on täiesti tühi?

Seal nimetatakse seda reserveeritud ruumiks, st selle saab vabastada ja sõltuvalt sellest, kui suureks see loodud on, saate vabade ruutmeetrite arvu. Vaikimisi ma ei tea, kui palju seal on. Teises olukorras tuleb tarnida ketas, et teil oleks ruumi taastamistegevuse läbiviimiseks. Võite kustutada mõne tabeli, mis on teile garanteeritult üleliigne.

Teisi tööriistu ei ole?

See on alati käsitöö. Ja kohapeal tuvastatakse, mida teha, kuna andmed on kriitilised ja on mitte-kriitilised. Iga andmebaasi ja rakenduse jaoks, mis seda kasutab, sõltub see ärist. See otsustatakse alati kohapeal.

Aitäh ettekande eest! Mul on kaks küsimust. Esiteks, te tutvustasite slaide, kus näidati, et kui tehingud hanguvad, suureneb nii tabeli ruumi maht kui ka indeksi suurus. Ja seejärel ettekandes oli palju utiliite, mis paketivad tabelit. Mis toimub indeksi puhul?

Need paketivad ka neid.

Aga vacuum ei mõjuta indeksi?

Mõned töötavad indeksi kallal. Näiteks pg_rapack, pgcompacttable. Vacuum loob indekseid uuesti, mõjutab neid. VACUUM FULLi olemus on see, et kõik uuesti kirjutada, st see töötab kõigi kallal.

Ja teine küsimus. Ma ei saanud aru, miks aruanded replikates nii palju sõltuvad ise replikatsioonist. Tundus, et aruanded on lugemine ja replikatsioon on kirjutamine.

Kus tekib replikatsiooni konflikt? Meil on Master, kus toimuvad protsessid. Meil toimub automaatne vacuum. Automaatne vacuum, mis see tegelikult teeb? See eemaldab mõned vanad read. Kui meil samal ajal toimub replikas päring, mis loeb neid vanu ridu, ja Masteris on juhtunud, et automaatne vacuum on need read võimalike kirjutamiseks märkinud, siis me need uuesti kirjutame. Ja me saame andmepaketi ajal, kui peame uuesti kirjutama need read, mis on replikas päringule vajalikud, siis replikatsiooni protsess ootab seda seadistatud ajavahemikku. Seejärel otsustab PostgreSQL, mis on tema jaoks olulisem. Ja replikatsioon on tema jaoks olulisem kui päring ja ta katkestab päringu, et teha need muudatused replikas.

Andrej, mul on küsimus. Need imelised graafikud, mida te näitasite esitluse ajal, on teie tööriista tulemus? Millega graafikud koostati?

See on teenus Okmeter.

Kas see on kaubanduslik toode?

Jah. See on kaubanduslik toode.

Allikas: habr.com