Tüüpilised vead rakendustes, mis põhjustavad postgreSQL-is bloat'i. Andrei Sõlnikov

Pakun tutvuda 2016. aasta alguses Andrei Sõlnikovi esitatud ettekande "Tüüpilised vead rakendustes, mis viivad postgreSQL-is bloat'ini" kokkuvõttega.

Selles ettekandes käsitlen peamisi vigu rakendustes, mis tekivad rakenduse projekteerimise ja koodi kirjutamise etapis. Vaatan vaid neid vigu, mis viivad postgreSQL-is bloat'ini. Tüüpiliselt on see teie süsteemi üldise jõudluse lõpuga tegelemise algus, ehkki esialgu ei olnud selleks mingeid märke näha.

Tere kõigile! See ettekande ei ole nii tehniline nagu minu kolleegi eelmine. See ettekande on suunatud peamiselt tagasisüsteemide arendajatele, kuna meil on piisavalt suur hulk kliente. Ja kõik nad teevad samu vigu. Nendest räägin ma teile. Selgitan, millistele halbadest tagajärgedest need vead viivad.

Miks tehakse vigu? Vigu tehakse kahe põhjuse tõttu: lootuses, et äkki läheb läbi, ja teadmatusest teatud mehhanismide osas, mis toimuvad andmebaasi ja rakenduse vahel, aga ka andmebaasis endas.

Ma toon teile kolm näidet kohutavatest piltidest, mis näitavad, kuidas kõik halvasti läks. Lühidalt räägin mehhanismist, mis seal toimub. Ja kuidas nendega tegeleda, kui need juhtuvad, ning milliseid ennetusmeetodeid kasutada vigade vältimiseks. Räägin abivahenditest ja jagan kasulikke linke.

Kasutasin testandmebaasi, kus mul oli kaks tabelit. Üks tabel klientide arvetega, teine nende arvetega seotud tehingutega. Ja mingite ajavahemike järel uuendame nende arvete jääke.

Algandmed tabelist: see on piisavalt väike, 2 MB. Andmebaasi vastuse aeg ja konkreetne tabeli vastuse aeg on samuti väga hea. Ja piisavalt suur koormus – 2000 tehingut sekundis selle tabeli kohta.

Ja selle ettekande kaudu näitan teile graafikuid, et oleks selgelt aru saada, mis toimub. Alati on kaks slaidi graafikutega. Esimene slaid – see, mis toimub serveris üldiselt.

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

Serveri keskmine vastusaeg on samuti stabiilne ja madal. See on parem ülemine diagramm.

Vasak alumine diagramm näitab pikimaid tehinguid. Me näeme, et tehingud viiakse kiiresti lõpule. Ja automaatne vaakum ei tööta veel siin, kuna see oli algtest. Edasi hakkab see tööle ja on meile kasulik.

Teine slaid on alati pühendatud katsetatavale tabelile. Antud juhul uuendame pidevalt kliendi kontode jääke. Ja me näeme, et keskmine vastusaeg uuenduste operatsioonide jaoks on piisavalt hea, alla ühe millisekundi. Näeme, et protsessori ressursid (see on parem ülemine diagramm) tarbitakse samuti ühtlaselt ja on piisavalt väikesed.

Parem alumine diagramm näitab, kui palju operatiiv- ja kettamälu me otsime meie vajaliku rea leidmiseks, enne kui seda uuendame. Ja tehingute arv tabelis – 2000 sekundis, nagu ma alguses ütlesin.

Ja nüüd juhtub meil tragöödia. Mikski pärast tekib pikk unustatud tehing. Põhjused on tavaliselt kõik banaalsed:

• Üks levinumaid olukordi on see, et rakenduse koodis hakkame välisteenusega suhtlema ning see teenus ei vasta meile. See tähendab, et oleme avanud tehingu, teinud muudatuse andmebaasis ja läinud rakendusest posti vaatama või mõnda teise teenusesse meie infrastruktuuris, ning see ei vasta mingil põhjusel. Ja meil on sessioon, mis on seiskunud seisundis – teadmata, millal see lahendust leiab.
• Teine olukord on see, et meie koodis on mingil põhjusel toimunud erand (exception). Ja me ei ole erandi käsitlemisel tehingu sulgemist töötlenud. Ja me saime seiskunud sessiooni avatud tehinguga.
• Ja viimane – see on samuti üsna levinud juhtum. See on kehva kvaliteediga kood. Mõned raamistikud avavad tehingu, see jääb seisma ja te võite oma rakenduses mitte teada, et see on seiskunud.

Mida sellised asjad endaga kaasa toovad?

Meie tabelid ja indeksid hakkavad järsult paisuma. See on just see bloat efekt. Andmebaasi jaoks väljendub see selles, et andmebaasi vastusaeg suureneb järsult ja andmebaasi serveri koormus tõuseb. Lõppkokkuvõttes kannatab rakendus. Kui varem kulus koodis andmebaasi päringule 10 millisekundit ja oma loogikale 10 millisekundit, siis funktsioon töötas 20 millisekundit. Nüüd on olukord palju kehvem.

