Ehdotan, että luetaan Andrey Salnikovin vuoden 2016 alun raportin "Tyypilliset virheet sovelluksissa, jotka johtavat turvotukseen postgresql:ssä" kopio.
Tässä raportissa analysoin tärkeimpiä sovellusten virheitä, joita esiintyy sovelluskoodin suunnittelu- ja kirjoitusvaiheessa. Ja otan vain ne virheet, jotka johtavat paisumiseen Postgresqlissa. Tämä on pääsääntöisesti koko järjestelmäsi suorituskyvyn lopun alkua, vaikka siihen ei alun perin nähty edellytyksiä.
Kiva toivottaa kaikki tervetulleiksi! Tämä raportti ei ole niin tekninen kuin kollegani edellinen raportti. Tämä keskustelu on suunnattu taustajärjestelmien kehittäjille lähinnä siksi, että meillä on melko suuri määrä asiakkaita. Ja he kaikki tekevät samoja virheitä. Kerron sinulle niistä. Selitän, mihin kohtalokkaaseen ja pahaan nämä virheet johtavat.
Miksi virheitä tehdään? Ne suoritetaan kahdesta syystä: satunnaisesti, ehkä se toimii tietämättömyydestä joistakin mekanismeista, joita esiintyy tukikohdan ja sovelluksen välisellä tasolla sekä itse tukiasemassa.
Annan sinulle kolme esimerkkiä kauheiden kuvien kera siitä, kuinka asiat menivät huonosti. Kuvaan lyhyesti siellä esiintyvää mekanismia. Ja kuinka käsitellä niitä, milloin ne tapahtuivat ja mitä ennaltaehkäiseviä menetelmiä käyttää virheiden estämiseksi. Kerron sinulle aputyökaluista ja annan hyödyllisiä linkkejä.
Käytin testitietokantaa, jossa minulla oli kaksi taulukkoa. Toisella levyllä on asiakastilit, toisella näiden tilien toiminnot. Ja tietyin väliajoin päivitämme näiden tilien saldot.
Kilven alkutiedot: se on melko pieni, 2 MB. Tietokannan ja erityisesti levyn vasteaika on myös erittäin hyvä. Ja melko hyvä kuorma - 2 operaatiota sekunnissa levyllä.
Ja tämän raportin kautta näytän sinulle kaavioita, jotta on selvää, mitä tapahtuu. Mukana on aina 2 diaa, joissa on kaavioita. Ensimmäinen dia on se, mitä yleensä tapahtuu palvelimella.
Ja tässä tilanteessa näemme, että meillä on todella pieni lautanen. Indeksi on pieni, 2 Mt. Tämä on ensimmäinen kaavio vasemmalla.
Keskimääräinen vasteaika palvelimella on myös vakaa, pieni. Tämä on oikean yläkulman kaavio.
Alempi vasen kaavio on pisimmät tapahtumat. Näemme, että kaupat valmistuvat nopeasti. Ja autoimuri ei vielä toimi täällä, koska - se oli aloitustesti. Silloin se toimii ja on hyödyllinen meille.
Toinen dia omistetaan aina testilevylle. Tässä tilanteessa päivitämme jatkuvasti asiakkaan tilisaldoja. Ja näemme, että päivitystoiminnan keskimääräinen vasteaika on melko hyvä, alle millisekunti. Näemme, että myös prosessoriresurssit (tämä on ylempi oikea kaavio) kulutetaan tasaisesti ja melko vähän.
Oikean alareunan kaavio näyttää, kuinka paljon käyttö- ja levymuistia käymme läpi etsiessään haluamaamme riviä ennen sen päivittämistä. Ja leikkausten määrä levyllä on 2 sekunnissa, kuten sanoin alussa.
Ja nyt meillä on tragedia. Jostain syystä tapahtuu kauan unohdettu tapahtuma. Syyt ovat yleensä banaalisia:
- Yksi yleisimmistä on, että aloimme käyttää ulkoista palvelua sovelluskoodissa. Ja tämä palvelu ei vastaa meille. Toisin sanoen avasimme tapahtuman, teimme muutoksen tietokantaan ja siirryimme sovelluksesta lukemaan postia tai toiseen palveluun infrastruktuurissamme, eikä se jostain syystä vastaa meille. Ja istuntomme roikkui tilassa - ei tiedetä, milloin se ratkaistaan.
- Toinen tilanne on, kun koodissamme tapahtui poikkeus jostain syystä. Emmekä käsitelleet kaupan sulkemista poikkeustapauksessa. Ja saimme hengailuistunnon avoimella kaupalla.
- Ja viimeinen on myös melko yleinen. Tämä on huonolaatuinen koodi. Jotkut puitteet avaavat tapahtuman. Se roikkuu, etkä ehkä tiedä sovelluksesta, että se roikkuu.
Mihin tällaiset asiat johtavat?
Siihen, että taulukomme ja indeksimme alkavat turvota dramaattisesti. Tämä on täsmälleen sama turvotusefekti. Tietokannan osalta tämä ilmenee siinä, että tietokannan vasteaika kasvaa erittäin jyrkästi, tietokantapalvelimen kuormitus kasvaa. Tämän seurauksena sovelluksemme kärsii. Sillä jos koodissasi käytit 10 millisekuntia tietokannan pyyntöön, 10 millisekuntia logiikkaan, funktiosi toimi 20 millisekuntia. Ja nyt tilanteesi tulee olemaan hyvin surullinen.
Ja katsotaan mitä tapahtuu. Vasemmanpuoleinen kaavio osoittaa, että meillä on pitkä ja pitkä kauppa. Ja jos katsomme vasemman yläkulman kaaviota, huomaamme, että taulukon koko hyppäsi kahdesta megatavusta 300 megatavuun. Samaan aikaan taulukon tietojen määrä ei ole muuttunut, eli roskaa on melko paljon.
Myös kokonaistilanne keskimääräisen palvelimen vasteajan suhteen on muuttunut useiden suuruusluokkien verran. Eli kaikki palvelimella olevat pyynnöt alkoivat laskea kokonaan. Ja samaan aikaan käynnistettiin sisäiset Postgres-prosessit autotyhjiön edessä, jotka yrittävät tehdä jotain ja kuluttavat resursseja.
Mitä lautasellemme tapahtuu? Sama. Tabletin keskimääräinen vasteaika nousi useita suuruusluokkia. Jos nimenomaan kulutettujen resurssien suhteen, niin näemme, että prosessorin kuormitus on lisääntynyt huomattavasti. Tämä on oikean yläkulman kaavio. Ja se on lisääntynyt, koska prosessori joutuu käymään läpi joukon turhia linjoja etsiessään tarvitsemaasi. Tämä on alempi oikea kaavio. Ja seurauksena puheluiden määrä sekunnissa alkoi laskea voimakkaasti, koska tietokannalla ei ole aikaa käsitellä samaa määrää pyyntöjä.
Meidän on palattava elämään. Kiipeämme Internetiin ja huomaamme, että pitkät tapahtumat johtavat ongelmaan. Löydämme ja lopetamme tämän kaupan. Ja meillä kaikki menee hyvin. Kaikki toimii niinkuin pitääkin.
Rauhoituimme, mutta hetken kuluttua alamme huomata, että sovellus ei toimi niin kuin ennen hätätilannetta. Pyynnöt käsitellään kuitenkin hitaammin ja paljon hitaammin. Puolitoista tai kaksi kertaa hitaampi erityisesti esimerkissäni. Palvelimen kuormitus on myös suurempi kuin ennen onnettomuutta.
Ja kysymys: "Mitä tukikohdalle tapahtuu tällä hetkellä?". Ja pohjalta on seuraava tilanne. Tapahtumakaaviosta näet, että se on pysähtynyt ja pitkäaikaisia tapahtumia ei todellakaan ole. Mutta levyn mitat onnettomuuden aikana kasvoivat kohtalokkaasti. Eikä se ole vähentynyt sen jälkeen. Keskimääräinen aika tukikohdassa on vakiintunut. Ja vastaukset näyttävät menevän riittävästi meille hyväksyttävällä nopeudella. Autovacuum aktivoitui ja alkoi tehdä jotain tabletin kanssa, koska se tarvitsee lisää tietoa.
Erityisesti testitulostaululla, jossa vaihdamme saldoja: pyynnön vastausaika näyttää palanneen normaaliksi. Mutta itse asiassa se on puolitoista kertaa suurempi.
Ja prosessorin kuormituksen perusteella näemme, että prosessorin kuormitus ei palannut haluttuun arvoon ennen kaatumista. Ja syyt siihen ovat vain oikeassa alakulmassa. Voidaan nähdä, että jonkin verran muistia etsitään. Toisin sanoen halutun rivin etsimiseen kulutamme tietokantapalvelimen resursseja lajitellessamme turhia tietoja. Tapahtumien määrä sekunnissa on vakiintunut.
Yleisesti ottaen hyvä, mutta tilanne on huonompi kuin se oli. Tietokannan selkeä heikkeneminen tämän tietokannan kanssa toimivan sovelluksemme seurauksena.
Ja ymmärtääkseni mitä siellä tapahtuu, jos et ollut edellisessä raportissa, niin nyt vähän teoriaa. Teoria sisäisestä prosessista. Miksi autoimuri ja mitä se tekee?
Kirjaimellisesti pähkinänkuoressa ymmärryksen vuoksi. Jossain vaiheessa meillä on pöytä. Meillä on rivejä taulukossa. Nämä linjat voivat olla aktiivisia, live, tarvitsemme nyt. Ne on merkitty kuvassa vihreällä. Ja on kuolleita rivejä, jotka ovat jo toimineet, päivitetty, niihin on ilmestynyt uusia merkintöjä. Ja ne on merkitty, että ne eivät enää kiinnosta tietokantaa. Mutta ne ovat taulukossa Postgresin erityispiirteiden vuoksi.
Miksi tarvitset automaattisen tyhjiön? Autovacuum tulee jossain vaiheessa, soittaa tietokantaan ja kysyy: "Anna minulle vanhimman tietokannassa tällä hetkellä avoinna olevan tapahtuman tunnus." Tietokanta palauttaa tämän tunnuksen. Ja siihen luottaen autotyhjiö kulkee taulukon linjojen läpi. Ja jos hän näkee, että joitain rivejä on muutettu paljon vanhemmilla tapahtumilla, hänellä on oikeus merkitä ne riveiksi, joita voimme käyttää jatkossa uudelleen kirjoittamalla sinne uusia tietoja. Tämä on taustaprosessi.
Tällä hetkellä jatkamme työskentelyä tietokannan kanssa, jatkamme joidenkin muutosten tekemistä taulukkoon. Ja näille riveille, joita voimme käyttää uudelleen, kirjoitamme uutta dataa. Ja tällä tavalla saamme syklin, eli siellä ilmestyy jatkuvasti jotain kuolleita vanhoja rivejä, niiden sijaan kirjoitamme uusia rivejä, joita tarvitsemme. Ja tämä on normaali tila, jossa PostgreSQL toimii.
Mitä tapahtui onnettomuuden aikana? Miten tämä prosessi tapahtui?
Meillä oli lautanen jossain kunnossa, osa eläviä, osa kuolleita linjoja. Autoimuri on saapunut. Hän kysyi tietokannasta, mikä on vanhin tapahtumamme, mikä on sen tunnus. Sain tämän tunnuksen, joka voi olla monta tuntia vanha, ehkä kymmenen minuuttia vanha. Se riippuu siitä, kuinka suuri kuormitus sinulla on tietokannassa. Ja hän meni etsimään rivejä, jotka hän voi merkitä uudelleen käytetyiksi. Enkä löytänyt tällaisia rivejä taulukostamme.
Mutta tällä hetkellä jatkamme työskentelyä pöydän kanssa. Teemme siinä jotain, päivitämme sitä, muutamme tietoja. Mitä tietokannan pitäisi tehdä tällä hetkellä? Hänellä ei ole muuta vaihtoehtoa kuin lisätä uusia rivejä olemassa olevan taulukon loppuun. Ja näin meillä pöydän koko alkaa paisua.
Tarvitsemme todella vihreitä linjoja toimiaksemme. Mutta tällaisen ongelman aikana käy ilmi, että vihreiden viivojen prosenttiosuus on erittäin alhainen koko taulukon tilavuudessa.
Ja kun suoritamme kyselyn, tietokannan täytyy käydä läpi kaikki rivit, sekä punaiset että vihreät, löytääkseen oikean rivin. Ja vaikutusta taulukon täyttämisestä turhalla tiedolla kutsutaan "paisutukseksi", joka myös syö levytilaamme. Muistatko, se oli 2 Mt, nyt se on 300 Mt? Vaihda nyt megatavuja gigatavuiksi ja menetät kaikki levyresurssit melko nopeasti.
Mitä vaikutuksia sillä on meille?
- Esimerkissäni taulukko ja indeksi ovat kasvaneet 150 kertaa. Joillakin asiakkaillamme on ollut kohtalokkaampia tapauksia, joissa levytila on yksinkertaisesti alkanut loppua.
- Pöydät eivät koskaan kutistu itsestään. Automaattinen tyhjiö voi joissain tapauksissa katkaista pöydän hännän, jos siinä on vain kuolleita viivoja. Mutta koska pyöriminen on jatkuvaa, yksi vihreä viiva voi roikkua lopussa eikä sitä päivitetä, ja kaikki loput jonnekin levyn alkuun tallennetaan. Mutta tämä on niin epätodennäköinen tapahtuma, että pöytäsi pienenee, joten sinun ei pitäisi toivoa sitä.
- Tietokannan on järjestettävä läpi koko kasa turhia rivejä. Ja tuhlaamme levyresursseja, tuhlaamme prosessoriresursseja ja sähköä.
- Ja tämä vaikuttaa suoraan sovellukseemme, sillä jos aluksi käytimme pyyntöön 10 millisekuntia, koodiimme 10 millisekuntia, niin kaatumisen aikana aloimme käyttää sekuntia pyyntöön ja 10 millisekuntia koodiin, eli järjestyksessä sovelluksen suorituskyky heikkeni. Ja kun onnettomuus ratkesi, aloimme käyttää 20 millisekuntia pyyntöä kohti, 10 millisekuntia koodia kohti. Tämä tarkoittaa, että suorituskyvyn suhteen upposimme silti puolitoista kertaa. Ja tämä kaikki johtuu yhdestä tapahtumasta, joka jäi jumiin, ja ehkä meidän syytämme.
- Ja kysymys: "Kuinka saan kaiken takaisin?" Että meillä on kaikki hyvin ja pyynnöt kulkevat yhtä nopeasti kuin ennen onnettomuutta.
Tätä varten tehdään tietty työkierto.
Ensin meidän on löydettävä ongelmalliset taulukot, jotka ovat turvonneet. Ymmärrämme, että jotkut taulukot tallentavat aktiivisemmin, jotkut vähemmän aktiivisesti. Ja tähän käytämme laajennusta . Asentamalla tämän laajennuksen voit kirjoittaa kyselyitä, jotka auttavat sinua löytämään riittävän paisuneita taulukoita.
Kun olet löytänyt nämä taulukot, ne on pakattava. Tähän on jo työkalut. Yrityksessämme käytämme kolmea työkalua. Ensimmäinen on sisäänrakennettu VACUUM FULL. Hän on julma, ankara ja armoton, mutta joskus hän on erittäin hyödyllinen. и ovat kolmannen osapuolen apuohjelmia taulukoiden pakkaamiseen. Ja he ovat varovaisempia tietokannan suhteen.
Niitä käytetään sen mukaan, mikä on sinulle kätevämpää. Mutta puhun tästä aivan lopussa. Pääasia, että työkaluja on kolme. Valittavana on paljon.
Kun olemme korjanneet kaiken ja varmistaneet, että kaikki on hyvin, meidän pitäisi tietää, kuinka tämä tilanne voidaan estää tulevaisuudessa:
- Se on melko helppo estää. Sinun on seurattava istuntojen kestoa pääpalvelimella. Erityisen vaaralliset istunnot lepotilassa tapahtumatilassa. Nämä ovat niitä, jotka juuri avasivat tapahtuman, tekivät jotain ja lähtivät, tai yksinkertaisesti roikkuivat, eksyivät koodiin.
- Ja sinulle, kehittäjille, on tärkeää testata koodia näiden tilanteiden ilmaantuessa. Se ei ole vaikea tehdä. Tämä on hyödyllinen tarkistus. Vältät monia "lapsellisia" ongelmia, jotka liittyvät pitkiin asioihin.
Näillä kaavioilla halusin näyttää, kuinka taulukko ja tietokannan käyttäytyminen muuttuivat sen jälkeen, kun läpäisin VACUUM FULL taulukossa tässä tapauksessa. Tämä ei ole minun tuotantoani.
Taulukon koko palasi välittömästi normaaliin parin megatavun toimintatilaan. Tämä ei suuresti vaikuttanut keskimääräiseen vasteaikaan palvelimella.
Mutta erityisesti testitaulukossamme, jossa päivitimme tilisaldot, huomaamme, että keskimääräinen vastausaika pyyntöön päivittää tabletin tiedot lyheni kaatumista edeltävälle tasolle. Myös prosessorin tämän pyynnön suorittamiseen käyttämät resurssit putosivat kaatumista edeltävälle tasolle. Ja alempi oikea kaavio osoittaa, että nyt löydämme juuri sen rivin, jonka tarvitsemme heti, menemättä läpi niitä kuolleita rivejä, jotka olivat ennen taulukon pakkaamista. Ja keskimääräinen kyselyaika pysyi suunnilleen samalla tasolla. Mutta tässä minulla on pikemminkin laitteistoni virhe.
Ensimmäinen tarina päättyy tähän. Hän on yleisin. Ja se tapahtuu kaikille, riippumatta asiakkaan kokemuksesta, kuinka päteviä ohjelmoijia siellä on. Ennemmin tai myöhemmin se tapahtuu.
Toinen tarina, jossa jaamme kuorman ja optimoimme palvelinresursseja
- Olemme kasvaneet ja tulleet vakaviksi miehiksi. Ja ymmärrämme, että meillä on kopio, ja meidän olisi hyvä tasapainottaa kuormitusta: kirjoittaa Masterille ja lukea replikasta. Ja yleensä tämä tilanne syntyy, kun haluamme laatia jonkinlaisia raportteja tai ETL: tä. Ja liike on erittäin iloinen siitä. Hän todella haluaa erilaisia raportteja, joissa on paljon monimutkaista analytiikkaa.
- Raportit kestävät useita tunteja, koska monimutkaista analytiikkaa ei voida laskea millisekunneissa. Me, kuten rohkeat kaverit, kirjoitamme koodia. Teemme lisäyssovelluksessa, jonka nauhoitamme Masteriin, teemme raportteja kopiosta.
- Jaamme kuorman.
- Kaikki toimii täydellisesti. Olemme mahtavia.
Ja miltä tämä tilanne näyttää? Tarkemmin sanottuna näihin kaavioihin lisäsin myös replikan tapahtumien keston tapahtuman kestoon. Kaikki muut kaaviot viittaavat vain pääpalvelimeen.
Tähän mennessä raporttitauluni oli kasvanut. Niitä on enemmän. Voimme nähdä, että palvelimen keskimääräinen vasteaika on vakaa. Näemme, että meillä on pitkä käynnissä oleva kopio, joka kestää 2 tuntia. Näemme automaattisen tyhjiön hiljaisen työn, joka käsittelee kuolleita linjoja. Ja meillä on kaikki hyvin.
Tarkemmin sanottuna testitabletin mukaan jatkamme siellä olevien tilien saldojen päivittämistä. Ja meillä on myös vakaa vasteaika pyynnöstä, vakaa resurssien kulutus. Meillä on kaikki hyvin.
Kaikki on hyvin siihen hetkeen asti, kun nämä raportit alkavat palata meille ristiriidassa replikoinnin kanssa. Ja he ampuvat takaisin säännöllisin väliajoin.
Siirrymme verkkoon ja alamme lukea, miksi näin tapahtuu. Ja löydämme ratkaisun.
Ensimmäinen ratkaisu on lisätä replikaation latenssia. Tiedämme, että raporttimme kestää 3 tuntia. Aseta replikointiviive 3 tunniksi. Aloitamme kaiken, mutta meillä on edelleen ongelmia sen kanssa, että raportteja joskus ammutaan takaisin.
Haluamme kaiken olevan täydellistä. Mennään pidemmälle. Ja löydämme siistin asetuksen Internetistä - hot_standby_feedback. Kytkemme sen päälle. Hot_standby_feedback antaa meille mahdollisuuden pitää automaattinen tyhjiö käynnissä Masterissa. Siten pääsemme täysin eroon replikointiristiriidoista. Ja me kaikki työskentelemme hyvin raporttien kanssa.
Ja mitä pääpalvelimelle tapahtuu tällä hetkellä? Ja pääpalvelimen kanssa meillä on täydellinen katastrofi. Näemme nyt kaavioita, joissa molemmat asetukset ovat käytössä. Ja näemme, että replikan istunto alkoi jotenkin vaikuttaa pääpalvelimen tilanteeseen. Sillä on vaikutusta, koska se on keskeyttänyt automaattisen tyhjiön, joka puhdistaa kuolleet viivat. Pöytäkokomme on taas noussut pilviin. Myös keskimääräinen kyselyn suoritusaika koko tietokannassa nousi pilviin. Imurit kiristyvät hieman.
Tarkemmin sanottuna levyllämme näemme, että myös sen datapäivitys hyppäsi taivaalle. Myös prosessoriresurssien kulutus on kasvanut huomattavasti. Toistamme jälleen useita kuolleita hyödyttömiä rivejä. Ja tämän tabletin vasteaika, tapahtumien määrä on laskenut.
Miltä se näyttää, jos emme tiedä, mistä puhuin aiemmin?
- Alamme etsiä ongelmia. Jos kohtasimme ongelmia ensimmäisessä osassa, tiedämme, että tämä voi olla syynä pitkälle transaktiolle ja kiipeämme Masterin päälle. Ongelma on Mestarissa. Makkarat hänelle. Hän lämmittelee, hänen kuormituksen keskiarvo on alle sata.
- Pyynnöt hidastuvat siellä, mutta emme näe siellä mitään pitkäaikaisia transaktioita. Ja me emme ymmärrä mitä tapahtuu. Emme tiedä mistä etsiä.
- Tarkistetaan palvelinlaitteistoa. Ehkä ryöstömme on romahtanut. Ehkä poltimme muistipalkin. Kyllä, mitä tahansa voi olla. Mutta ei, palvelimet ovat uusia, kaikki toimii hyvin.
- Kaikki juoksevat: järjestelmänvalvojat, kehittäjät ja johtaja. Mikään ei auta.
- Ja jossain vaiheessa kaikki alkaa yhtäkkiä korjata itsestään.
Tuolloin kopiossa pyyntö toimi ja lähti. Olemme saaneet raportin. Liike on edelleen onnellinen. Kuten näette, pöytämme on jälleen kasvanut eikä aio laskea. Istuntoja sisältävään kaavioon jätin osan tästä pitkästä tapahtumasta kopiosta, jotta voit arvioida, kuinka kauan tilanteen vakauttaminen kestää.
Istunto on mennyt. Ja vasta jonkin ajan kuluttua palvelin tulee enemmän tai vähemmän järjestykseen. Ja pääpalvelimen pyyntöjen keskimääräinen vasteaika palaa normaaliksi. Koska vihdoinkin autoimuri sai mahdollisuuden puhdistaa, merkitä nämä kuolleet linjat. Ja hän alkoi tehdä työtään. Ja kuinka nopeasti hän tekee sen, niin nopeasti me olemme kunnossa.
Testitaulukossa, jossa päivitämme tilisaldot, näemme täsmälleen saman kuvan. Keskimääräinen tilin päivitysaika normalisoituu myös vähitellen. Myös prosessorin kuluttamat resurssit vähenevät. Ja tapahtumien määrä sekunnissa on palannut normaaliksi. Mutta taas, takaisin normaaliin, ei samaan kuin ennen onnettomuutta.
Joka tapauksessa saamme suorituskyvyn laskun, kuten ensimmäisessä tapauksessa, puolitoista tai kaksi kertaa ja joskus enemmän.
Näyttää siltä, että olemme tehneet kaiken oikein. Jaa kuorma. Laite ei ole tyhjäkäynnillä. Mielen mukaan he rikkoivat pyyntöjä, mutta silti kaikki meni huonosti.
- Älä ota hot_standby_feedbackia käyttöön? Kyllä, sitä ei suositella kytkemään päälle ilman erityisen painavia syitä. Koska tämä kierre vaikuttaa suoraan pääpalvelimeen ja keskeyttää siellä olevan tyhjiön työn. Kytkemällä sen päälle jossain kopiossa ja unohtamalla sen, voit tappaa Masterin ja saada suuria ongelmia sovelluksen kanssa.
- Lisätäänkö max_standby_streaming_delaya? Kyllä, raporteissa se on. Jos sinulla on kolmen tunnin raportti, etkä halua sen kaatuvan replikointiristiriitojen vuoksi, lisää vain viivettä. Pitkä raportti ei koskaan vaadi tietoja, jotka ovat tulleet tietokantaan juuri nyt. Jos sinulla on se kolme tuntia, käytät sitä jonkin vanhan datajakson ajan. Ja sinä, se kolmen tunnin viive, tuo kuuden tunnin viive - et näytä mitään roolia, mutta saat raportteja johdonmukaisesti etkä tiedä niiden kaatumisen ongelmia.
- Luonnollisesti sinun on ohjattava replikoiden pitkiä istuntoja, varsinkin jos päätät ottaa hot_standby_feedbackin käyttöön replikoissa. Koska se voi olla mitä tahansa. Annoimme tämän huomautuksen kehittäjälle, jotta hän testaisi pyynnöt. Hän kirjoitti hullun pyynnön. Hän aloitti ja meni juomaan teetä, ja saimme vakiintuneen mestarin. Tai sitten käynnistimme väärän sovelluksen. Tilanteet ovat erilaisia. Kopioiden istuntoja on valvottava yhtä huolellisesti kuin Masterissa.
- Ja jos sinulla on nopeita ja pitkiä kyselyitä replikoista, tässä tapauksessa on parempi jakaa ne taakan jakamiseksi. Tämä on linkki kohtaan streaming_delay. Nopeasti saada yksi replika pienellä replikointiviiveellä. Käytä pitkäaikaisia raportointipyyntöjä varten kopiota, joka voi viivästyä 6 tuntia päivässä. Tämä on täysin normaali tilanne.
Poistamme seuraukset samalla tavalla:
- Löydämme turvonneita pöytiä.
- Ja puristamme kätevimmällä meille sopivalla työkalulla.
Toinen tarina päättyy tähän. Siirrytään kolmanteen tarinaan.
Myös melko yleistä meille, jossa teemme muuton.
- Mikä tahansa ohjelmistotuote kasvaa. Vaatimukset muuttuvat. Joka tapauksessa haluamme kehittyä. Ja tapahtuu, että meidän on päivitettävä taulukon tiedot, nimittäin suorittaaksemme päivityksen siirtyessämme uuteen toiminnallisuuteen, jota otamme käyttöön osana kehitystämme.
- Vanha datamuoto ei sovi. Oletetaan, että siirrymme nyt toiseen taulukkoon, jossa minulla on toimintaa näillä tileillä. Ja sanotaan, että ne olivat ruplissa, ja päätimme lisätä tarkkuutta ja tehdä sen kopeikoissa. Ja tätä varten meidän on tehtävä päivitys: kerrotaan kenttä operaation määrällä sadalla.
- Nykymaailmassa käytämme automaattisia tietokannan versiointityökaluja. Sanokaamme . Rekisteröimme muuttomme siellä. Testaamme sitä testipohjallamme. Kaikki on hyvin. Päivitys on käynnissä. Esteet toimivat jonkin aikaa, mutta saamme päivitettyjä tietoja. Ja voimme tuoda tähän käyttöön uusia toimintoja. Kaikki testattu ja tarkastettu. Kaikki vahvistettu.
- Suoritti suunniteltuja töitä, toteutti muuttoliikkeen.
Tässä on siirto edessäsi olevalla päivityksellä. Koska minulla on tilitoimintoja, levy oli 15 Gt. Ja koska päivitämme jokaista riviä, olemme kaksinkertaistaneet taulukon koon, koska olemme kirjoittaneet jokaisen rivin päälle.
Siirron aikana emme voineet tehdä tälle tunnisteelle mitään, koska kaikki sitä koskevat pyynnöt olivat jonossa ja odotettiin päivityksen valmistumista. Mutta tässä haluan kiinnittää huomionne numeroihin, jotka ovat pystyakselilla. Toisin sanoen meillä on keskimääräinen pyyntöaika ennen siirtoa noin 5 millisekuntia ja prosessorin kuormitus, levymuistin lukemisen lohkotoimintojen määrä on alle 7,5.
Muutimme ja saimme taas ongelmia.
Siirto onnistui, mutta:
- Vanhat toiminnot alkoivat toimia pidempään.
- Pöytä on taas kasvanut.
- Palvelimen kuormitus on taas kasvanut enemmän kuin se oli.
- Ja tietysti vieläkin puuhailemme hyvin toimineiden toimintojen parissa, paransimme sitä hieman.
Ja tämä on taas turvotusta, joka taas pilaa elämämme.
Tässä osoitan, että taulukko, kuten kaksi edellistä tapausta, ei aio palata edellisiin kokoihin. Palvelimen keskimääräinen kuormitus näyttää olevan riittävä.
Ja jos siirrymme tilien taulukkoon, huomaamme, että tämän taulukon keskimääräinen pyyntöaika on kaksinkertaistunut. Prosessorin kuormitus ja muistissa selvitettävien rivien määrä hyppäsi yli 7,5:n, mutta se oli pienempi. Ja hyppäsi prosessorien tapauksessa 2-kertaiseksi, lohkotoimintojen osalta 1,5-kertaiseksi, eli saimme palvelimen suorituskyvyn heikkenemisen. Ja seurauksena - sovelluksemme suorituskyvyn heikkeneminen. Samaan aikaan puheluiden määrä pysyi suunnilleen samalla tasolla.
Ja tässä tärkeintä on ymmärtää, kuinka tällaiset siirrot tehdään oikein. Ja ne on tehtävä. Teemme näitä siirtoja melko säännöllisesti.
- Näin suuria siirtoja ei tehdä automaattisesti. Niitä on aina valvottava.
- Vaatii asiantuntevan henkilön ohjausta. Jos tiimissäsi on DBA, anna DBA:n tehdä se. Se on hänen työnsä. Jos ei, anna kokeneen henkilön tehdä se, joka osaa työskennellä tietokantojen kanssa.
- Uusi tietokantaskeema, vaikka päivittäisimme yhden sarakkeen, valmistelemme aina vaiheittain eli etukäteen ennen kuin sovelluksen uusi versio julkaistaan:
- Lisätään uusia kenttiä, joihin kirjoitamme vain päivitetyt tiedot.
- Siirrämme tietoja vanhasta pellosta uudelle pellolle pienissä osissa. Miksi teemme näin? Ensinnäkin hallitsemme aina tämän prosessin prosessia. Tiedämme, että olemme jo siirtäneet niin monta eriä ja meillä on niin paljon jäljellä.
- Ja toinen myönteinen vaikutus on, että jokaisen tällaisen erän välillä suljemme tapahtuman, avaamme uuden, ja tämä mahdollistaa sen, että autoimuri toimii levyn mukaisesti, merkitsee kuolleita linjoja uudelleenkäyttöä varten.
- Riveille, jotka tulevat näkyviin sovelluksen toiminnan aikana (meillä on edelleen vanha sovellus), lisäämme liipaisimen, joka kirjoittaa uusia arvoja uusiin kenttiin. Meidän tapauksessamme tämä on kertominen sadalla vanhasta arvosta.
- Jos olemme täysin itsepäisiä ja haluamme saman kentän, nimeämme kentät uudelleen kaikkien siirtojen päätyttyä ja ennen uuden sovelluksen version käyttöönottoa. Vanhat kentät joksikin keksityksi nimeksi ja nimeämme uudet kentät vanhoiksi.
- Ja vasta sen jälkeen käynnistämme uuden version sovelluksesta.
Ja samaan aikaan emme turvota emmekä heikkene suorituskyvyssämme.
Tämä on kolmannen tarinan loppu.
Ja nyt vähän lisää työkaluista, jotka mainitsin aivan ensimmäisessä jutussa.
Ennen kuin etsit turvotusta, sinun on asennettava laajennus .
Jotta et keksi pyyntöjä, olemme jo kirjoittaneet nämä pyynnöt työhömme. Voit käyttää niitä. Tässä on kaksi pyyntöä.
- Ensimmäinen kestää melko kauan, mutta se näyttää sinulle tarkat turvotuksen arvot taulukon mukaan.
- Toinen toimii nopeammin ja on erittäin tehokas, kun sinun on nopeasti arvioitava, onko taulukossa turvotusta vai ei. Ja sinun pitäisi myös ymmärtää, että Postgres-pöydässä on aina paisuminen. Tämä on hänen MVCC-mallinsa ominaisuus.
- Ja 20 % turvotus on hyvä useimmissa tapauksissa pöydissä. Eli sinun ei pitäisi huolehtia ja pakata tätä taulukkoa.
Selvitimme, kuinka tunnistamme mukanamme turvonneet taulukot, kun ne ovat turvonneet hyödyttömästä tiedosta.
Nyt turvotuksen korjaamisesta:
- Jos meillä on pieni levy ja hyvät levyt, eli gigatavun levyllä, on täysin mahdollista käyttää VACUUM FULLia. Hän ottaa sinulta eksklusiivisen lukon muutamaksi sekunniksi, ja okei, mutta hän tekee kaiken nopeasti ja ankarasti. Mitä VACUUM FULL tekee? Se vie pöydälle eksklusiivisen lukon ja kirjoittaa uudelleen elävät rivit vanhoista taulukoista uuteen taulukkoon. Ja lopulta hän korvaa ne. Poistaa vanhat tiedostot, korvaa vanhat uusilla. Mutta työnsä ajaksi se vie pöydälle ainutlaatuisen lukon. Tämä tarkoittaa, että et voi tehdä tälle taulukolle mitään: älä kirjoittaa siihen, lukea siihen tai muokata sitä. Ja VACUUM FULL vaatii lisää levytilaa tietojen kirjoittamiseen.
- Seuraava työkalu . Periaatteeltaan se on hyvin samanlainen kuin VACUUM FULL, koska se myös korvaa vanhojen tiedostojen tiedot uusiin ja korvaa ne taulukossa. Mutta samalla se ei ota eksklusiivista lukkoa pöydälle aivan työnsä alussa, vaan ottaa sen vasta sillä hetkellä, kun sillä on valmiita tietoja tiedostojen korvaamiseksi. Siinä on samat levyresurssivaatimukset kuin VACUUM FULL. Tarvitset ylimääräistä levytilaa, ja tämä on joskus kriittistä, jos sinulla on teratavuisia taulukoita. Ja hän on melko ahne prosessorin suhteen, koska hän työskentelee aktiivisesti I / O: n kanssa.
- Kolmas apuohjelma on . Se käsittelee resursseja huolellisemmin, koska se toimii hieman eri periaatteilla. pgcompacttablen pääoletus on, että se siirtää kaikki elävät rivit taulukon alkuun taulukon päivityksillä. Ja sitten se aloittaa tyhjiön tässä pöydässä, koska tiedämme, että meillä on elävät rivit alussa ja kuolleet rivit lopussa. Ja itse tyhjiö katkaisee tämän hännän, eli se ei vaadi paljon ylimääräistä levytilaa. Ja samalla resurssit voivat silti puristaa sitä.
Kaikki työkaluilla.
Jos bloat-aihe on mielestäsi kiinnostava syvemmälle syventymisen kannalta, tässä on joitain hyödyllisiä linkkejä sinulle:
- on kollegani raportti. Se on yleinen siitä, mihin Postgresin paikka menee työnsä ja elämänsä aikana. Ja siellä on erittäin suuri ja yksityiskohtainen tekninen kappale DBA: ille bloatista.
- on linkki arkistoon, johon tallennamme joukon hyödyllisiä skriptejä tietokannan tilan tarkistamiseksi. Sieltä löydät bloat-hakukomentosarjat.
- и linkkejä työkaluihin, jotka auttavat sinua puristamaan levyt.
- Tämä on kollegani postaus. Siellä hän analysoi bloatin melko vakavasti ja teknisesti yksityiskohtaisesti jo järjestelmänvalvojia lähellä olevalla tasolla.
Tässä yritin näyttää kauhutarinaa kehittäjille, koska he ovat tietokantojen suoria asiakkaitamme ja heidän on ymmärrettävä mihin ja mihin toimet johtavat. Toivottavasti onnistuin. Kiitos huomiostasi!
kysymykset
Kiitos raportista! Puhuit siitä, kuinka ongelmat voidaan tunnistaa. Miten heitä voidaan varoittaa? Eli minulla oli tilanne, jossa pyynnöt roikkuivat paitsi siksi, että ne kääntyivät joidenkin ulkopuolisten palvelujen puoleen. Se oli vain villejä liitoksia. Oli joitain pieniä, harmittomia pyyntöjä, jotka viipyivät päivän, ja sitten alkoivat tehdä jonkinlaista hölynpölyä. Eli se on hyvin samanlainen kuin kuvailet. Kuinka seurata sitä? Istu ja katso jatkuvasti, mikä pyyntö on jumissa? Miten tämä voidaan estää?
Tässä tapauksessa tämä on yrityksesi ylläpitäjien tehtävä, ei välttämättä DBA:n tehtävä.
Olen järjestelmänvalvoja.
PostgreSQL:ssä on näkymä nimeltä pg_stat_activity, joka näyttää odottavat kyselyt. Ja näet kuinka kauan se roikkuu siellä.
Pitääkö minun tulla 5 minuutin välein katsomaan?
Asenna cron ja tarkista. Jos sinulla on pitkä pyyntö, kirjoita kirje ja se on siinä. Eli sinun ei tarvitse katsoa silmilläsi, tämä voidaan automatisoida. Saat kirjeen, vastaat siihen. Tai voit ampua automaattisesti.
Onko olemassa selviä syitä miksi näin tapahtuu?
Olen listannut joitain. Muita monimutkaisempia esimerkkejä. Ja siitä voi tulla pitkä keskustelu.
Kiitos raportista! Halusin selventää pg_repack-apuohjelmaa. Jos se ei vaadi eksklusiivista lukkoa, niin...
Hän tekee ainutlaatuisen lukon.
... niin saatan menettää tietoja. Eikö sovellukseni pitäisi tallentaa mitään tällä hetkellä?
Ei, se toimii hiljaa pöydän kanssa, eli pg_repack siirtää ensin kaikki siellä olevat live-rivit. Luonnollisesti taulukossa on meneillään jonkinlainen ennätys. Hän vain heittää tämän poninhäntän.
Eli tekeekö hän sen vielä lopussa?
Lopulta näiden tiedostojen vaihtaminen vaatii eksklusiivisen lukon.
Onko se nopeampi kuin VACUUM FULL?
VACUUM FULL, kun se alkoi, otti heti ainutlaatuisen lukon. Ja ennen kuin hän tekee kaiken, hän ei päästä häntä menemään. Ja pg_repack ottaa yksinomaisen lukon vain tiedostojen korvaamisen yhteydessä. Tässä vaiheessa et kirjoita sinne, mutta tiedot eivät katoa, kaikki on kunnossa.
Hei! Puhuit autotyhjiön työstä. Siellä oli kaavio tietueen punaisista, keltaisista ja vihreistä soluista. Eli keltaiset - hän merkitsi ne poistetuiksi. Ja sen seurauksena voit kirjoittaa niihin jotain uutta?
Joo. Postgres ei poista rivejä. Hänellä on sellainen erityispiirre. Jos päivitimme rivin, merkitsimme vanhan poistetuksi. Tapahtumatunnus, joka muutti tämän rivin, tulee sinne, ja kirjoitamme uuden rivin. Ja meillä on istuntoja, jotka voivat mahdollisesti lukea niitä. Jossain vaiheessa niistä tulee aika vanhoja. Ja automaattisen tyhjiön ydin on, että se kulkee näiden linjojen läpi ja merkitsee ne tarpeettomiksi. Ja siellä voit ylikirjoittaa tiedot.
Ymmärrän. Mutta kysymys ei ole siitä. En suostunut. Oletetaan, että meillä on pöytä. Siinä on vaihtelevan kokoisia kenttiä. Ja jos yritän lisätä jotain uutta, se ei ehkä yksinkertaisesti sovi vanhaan soluun.
Ei, siellä joka tapauksessa koko rivi päivitetään. Postgresilla on kaksi säilytysmallia. Se valitsee tietotyypistä. On dataa, joka on tallennettu suoraan taulukkoon, ja on myös tos-tietoja. Nämä ovat suuria tietomääriä: teksti, json. Ne säilytetään erillisissä tableteissa. Ja näiden tablettien mukaan tapahtuu sama tarina turvotuksen kanssa, eli kaikki on samaa. Ne on vain lueteltu erikseen.
Kiitos raportista! Kuinka hyväksyttävää on käyttää lausekkeen aikakatkaisupyyntöjä keston rajoittamiseen?
Erittäin hyväksyttävää. Käytämme sitä kaikkialla. Ja koska meillä ei ole omia palveluita, tarjoamme etätukea, asiakkaita on aika monenlaisia. Ja kaikki ovat tähän melko tyytyväisiä. Eli meillä on työpaikkoja cronissa, joka tarkistaa. Se on vain se, että istuntojen kesto neuvotellaan asiakkaan kanssa, jota ennen emme naulaa. Se voi olla minuutti, se voi olla 10 minuuttia. Se riippuu alustan kuormituksesta ja sen tarkoituksesta. Mutta me kaikki käytämme pg_stat_activity.
Kiitos raportista! Yritän kokeilla raporttiasi sovelluksissani. Ja näyttää siltä, että aloitamme tapahtuman kaikkialla ja teemme sen nimenomaisesti kaikkialla. Jos jokin poikkeus, niin kaikki samat palautukset tapahtuvat. Ja sitten ajattelin. Loppujen lopuksi kauppa ei voi alkaa nimenomaisesti. Tämä taitaa olla vihje tytölle. Jos teen vain tietueen päivityksen, alkaako tapahtuma PostgreSQL:ssä ja päättyykö se vasta, kun yhteys katkeaa?
Jos puhut nyt sovellustasosta, se riippuu käyttämästäsi ohjaimesta, käytettävästä ORM:sta. Siellä on paljon asetuksia. Jos automaattinen sitoutuminen on käytössä, tapahtuma alkaa siellä ja sulkeutuu välittömästi.
Eli sulkeutuuko se heti päivityksen jälkeen?
Se riippuu asetuksista. Nimesin yhden asetuksen. Tämä on automaattinen vahvistus. Hän on aika yleinen. Jos se on käytössä, tapahtuma avattiin ja suljettiin. Ellei nimenomaisesti sanonut "aloita tapahtuma" ja "lopeta tapahtuma", vaan yksinkertaisesti käynnistit pyynnön istuntoon.
Hei! Kiitos raportista! Kuvittele, että meillä on tietokanta, joka turpoaa ja turpoaa ja sitten palvelimen tila loppuu. Onko olemassa työkaluja tilanteen korjaamiseksi?
Paikka palvelimella on hyvällä tavalla tarkkailtava.
Esimerkiksi DBA meni juomaan teetä, oli lomakeskuksessa jne.
Kun tiedostojärjestelmä luodaan, luodaan ainakin jonkin verran varatilaa, johon ei kirjoiteta tietoja.
Entä jos se on täysin nolla?
Siellä sitä kutsutaan varatuksi tilaksi, eli se voidaan vapauttaa, ja riippuen siitä, kuinka suuri se luotiin, saat vapaata tilaa. Oletuksena en tiedä kuinka monta niitä on. Ja toisessa tapauksessa toimita levyjä, jotta sinulla on paikka palautusoperaatiolle. Voit poistaa taulukon, jota et taatusti tarvitse.
Eikö muita työkaluja ole?
Se on aina käsintehty. Ja siinä paikassa paljastetaan, mitä siellä on parempi tehdä, koska on dataa, joka on kriittistä, on ei-kriittistä. Ja jokainen tietokanta ja sovellus, joka toimii sen kanssa, riippuu yrityksestä. Se päätetään aina paikan päällä.
Kiitos raportista! Minulla on kaksi kysymystä. Ensin näytit dioja, joissa näytettiin, että ripustettujen tapahtumien tapauksessa sekä taulukkotilan määrä että indeksin koko kasvavat. Ja edelleen raportissa oli joukko apuohjelmia, jotka pakkaavat tabletin. Ja entä indeksi?
Ne myös pakkaavat.
Mutta tyhjiö ei vaikuta indeksiin?
Jotkut toimivat indeksin kanssa. Esimerkiksi pg_rapack, pgcompacttable. Tyhjiö luo indeksit uudelleen, vaikuttaa niihin. VACUUM FULLin ydin on kaiken päällekirjoittaminen, eli se toimii kaikkien kanssa.
Ja toinen kysymys. En ymmärtänyt, miksi replikoiden raportit riippuvat niin paljon itse replikaatiosta. Minusta näytti, että raportit lukevat ja replikointi kirjoittaa.
Mikä aiheuttaa replikointiristiriidan? Meillä on mestari, jolla prosessit tapahtuvat. Meillä on tyhjiö. Autovacuum itse asiassa, mitä se tekee? Hän leikkaa pois vanhoja linjoja. Jos meillä on tällä hetkellä pyyntö kopiossa, joka lukee nämä vanhat rivit, ja Masterissa oli tilanne, että autotyhjiö merkitsi nämä rivit mahdollisiksi uudelleenkirjoitusta varten, kirjoitimme ne päälle. Ja saimme datapaketin, kun meidän on kirjoitettava uudelleen pyynnön tarvitsemat rivit replikaan, niin replikointiprosessi odottaa määrittämääsi aikakatkaisua. Ja sitten PostgreSQL päättää, mikä on sille tärkeämpää. Ja replikointi on hänelle tärkeämpää kuin pyyntö, ja hän ampuu pyynnön tehdä nämä muutokset replikaan.
Andrew, minulla on kysymys. Nämä upeat grafiikat, joita näytit esityksen aikana, ovatko nämä apuohjelmasi työn tulos? Miten kaaviot tehtiin?
Tämä on palvelu .
Onko tämä kaupallinen tuote?
Joo. Tämä on kaupallinen tuote.
Lähde: will.com