Vaadakem siis, mis juhtub. Vasaku alumise graafiku järgi on meil pikk ja aeglane tehing. Ja kui vaatame vasakus ülemises graafikus, näeme, et tabeli suurus on kahe megabaidi pealt järsult tõusnud 300 megabaidini. Samas tabeli andmete hulk ei ole muutunud, st seal on piisavalt palju prügi.

Üldine olukord serveri keskmise vastusaaja osas on samuti muutunud mitme korra võrra. See tähendab, et kõik serveri päringud hakkasid tõsiselt langema. Samuti käivitusid Postgresis sisemised protsessid nagu autovakuu, mis üritavad midagi teha ja tarbivad ressursse.

Mis toimub meie tabeliga? Sama asi. Tabeli keskmine vastusaeg on tõusnud mitu korda. Kui rääkida kasutatud ressurssidest, siis näeme, et protsessori koormus on oluliselt suurenenud. See on paremal ülemisel graafikul. Koormus on suurenenud, kuna protsessor peab läbi kammima hulgaliselt kasutu ridu, et leida üks vajalik. See on paremal alumisel graafikul. Tulemusena on meie sekundis tehtud päringute arv langenud oluliselt, kuna andmebaas ei jõua sama palju päringutest töötleda.

Me peame tagasi elama hakkama. Uurime internetist, et pikad tehingud põhjustavad probleemi. Leiame ja lõpetame selle tehingu. Ja kõik muutub normaalseks. Kõik töötab nagu peab.

Me rahunesime, kuid mõne aja pärast hakkame märkama, et rakendus ei tööta enam samamoodi nagu enne avarii. Päringud töötlevad siiski aeglasemalt, oluliselt aeglasemalt. Minu näite puhul on see poolteist kuni kaks korda aeglasem. Serveri koormus on samuti kõrgem kui see oli enne avariid.

Küsimus on: „Mis juhtub andmebaasi sel hetkel?“. Andmebaasis toimub järgmine olukord. Tehingute graafikul näete, et see on peatanud ja seal tõepoolest ei ole pikki tehinguid. Kuid tabeli suurused on hädaolukorra ajal oluliselt kasvanud. Ja sellest ajast alates ei ole nad vähenenud. Andmebaasi keskmine aeg on stabiliseerunud. Ja vastused näivad liikuvat adekvaatselt meie jaoks vastuvõetava kiiruseni. Automaatne vakumeerimine on muutunud aktiivsemaks ja on hakanud tabeliga midagi ette võtma, sest tal on vaja ümber töötada suurem hulk andmeid.

Konkreetse tabeli osas, kus me muudame jääke: päringu vastamisaeg on nagu tagasi normaali. Kuid tegelikult on see poolteist korda kõrgem.

Ja protsessorikoormuse osas näeme, et protsessori koormus ei ole naasnud vajalikule tasemele enne hädaolukorda. Ja põhjused peituvad seal paremas alanurgas oleva graafiku juures. Näha on, et seal toimub mingisugune mälu ületamine. See tähendab, et vajaliku rea leidmiseks kulutame andmebaasi serveri ressursse kasutu andmete läbivaatamisele. Tehingute arv sekundis on stabiliseerunud.

Üldiselt on olukord hea, kuid see on halvenenud võrreldes varasemaga. Andmebaasi selge degradatsioon, mis tuleneb meie rakendusest, mis töötab selle andmebaasiga.

Ja et aru saada, mis seal toimub, kui te pole eelmisel ettekandel olnud, siis veidi teooriat. Teooria sisemisest protsessist. Miks on automaatne vaakum ja mida see teeb?

Lühidalt arusaamiseks. Teatud hetkel on meil tabel. Tabelis on read. Need read võivad olla aktiivsed, elusad, meie jaoks hetkel vajalikud. Pildil on need märgitud rohelise värviga. Ja on ka surnud read, mis on juba töötanud, on uuendatud ja mille kohta on ilmunud uued kirjed. Need on juba tähistatud, et nad pole andmebaasi jaoks enam huvitavad. Aga nad jäävad tabelisse PostgreSQL eripära tõttu.

Miks on autovakuum vajalik? Autovakuum jõuab mingil hetkel andmebaasi, pöördub selle poole ja küsib: "Palun anna mulle kõige vanema tehingu ID, mis on praegu andmebaasis avatud." Andmebaas tagastab selle ID. Autovakuum, tuginedes sellele, läbib tabelis olemasolevad read. Kui ta näeb, et mõni rida on muutunud palju vanemate tehingute tõttu, on tal õigus need markeerida ridadena, mida saame tulevikus taaskasutada, kirjutades sinna uusi andmeid. See on taustaprotsess.

Selle aja jooksul jätkame andmebaasiga töötamist, teeme tabelis mingeid muudatusi. Ja nendele ridadele, mida saame taaskasutada, kirjutame uusi andmeid. Niimoodi toimub meil ringkäik, st pidevalt tekivad sinna vanad surnud read, asemele kirjutame uued read, mida vajame. See on PostgreSQL-i töö normaalne seisund.

Mis juhtus õnnetuse ajal? Kuidas see protsess seal toimus?

Meil oli tabel, kus olid mõned elavad ja mõned surnud read. Siis tuli automaatne vaakum. Ta küsis andmebaasilt, 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 teie andmebaasi koormus. Ning ta asus otsima ridu, mida ta saaks märgistada taaskasutatavateks, kuid ei leidnud meie tabelist selliseid rive.

Aga samal ajal jätkame me tabeliga töötamist. Teeme seal midagi, uuendame ja muudame andmeid. Mis aga andmebaasile sel ajal jääb? Tal ei jää muud üle, kui kirjutada uued read olemasoleva tabeli lõppu. Seega hakkab meie tabeli suurus paisuma.

Tegelikkuses on meile tööks vajalikud rohelised read. Kuid sellise probleemi ajal on meil olukord, kus roheliste ridade protsent on kogu tabeli mahus äärmiselt madal.

Kui me teeme 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, mida täidavad kasutud andmed, nimetatakse „bloat”, mis veel sööb meie ketta ruumi. Kas mäletate, et oli 2 MB, nüüd on 300 MB? Nüüd asendage megabaitid gigabaidiga ja te kaotate oma kettaressursid üsna kiiresti.

Millised on meie jaoks tagajärjed?

• Minu näites kasvas tabel ja indeks 150 korda. Mõnel meie kliendil on olnud isegi halvemad juhtumid, kus kettaruumi hakkas lihtsalt nappima.
• Tabelite suurus iseenesest kunagi ei vähene. Automaatne tühjendamine võib mõnel juhul lõigata tabeli sabanema, kui seal on ainult surnud read. Kuid kuna toimub pidev rotatsioon, võib üks roheline rida lõpuks kinni jääda ja mitte uuenduda, samas kui kõik teised kirjutatakse kuskil tabeli algusesse. Kuid see on niivõrd ebatõenäoline sündmus, et te ei peaks lootma, et teie tabel iseenesest väheneb.
• Andmebaas peab läbi käima kogu selle kasutu rivi. See kulutab meie diskiruume, protsessorite ressursse ja energiat.
• See mõjutab meie rakendust otseselt, sest kui alguses kulus meil päringule 10 millisekundit ja meie koodile 10 millisekundit, siis avarii ajal hakkasime päringule kulutama sekundi ja koodile 10 millisekundit. See tähendab, et rakenduse jõudlus on langenud korra võrra. Ja kui avarii lahendus leiti, kulub meil nüüd 20 millisekundit päringule ja 10 millisekundit koodile. See tähendab, et oleme ikkagi poole vähem efektiivsed. Ja see kõik juhtus ühe tehingu tõttu, mis kukkus kinni, mis võib-olla on ka meie süü.
• Ja küsimus on: 'Kuidas kõik tagasi tuua?', et meil oleks kõik korras ja päringud töötaksid taas sama kiiresti kui enne avariid.

Selleks on kindel töötsükkel, mis tuleb läbi viia.

Esimene asi, mida peame tegema, on leida probleemsed tabelid, mis on paisunud. Me mõistame, et teatud tabelite kirjutamine toimub aktiivsemalt, teistel vähem aktiivselt. Ja selleks kasutatakse laiendust. pgstattuple. Paigaldades selle laienduse, saate esitada päringuid, mis aitavad leida tabeleid, mis on piisavalt paisunud.

Pärast nende tabelite leidmist tuleb need tihendada. Selleks on juba olemas tööriistad. Meie ettevõttes kasutame kolme tööriista. Esimene on sisseehitatud VACUUM FULL. See on karm, ranged ja halastamatu, kuid mõnikord on see väga kasulik. Pg_repack ja pgcompacttable – on kolmanda osapoole utiliidid tabelite tihendamiseks. Ja need on andmebaasi suhtes õrnemad.

Nende kasutamine sõltub sellest, mis on teile mugavam. Kuid sellest räägin ma lõpuks. Peamine on see, et on kolm tööriista. On, mida valida.

Pärast seda, kui oleme kõik korda saanud ja veendunud, et kõik on hästi, peame teadma, kuidas selliseid olukordi tulevikus vältida:

• Seda on piisavalt lihtne vältida. Tuleb jälgida sessioonide kestvust Meistriserveris. Eriti ohtlikud on sessioonid, mis on idle in transaction. Need on need, mis avasid tehingu, tegid midagi ja lahkusid või lihtsalt jäid seisma, kadusid koodi sisse.
• Arendajatele on oluline testida koodi, kui esinevad sellised olukorrad. Seda ei ole keeruline teha. See on kasulik kontroll, mis aitab vältida paljusid "lapsepõlve" probleeme, mis on seotud pikaajaliste tehingutega.

Nendel graafikutel soovisin näidata, kuidas tabel ja andmebaasi käitumine muutusid pärast seda, kui kasutasin antud juhul VACUUM FULL'i tabeli peal. See ei ole tootmiskeskkond.

Tabeli suurus naasis kiiresti normaalsesse tööseisundisse paar megabaiti. See ei mõjutanud serveri keskmist vastusaega märkimisväärselt.

Kuid meie katsetatava tabeli osas, kus me uuendasime kontode jääke, näeme, et andmete uuendamise päringute keskmine vastamisaeg on vähenenud hädaolukorra eelsetele tasemetele. Protsessorile rakendatud ressursid selle päringu täitmiseks on samuti langenud hädaolukorra eelsetele tasemetele. Ja parempoolne alumine graafik näitab, et nüüd leiame otse selle rea, mida vajame, ilma et peaksime läbima hulk surmaga lõppenud rease, mis olid enne tabeli kokkusurumist. Ja keskmine päringute aeg on umbes samal tasemel püsinud. Kuid mul on siin pigem minu riistvara talitlushäire.

Selleks esimesed lood on lõppenud. See on kõige levinum ja juhtub kõigiga, sõltumata kliendi kogemusest, kui oskuslikud on programmeerijad. Varem või hiljem juhtub see.

Teine lugu, kus me jaotame koormust ja optimeerime serveri ressursse

• Oleme juba kasvanud ja oleme tõsised tegijad. Mõistame, et meil on replika ja oleks hea jaotada koormust: kirjutada Master'il ja lugeda replikalt. See olukord tekib tavaliselt siis, kui soovime koostada aruandeid või ETL-i. Ja äri on sellest väga rõõmus. Ta soovib väga erinevaid aruandeid koos keeruka analüüsiga.
• Aruanded võtavad palju tunde, sest keerulist analüüsi ei saa arvutada millisekunditega. Me, nagu tublid tegijad, kirjutame koodi. Teeme rakenduses sisestusi, et kandu oleks Master'il, aruandeid täidame replikal.
• Jaotame koormust.
• Kõik töötab suurepäraselt. Me oleme tublid.

Kuidas see situatsioon välja näeb? Konkreetselt nende graafikute põhjal lisasin ma ka tehingute kestvuse replikalt. Kõik teised graafikud kuuluvad ainult Master-serverile.

Aruannete tabel on selleks ajaks mul kasvanud. Need on muutunud rohkemaks. Näeme, et serveri keskmine vastamisaeg on stabiilne. Näeme, et replikal on pikaajaline tehing, mis kestab 2 tundi. Näeme rahulikku automaatset tühjendamist, mis töötleb surnud ridu. Ja kõik on meil hästi.

Konkreetse katse tabeli osas jätkame saldo värskendamist kontodel. Samuti on meil stabiilne vastuse aeg päringule ja stabiilne ressursikasutus. Meil on kõik hästi.

Kõik on hästi, kuni meie raportid hakkavad tulistama replikatsiooni konflikti tõttu. Ja need tulistuvad pideva perioodilisusega.

Me hõivame interneti ja hakkame lugema, miks see juhtub. Ja leiame lahenduse.

Esimene lahendus on suurendada replikatsiooni viivitust. Me teame, et meie raport töötab 3 tundi. Seame replikatsiooni viivituseks 3 tundi. Käivitame kõik, kuid meil jätkuvad probleemid, et raportid mõnikord tulistuvad.

Me soovime, et kõik oleks ideaalne. Jätkame uurimist. Ja leiame internetis suurepärase seadistuse – hot_standby_feedback. Lülitame selle sisse. Hot_standby_feedback võimaldab meil peatada autovakumeerimise töö Meistris. Nii vabaneme täielikult replikatsiooni konfliktidest. Ja meil on kõik raportitega hästi.

Aga mis siis juhtub meie Peaserveriga? Peaserveriga on meil totaalne häda. Praegu jälgime graafikuid, kui aktiveerisin mõlemad seaded. Ja me näeme, et replika seanss on mingil viisil hakanud mõjutama olukorda Peaserveris. See tõesti mõjutab, sest see on peatama pannud autovakuumi, mis puhastab surnud read. Meie tabeli suurus on taas taevasse tõusnud. Keskmine päringute täitmise aeg kogu andmebaasis on samuti järsult tõusnud. Autovakuumid on natuke üle koormatud.

Konkreetse tabeli osas näeme, et andmete värskendamise aeg on samuti järsult tõusnud. Protsessori ressursikasutuse tarbimine on samuti väga suurenenud. Me uuesti suuname suurt hulka surnud, kasutu read. Ja selle tabeli vastamisaeg, tehingute arv on langenud.

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

• Alustame probleemide otsimist. Kui me oleme esimeses osas probleemidega kokku puutunud, teame, et see võib tuleneda pikaajalisest tehingust ning vaatame Masti. Probleem on meil Masti juures. See on üle koormatud. See kuumeneb, Load Average on lähenenud sajale.
• Küsimused seal tunnivad, kuid seal ei näe me mingeid pikki tehinguid. Ja ei saa aru, milles on asi. Ei saa aru, kust otsida.
• Kontrollime serveri riistvara. Võib-olla on meil raid kokku kukkunud. Võib-olla on mäluplokk läbi kukkunud. Mis iganes võib juhtuda. Kuid ei, serverid on uued, kõik töötab suurepäraselt.
• Kõik jooksevad: administraatorid, arendajad ja direktor. Miski ei aita.
• Ja mingil hetkel hakkab kõik ootamatult iseenesest paranema.

Replikas töötas meil sel ajal päring ja läks. Saime aruande. Ärikliendil on endiselt hea meel. Nagu näeme, on meie tabel taas kasvanud ja ei plaani väheneda. Sessioonide graafikul olen jätnud tükikese sellest pikast tehingust replikast, et saaksite hinnata, kui kaua olukorra stabiliseerumine aega võtab.

Seans on kadunud. Ja alles mõne aja pärast hakkab server enam-vähem korda saama. Ja keskmine vastamisaeg päringutele Master-serveris stabiliseerub. Sest lõpuks on automaatne vakumeerimine saanud võimaluse surnud read puhastada ja märgistada. Ja ta on hakanud oma tööd tegema. Nii kiiresti, kui ta seda teeb, tuleme me korda.

Katsetataval tabelil, kus uuendame saldoid, näeme täpselt sama pilti. Keskmine saldo uuendamise aeg normaliseerub samuti järk-järgult. Protsessori poolt tarbitavad ressursid vähenevad samuti. Ja tehingute arv sekundis naaseb normaali. Kuid normaali mitte sellisena, nagu see oli enne õnnetust.

Igal juhul saame me jõudluses languse nagu esimesel korral, poolteise kuni kahe korra võrra, vahel isegi rohkem.

Me näisime tegevat kõik õigesti. Jagasime koormust. Seade ei seisa. Targalt jagasime päringud, kuid ikkagi läks kõik halvasti.

• Kas hot_standby_feedback'i mitte lubada? Jah, seda ei soovitata lubada ilma olulise põhjuseta. Sest see reguleerija mõjutab otseselt Meistri serverit ja peatab seal automaatvakumimist. Kui te lubate seda mõnes replikas ja unustate selle, võite tappa Meistri ja saada suuri probleeme rakendusega.
• Kas max_standby_streaming_delay'd suurendada? Jah, aruannete puhul – see on nii. Kui teil on kolmekordne aruanne ja te ei soovi, et see probleemide tõttu kokku kukuks, lihtsalt suurendage viivitust. Pikaajaline aruanne ei vaja kunagi andmeid, mis on just praegu andmebaasi tulnud. Kui see on kolmekordne, tähendab see, et käitate seda mõne vanema andmeperioodi jaoks. Ja kas teie jaoks on kolm või kuus tundi viivitust – see ei mängi mingit rolli, kuid nii saate stabiilselt aruandeid ja ei pea nende kadumise pärast muretsema.
• Muidugi on oluline jälgida pikki sessioone replikates, eriti kui olete otsustanud lubada hot_standby_feedback replikas. Sest võib juhtuda ükskõik mis. Oleme andnud selle replikatsiooni arendajale, et ta testiks päringute kohta. Ta kirjutas pöörase päringu. Käivitas selle ja läks teed juua, ning meie saime kokku pandud Masteri. Või me lubasime sinna vale rakenduse. Olukordi on palju. Sessioone replikates tuleb jälgida sama põhjalikult kui Masteris.
• Ja kui teil on replikate seas kiireid ja pikka aega kesta päringuid, siis on sel juhul parem laadija jaotamiseks need jagada. See viitab streaming_delay'le. Kiirete jaoks tuleks omada ühte replikat väikese replikeerimise viivitusega. Pikkade aruandlike päringute jaoks tuleks omada replikat, mis võib jääda 6 tunni või päeva võrra maha. See on täiesti normaalne olukord.

Eemaldame tagajärjed ikka sama meetodiga:

• Leidke paisutatud tabelid.
• Ja surume kokku kõige sobivama tööriistaga, mis meile sobib.

Teine lugu sai siin otsa. Liigume kolmanda loo juurde.

Ka see on meile üsna tavaline, kus me teeme migreerimise.

• Iga tarkvara areneb. Nõuded tema suhtes muutuvad. Me tahame igal juhul areneda. Ja juhtub, et peame andmeid tabelis uuendama, just viima läbi värskenduse meie migratsiooni plaanis uue funktsionaalsuse jaoks, mille me oma arendustegevuses juurutame.
• Vana andmeformaat ei sobi. Ütleme, et vaatame teisele tabelile, kus mul on tehingud nende kontode osas. Ja ütleme, et need olid rublades, kuid oleme otsustanud täpsust tõsta ja teha kopikates. Selleks peame tegema uuenduse: tehingu summa väli tuleb korrutada sajaga.
• Kaasaegses maailmas kasutame automatiseeritud andmebaasi versioonikontrolli vahendeid. Ütleme, et Liquibase. Kirjutame sinna meie migratsiooni. Testime seda meie testandmebaasis. Kõik läheb hästi. Uuendus toimub. See blokeerib töö mõneks ajaks, aga saame uuendatud andmed. Ja saame käivitada sellel meie uue funktsionaalsuse. Kõik on testitud, kontrollitud. Kõik on kinnitatud.
• Teostasime plaanilised tööd, viisime läbi migratsiooni.

Siin on migreerimise värskendus, mida teie ees esitatakse. Kuna need on minu arvelduse operatsioonid, oli tabeli maht 15 GB. Ja kuna me uuendame iga rida, suurendasime tabeli suurust kahekordseks, sest kirjutasime iga rea üle.

Migreerimise ajal ei saanud me selle tabeliga midagi teha, sest kõik päringud olid järjekorras ja ootasid, kuni see uuendus lõpule jõuab. Kuid siin tahan ma juhtida teie tähelepanu vertikaalsel teljel olevatele numbritele. St. meil oli keskmine päringu aeg enne migreerimist umbes 5 millisekundit ning protsessori koormus, ketta mälust lugemise plokkoperatsioonide arv oli väiksem kui 7,5.

Migreerimine toimus, aga jälle tekkisid probleemid.

Migreerimine õnnestus, kuid:

• Vana funktsionaalsus hakkas töötama kauem.
• Tabel kasvas jälle suuremaks.
• Serveri koormus suurenes jälle suuremaks, kui oli.
• Ja loomulikult jätkame veel selle funktsionaalsuse kallal töötamist, mis töötas hästi, ning oleme seda veidi parandanud.

Ja see on jälle bloat, mis häirib meid taas.

Siin ma demonstreerin, et tabel, nagu eelnevatel kahel juhul, ei plaanita tagasi varasematele mõõtmetele naasta. Serveri keskmine koormus näib olevat normaalne.

Ja kui me vaatame arvetega tabelit, siis näeme, et meie keskmine päringu aeg on kahekordistunud. Protsessori koormus ja mälu tarvitamine on tõusnud üle 7,5, kui see oli varem madalam. Protsessorite puhul on tõus olnud kahekordne, plokkoperatsioonide puhul 1,5 korda, st me oleme saanud serveri jõudluse halvenemise. Selle tagajärjel ka meie rakenduse jõudlus.

Oluline on mõista, kuidas selliseid migratsioone õigesti teha. Ja neid on vajalik teostada. Teeme neid üsna tihti.

• Selliseid suuri migratsioone ei tehta automaatselt. Need peavad olema alati kontrolli all.
• Töötaja õigete teadmiste järelevalve on vajalik. Kui teie meeskonnas on DBA, siis las see teeb DBA. See on tema töö. Kui ei ole, siis las seda teostab kõige kogenum inimene, kes oskab andmebaasidega töötada.
• Uus andmebaasi skeem, isegi kui me uuendame ainult üht veergu, valmistame alati etappidena, st eelnevalt enne uue rakenduse versiooni väljalaskmist:
• Lisatakse uusi välju, kuhu salvestame just värskendatud andmed.
• Kandime andmeid vanast väljast uude väljast väikeste osade kaupa. Miks me seda teeme? Esiteks, me kontrollime alati protsessi käiku. Me teame, et oleme juba nii palju partiiid viinud ja meil on veel nii palju jäänud.
• Teine positiivne aspekt on see, et iga sellise partii vahel sulgeme transaktsiooni, avame uue ja see võimaldab automaatset vaakumit tabeli suhtes töötada, märgistada surnud read taaskasutamiseks.
• Ridade jaoks, mis ilmuvad rakenduse töö käigus (meil on endiselt aktiivne vana rakendus), lisame vallandaja, mis salvestab uued väärtused uutesse väljadessse. Meie puhul - see on vana väärtuse korrutamine sajaga.
• Kui me oleme tõeliselt kangekaelsed ja soovime sama välja, siis pärast kõiki migratsioone ja enne uue rakenduse versiooni käivitamist lihtsalt nimetame väljaanded ümber. Vanad mingiks väljamõeldud nimeks ja uued väljad nimetame vanadeks.
• Ainult pärast seda käivitame uue versiooni rakendusest.

Ja sellega ei teki meil bloat'i ega ole meil jõudluse kaotust.

Sellega 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

Nüüd räägime veidi rohkem tööriistadest, millest mainisin kõige esimeses loos.

Enne kui otsite bloat'i, on kindlasti vajalik paigaldada laiendus. pgstattuple.

Kuna te ei pea ise päringuid välja mõtlema, oleme oma töös need päringud juba valmis kirjutanud. Te saate neid kasutada. Siin on esitatud kaks päringut.

• Esimene töötab üsna kaua, kuid näitab täpseid bloat'i väärtusi tabeli lõikes.
• Teine töötab kiiremini ja on väga efektiivne, kui tuleb kiiresti hinnata – kas tabelis on bloat või ei. Ja te peaksite mõistma, et bloat Postgresi tabelites on alati olemas. See on MVCC mudeli omadus.
• Ja 20% bloat on enamasti tabelite puhul normaalne. See tähendab, et te ei pea muretsema ja seda tabelit kompresseerima.

Kuidas tuvastada vale suurusega tabeleid, oleme aru saanud, kui nad paisuvad kasututest andmetest.

Nüüd räägime, kuidas paisumist parandada:

• Kui meil on väike tabel ja head kettad, st kuni ühe gigabaidini tabeliis on täiesti võimalik kasutada VACUUM FULL. See annab teile eksklusiivse lukustuse tabelile paariks sekundiks, aga teeb selle kiiresti ja efektiivselt. Mida teeb VACUUM FULL? See võtab eksklusiivse lukustuse tabelile ja kirjutab vanad read uude tabelisse. Lõpus vahetab need omavahel. Vanad failid kustutab ja uued asendab vanadega. Ent oma töö ajal võtab see eksklusiivse lukustuse tabelilt. See tähendab, et te ei saa selle tabeliga midagi teha: ei saa kirjutada, lugeda ega muuta. Ja VACUUM FULL vajab diskil lisaruumi andmete salvestamiseks.
• Järgmine tööriist pg_repack. Selle põhimõte on väga sarnane VACUUM FULL-ile, kuna see kirjutab samuti andmed vanadest failidest uutesse ja asendab neid tabelis. Kuid see ei võta alguses eksklusiivset lukku tabelile, vaid ainult siis, kui andmed on juba valmis failide asendamiseks. Diskiruumi nõudmised on sarnased VACUUM FULL-iga. Teil on vaja täiendavat ruumi kettal, mis võib vahel olla kriitiline, kui teil on terabaidised tabelid. Samuti on see üsna protsessorinäljane, kuna teeb aktiivset sisendi-väljaannet.
• Kolmas utiliit on pgcompacttable. See käsitleb ressursse säästlikumalt, kuna töötab veidi erinevatel põhimõtetel. pgcompacttable peamine idee on see, et see viib tabelis kõik elusread algusesse uuendustega. Ja seejärel käivitab vakkuumi selle tabeli peal, kuna teame, et alguses on elusread ja lõpus surnud read. Ja vakkuum ise lõikab juba selle sabaga, st täiendavat ketta ruumi ei nõuta palju. Samuti saab seda ressursse säästlikumalt suruda.

Tööriistadega on kõik.

Kui teema bloat teid huvitab ja soovite sügavamale sukelduda, siis siin on mõned kasulikud lingid:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres – see on minu kolleegi ettekande link. See käsitleb üldiselt, kuhu kaob ruum Postgres'i töö ja elu jooksul. Seal on väga suur ja põhjalik tehniline osa andmebaasi administraatoritele bloat'i kohta.
• https://github.com/dataegret/pg-utils – see on link meie repole, kus hoiame hulga kasulikke skripte andmebaasi seisundi kontrollimiseks. Sealt leiate skripte bloat'i otsimiseks.
• Kolmas ja neljas lingid tööriistadele, mis aitavad teil tabeleid kokku suruda.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html – see on link minu kolleegi postitusele. Seal käsitleb ta bloat'i üsna tõsiselt ja põhjalikult, juba tasemel, mis on lähenev administraatoritele.

Ma püüdsin rohkem näidata hirmu sellel tasemel, mis arendajatele, sest nad on otsesed meie andmebaasi kliendid ja peavad aru saama, kuhu millised tegevused viivad. 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 hangusid mitte ainult seetõttu, et need pöördusid mõne välisteenuse poole. Need olid lihtsalt mõningad metsikud joins. Seal olid mingid pisikesed, kahjutud päringud, mis päevad viibisid, ja siis hakkasid mingit jama tegema. See on väga sarnane sellele, mida te kirjeldasite. Kuidas seda jälgida? Kas peab pidevalt vaatama, milline päring on kinni? Kuidas seda ennetada?

Antud juhul on see teie ettevõtte administraatorite ülesanne, mitte tingimata DBA.

Mina olen administraator.

PostgreSQL-is on olemas vaade nimega pg_stat_activity, kus on näha kinni jäänud päringud. Ja saate näha, kui kaua need seal on olnud.

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

Seadke cron ja kontrollige. Kui teil on pikaajaline päring, saatke kiri ja kõik. Te ei pea seda visuaalselt jälgima, see on automatiseeritav. Te saate kirja, reageerite sellele. Võite ka automaatselt käituda.

Kas on selged põhjused, miks see juhtub?

Mina nime olen mitmed loetledes. Teised on keerukamad näited. See vestlus võib võtta kaua aega.

Aitäh ettekande eest! Soovin täpsustada pg_repack utiliidi kohta. Kui see ei kehtesta eksklusiivset lukku, siis…

See loob eksklusiivse luku.

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

Ei, see töötab rahulikult tabeliga, st pg_repack liigub esmalt kõik elavad read, mis seal on. Loomulikult toimub seal mingisugune kirje tabelis. Ta lihtsalt lisab selle lõpu.

St lõpuks teeb ta seda ikkagi?

Lõpuks võtab ta eksklusiivse luku, et neid faile vahetada.

Kas see on kiiremini kui VACUUM FULL?

VACUUM FULL, kui see alustas, võttis kohe eksklusiivse luku. Ja seni, kuni ta ei ole kõike lõpetanud, ei vabasta ta seda. Aga pg_repack võtab eksklusiivse luku ainult failide vahetamise hetkeks. Sel ajal ei saa te sinna kirjutada, kuid andmed ei kao, kõik on korras.

Tere! Te rääkisite automaatse vaakumi toimimisest. Seal oli graafik punaste, kollaste ja roheliste lahtritega. T. e. kollased – ta märkis need kui kustutatud. Ja seetõttu saab neisse kirjutada midagi uut?

Jah. Postgres ei kustuta ridu. Sellel on selline eripära. Kui me uuendame rida, siis märkisime vana kui kustutatud. Seal on tehingu id, mis muutis seda rida, ja kirjutame uue rea. Ja meil on sessioonid, mis võivad neid lugeda. Mingil hetkel muutuvad nad juba täiesti vanaks. Ja automaatse vaakumi töö idee on selles, et ta jookseb nende ridade vahelt läbi ja märkib nad kui mittevajalikud. Ja sinna saab andmeid üle kirjutada.

Mõistsin. Kuid küsimus ei ole sellest. Ma ei lõpetanud. Oletame, et meil on tabel. Seal on muutuva suurusega väljad. Ja kui ma üritan midagi uut lisada, siis see ei pruugi lihtsalt vanasse lahtrisse mahtuda.

Ei, seal igal juhul värskendatakse kogu rida. Postgresis on andmete salvestamiseks kaks mudelit. See valib andme tüübist lähtuvalt. On andmeid, mis salvestatakse otse tabelisse, ning on ka tos-andmeid. Need on suured andmehulgad: tekst, json. Need salvestatakse eraldi tabelitesse. Ja nende tabelite puhul kehtib sama lugu bloat'iga, st kõik on sama. Lihtsalt need on eraldi välja toodud.

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

Väga vastuvõetav. Me kasutame seda igal pool. Kuna meil ei ole oma teenuseid, pakume veebipõhist tuge ning meie kliendid on üsna erinevad. Kõik on sellega täiesti rahul. St meil on cron'is ülesanded, mis kontrollivad. Lihtsalt lepitakse kliendiga kokku sessioonide kestus, mille eel me ei katkesta. See võib olla minut või 10 minutit. See sõltub andmebaasi koormusest ja selle eesmärgist. Kuid kõigil kasutame pg_stat_activity.

Aitäh ettekande eest! Proovin teie ettekannet oma rakendustele rakendada. Tundub, et igal pool alustame tehingut, lõpetame selle selgelt. Kui on mingisugune erand, siis ikkagi toimub rollback. Siis mõtlesin. Tehing võib alata ju ka mitte selgelt. See võib olla vihje tüdrukule, ilmselt. Kui ma lihtsalt uuendan записи, algab PostgreSQL’is tehing ja see lõpeb alles siis, kui ühendus katkeb?

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

St. tähendab, et see sulgub kohe pärast uuendamist?

See sõltub seadistustest. Üht seadistust mainisin. See on auto commit. See on üsna levinud. Kui see on sisse lülitatud, siis tehing avatakse ja suletakse. Kui te ei ole selgelt öelnud 'start transaction' ja 'end transaction', vaid lihtsalt käivitasite päringu seansis.

Tere! Aitäh ettekande eest! Kujutame ette, et meil on andmebaas, mis kasvab pidevalt ja serveris hakkab ruum otsa saama. Kas on mingeid tööriistu, et seda olukorda parandada?

Serveri ruumi tuleks kindlasti jälgida.

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

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

Ent kui ruum on täiesti nullis?

Seal on see nimega reserved space, st seda on võimalik vabastada ja sõltuvalt sellest, kui suurt seda on loodud, saate vabade kohtade. Vaikimisi ei tea ma, kui palju seal on. Teises olukorras tuleb toimetada kettaid, et oleks ruumi taastamise operatsiooni läbiviimiseks. Saate eemaldada mingi tabeli, mis teil kindlasti ei ole vajalik.

Teisi tööriistu ei ole?

See on alati käsitsi tehtav töö. Ja ruumi osas selgub, mis seal parem oleks teha, kuna andmed on kriitilised ja mitte kriitilised. Iga andmebaasi ja rakenduse puhul, mis sellega töötab, sõltub see ettevõttest. Alati toimub otsus ruumi alusel.

Aitäh ettekande eest! Mul on kaks küsimust. Esiteks, te demonstreerisite slaide, kus näidati, et hetkeseisus olevate tehingute korral kasvab nii tabeliruumi maht kui ka indeksi suurus. Ja edasi ettekandes oli palju utiliite, mis pakivad tabelit. Aga mis juhtub indeksiga?

Need pakivad ka neid.

Aga vakuum ei puuduta indexit?

Mõned töötlused puudutavad indekseid. Näiteks, pg_rapack, pgcompacttable. Vakuum taastab indeksid, see mõjutab neid. VACUUM FULL-i mõte on kõik uuesti kirjutada, st see töötab kõigiga.

Ja teine küsimus. Ma ei saanud aru, miks raportid replikaates nii palju sõltuvad replikatsioonist. Mul tundus, et raportid on lugemine ja replikatsioon on kirjutamine.

Milles seis on replikatsiooni konflikt? Meil on Master, kus toimuvad protsessid. Meil on automaatne vaakum. Mida teeb automaatne vaakum? Ta eemaldab mõned vanad read. Kui sel ajal on replikas päring, mis loeb neid vanu ridu, ja Masteris on olukord, kus automaatne vaakum on need read märkinud kui võimalikud kirjutamiseks, siis me kirjutame need üle. Ja me saame andmepaki, kui peame kirjutama üle need read, mis on vajalikud päringu jaoks replikas, siis replikatsioon ootab määratud ajamisaega, mille olete seadistanud. Ja siis otsustab PostgreSQL, mis on tema jaoks olulisem. Ja replikatsioon on tema jaoks olulisem kui päring ning ta katkestab päringu, et teha need muudatused replikas.

Andrei, mul on küsimus. Need imelised graafikud, mida te esitlemise ajal näitasite, on need tulemused mingist teie utiliidist? Millest graafikud on koostatud?

See on teenus Okmeter.

Kas see on kaubanduslik toode?

Jah. See on kaubanduslik toode.

Allikas: habr.com