{"id":81089,"date":"2020-05-11T01:42:24","date_gmt":"2020-05-10T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov"},"modified":"2020-05-11T01:42:24","modified_gmt":"2020-05-10T23:42:24","slug":"tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov","title":{"rendered":"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat'i tekkimiseni PostgreSQL-is. Andrei Salnikovi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><strong>Tutvustan 2016. aasta alguses Andrei Salnikovi esitatud ettekande \"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad bloat'i PostgreSQL-is\" t\u00f5lgendust.<\/strong><\/p>\n<p><\/p>\n<p>Selles ettekandes k\u00e4sitlen 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\u00fcsteemi j\u00f5udluse languse algus, kuigi algselt ei olnud mingeid n\u00e4iliselt halbu m\u00e4rke.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/a9e199bfe2e01c76966b32868790f8f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Tere tulemast! See ettekande ei ole nii tehniline kui eelmine minu kolleegi esitlus. See ettekande on suunatud peamiselt tagaplaneedi s\u00fcsteemide arendajatele, kuna meil on piisavalt palju kliente. Ja k\u00f5ik nad teevad samu vigu. Nendest r\u00e4\u00e4gin ma teile. Selgitan, millistele fataalsetele ja halbadele tagaj\u00e4rgedele need vead viivad. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/c6c84dbafc595ae3068cd8bf804ccee7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Miks tekivad vead? Need tekivad kahe p\u00f5hjusel: m\u00f5nikord lootuses, et \u00e4kki l\u00e4heb \u00f5nneks, ja teadmatusest mehhanismide osas, mis toimuvad andmebaasi ja rakenduse vahel, samuti andmebaasi enda sees. <\/p>\n<p><\/p>\n<p>Toon teile kolm n\u00e4idet koos kohutavate piltidega, kuidas k\u00f5ik halvemaks l\u00e4heb. R\u00e4\u00e4gin l\u00fchidalt mehhanismist, mis seal toimub. Ja kuidas nendega toime tulla, kui nad juhtuvad, ja milliseid ennetavaid meetodeid kasutada vigade v\u00e4ltimiseks. R\u00e4\u00e4gin abistavatest t\u00f6\u00f6riistadest ja annan kasulikke linke. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/b0230d992f5b44f0e542df2e4b4d526f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kasutasin testandmebaasi, kus mul oli kaks tabelit. \u00dcks tabel klientide arvetega, teine nende arvete tehingutega. Ja teatud perioodilisusega uuendame nende arvetel olevaid j\u00e4\u00e4ke.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/1d2a21278b095b07546e1bb870819dbf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tabeli algandmed: see on piisavalt v\u00e4ike, 2 MB. Andmebaasi ja konkreetselt tabeli vastuse aeg on samuti v\u00e4ga hea. Ja p\u00e4ris hea koormus \u2013 2000 tehingut sekundis tabeli kohta.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/dea5a4b1ac7952f8cfed0e2e1cfc10dd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja kogu selle ettekande jooksul n\u00e4itan teile graafikuid, et oleks selge, mis toimub. Alati on 2 slaidi graafikut. Esimene slaid \u2013 see, mis toimub serveris \u00fcldiselt. <\/p>\n<p><\/p>\n<p>Ja antud olukorras n\u00e4eme, et meie tabel on t\u00f5eliselt v\u00e4ike. Indeks on v\u00e4ike, 2 MB. See on esimene graafik vasakul. <\/p>\n<p><\/p>\n<p>Keskmine vastuse aeg serveris on samuti stabiilne, v\u00e4ikene. See on \u00fclemises paremas graafikus. <\/p>\n<p><\/p>\n<p>Vasaku alumise diagrammi peal on k\u00f5ige pikemad tehingud. N\u00e4eme, et tehingud t\u00e4idetakse kiiresti. Ja automaatne vaakum ei t\u00f6\u00f6ta veel, kuna see oli starditest. Edasi hakkab see t\u00f6\u00f6le ja on meile kasulik.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/9e9b46acd9a878ff70ca4a7850adff09.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Teine slaid on alati p\u00fchendatud katsetatavale tabelile. Selles olukorras uuendame pidevalt kliendi kontode j\u00e4\u00e4ke. Ja me n\u00e4eme, et keskmine reageerimisaeg uuendustegevuses on piisavalt hea, v\u00e4hem kui millisekund. N\u00e4eme, et protsessori ressursid (see on paremas \u00fclanurgas olev diagramm) on samuti tasakaalustatult ja piisavalt v\u00e4ikesed. <\/p>\n<p><\/p>\n<p>Paremas alumises diagrammis n\u00e4itab, kui palju operatiivset ja kettam\u00e4lu me otsime meie vajaliku rida, enne kui selle uuendame. Ja tabeli operatsioonide arv \u2013 2000 sekundis, nagu ma \u00fctlesin alguses. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/84760d52716209b8dcfffb462c67a8e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd toimub meil trag\u00f6\u00f6dia. Mingil p\u00f5hjusel tekib pikk unustatud tehing. P\u00f5hjused on tavaliselt k\u00f5ik banaalsed: <\/p>\n<p><\/p>\n<ul>\n<li>\u00dcks levinumaid p\u00f5hjusi on see, et me rakenduse koodis alustasime v\u00e4lisesse teenusesse p\u00f6\u00f6rdumist. Ja see teenus ei vasta meile. St avasime tehingu, tegime muudatuse andmebaasis ja l\u00e4ksime rakendusest e-kirju lugema v\u00f5i m\u00f5nda teise teenusesse meie infrastruktuuris, ja see ei vasta meile mingil p\u00f5hjusel. Ja meil j\u00e4i seanss seisundisse \u2013 ei ole teada, millal see lahtiseks saab.<\/li>\n<li>Teine olukord, kui meie koodis mingil p\u00f5hjusel tekkis erand. Ja me ei t\u00f6\u00f6tanud v\u00e4lja tehingu sulgemist erandi korral. Ja meil tekkis rippuv seanss avatud tehinguga. <\/li>\n<li>Ja viimane \u2013 see on ka \u00fcsna levinud juhtum. See on kehva kvaliteediga kood. M\u00f5ned raamistikud avavad tehingu. See ripub ja te ei pruugi rakenduses teada, et see on riputatud. <\/li>\n<\/ul>\n<p><\/p>\n<p>Kuhu need asjad viivad? <\/p>\n<p><\/p>\n<p>Sellest tulenevalt hakkavad meie tabelid ja indeksid j\u00e4rsult paisuma. See on just see bloati efekt. Andmebaasi jaoks v\u00e4ljendub see selles, et meie andmebaasi reageerimisaeg suureneb j\u00e4rsult, koormus andmebaasi serverile t\u00f5useb. Ja tulemuseks hakkab rakendus kannatama. Sest kui te kulutasite koodis 10 millisekundit andmebaasi p\u00e4ringule, 10 millisekundit oma loogika jaoks, siis teie funktsioon t\u00f6\u00f6tas 20 millisekundit. Ja n\u00fc\u00fcd on teie olukord t\u00e4iesti kurb. <\/p>\n<p><\/p>\n<p>Ja vaatame, mis toimub. Vasak alamm\u00f5\u00f5tja n\u00e4itab, et meil on pikad tehingud. Ja kui vaatame vasakut \u00fclemist graafikut, siis n\u00e4eme, et meie kahe megabaidi suurune tabel on j\u00e4rsku t\u00f5usnud 300 megabaidini. Samas andmete hulk tabelis ei muutunud, st seal on palju r\u00e4mpsu.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/b1947f6487e440a770a1251a955e62d2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00dcldine olukord keskmise serveri vastuseaja osas on samuti muutunud mitmes j\u00e4rjestikus. St k\u00f5ik serverip\u00e4ringud on t\u00f5siselt kasvanud. Ja samal ajal on k\u00e4ima l\u00e4inud Postgresi sisemised protsessid autovakuumi n\u00e4ol, mis \u00fcritavad midagi teha ja v\u00f5tavad ressursse.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/8e91f035d1dd04e72e842d714cc611a5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mis meie tabeliga juhtub? T\u00e4pselt sama asi. Keskmine vastuseaeg tabeli jaoks on t\u00f5usnud mitmes j\u00e4rjestikus. Kui r\u00e4\u00e4kida ressursside tarbimisest, siis n\u00e4eme, et protsessorile on koormus j\u00e4rsult suurenenud. See on paremal \u00fclemisel graafikul. Ja see suurenemine toimub, kuna protsessor peab otsima palju kasutut rida \u00fche vajaliku leidmiseks. See on paremal alumisel graafikul. Ja tulemuseks on see, et meie p\u00e4ringute arv sekundis hakkas j\u00e4rsult v\u00e4henema, kuna andmebaas ei suuda t\u00f6\u00f6delda sama palju p\u00e4ringuid. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/424685ce852bc5f3ef77151f8d3d7289.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Peame uuesti ellu \u00e4rkama. Uurime internetist, et pikad tehingud toovad probleeme. Leiame ja l\u00f5petame selle tehingu. Ja siis muutub k\u00f5ik normaalseks. K\u00f5ik t\u00f6\u00f6tab nagu peab. <\/p>\n<p><\/p>\n<p>Me rahunesime, kuid m\u00f5ne aja p\u00e4rast hakkame m\u00e4rkama, et rakendus ei t\u00f6\u00f6ta enam nagu oli enne avariid. P\u00e4ringud t\u00f6\u00f6deldakse siiski aeglasemalt, oluliselt aeglasemalt. \u00dcksk\u00f5ik kui poolteist kuni kaks korda aeglasemalt, mis puudutab minu n\u00e4idet. Serveri koormus on samuti k\u00f5rgem kui avariieelsel ajal. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/ee3037719a31f8d18fc42745716c4da5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00fcsimus on: \u201eMis toimub andmebaasiga sel hetkel?\u201c. Andmebaasis toimub j\u00e4rgnev olukord. Tehingute graafikul n\u00e4ete, et see on peatunud ja seal t\u00f5epoolest ei ole pikki tehinguid. Kuid tabeli suurus avarii ajal on saanud fataalselt suureks. Ja sellest ajast alates ei ole see v\u00e4henenud. Keskmine aeg andmebaasi jaoks on stabiliseerunud. Ja vastused tunduvad liikuvat normaalselt, meie jaoks vastuv\u00f5etava kiirusena. Autovakuum on muutunud aktiivsemaks ja hakkas tegema midagi tabeliga, kuna tal on vaja t\u00f6\u00f6delda suuremat hulka andmeid. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/f6205242c4024dc3ed4cade5844dbf76.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetsete arve tabeli osas, kus me muudame j\u00e4\u00e4ke: p\u00e4ringu vastusaeg on n\u00e4iliselt naasnud normaalsusesse. Kuid tegelikult on see poolteise korra v\u00f5rra k\u00f5rgem.<\/p>\n<p><\/p>\n<p>Ja protsessori koormuse osas n\u00e4eme, et protsessori koormus ei ole naasnud enne avariid vajaliku tasemeni. P\u00f5hjused peituvad just paremas alanurgas olevas graafikus. On n\u00e4ha, et seal toimub teatud koguse m\u00e4lu \u00fcletamine. See t\u00e4hendab, et vajaliku rea leidmiseks kulutame andmebaasi serveri ressursse m\u00f5ttetu andmete t\u00f6\u00f6tlemise t\u00f5ttu. Tehingute arv sekundis on stabiliseerunud. <\/p>\n<p><\/p>\n<p>\u00dcldiselt on k\u00f5ik h\u00e4sti, aga olukord on halvem kui enne. Selge andmebaasi deklareerimine meie rakenduse tagaj\u00e4rjel, mis t\u00f6\u00f6tab selle andmebaasiga. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/0dfc9cd453fd84bc639ffd99cf189fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja et aru saada, mis seal toimub, kui te ei olnud eelmisel ettekandel, siis n\u00fc\u00fcd natuke teooriat. Teooria sisemisest protsessist. Miks on autovakuum ja mida see teeb?<\/p>\n<p><\/p>\n<p>L\u00fchidalt arusaamiseks. Teatud hetkel on meil tabel. Tabelis on meil read. Need read v\u00f5ivad olla aktiivsed, elavad, meie jaoks vajalikud. Joonisel on nad rohelise v\u00e4rviga m\u00e4rgitud. Ja on surnud read, mis on juba t\u00f6\u00f6d teinud, on uuendatud, millele on lisatud uusi kirjeid. Ja need on m\u00e4rgitud, et nad ei ole andmebaasile enam huvitavad. Kuid nad j\u00e4\u00e4vad tabelisse Postgresi erip\u00e4ra t\u00f5ttu.<\/p>\n<p><\/p>\n<p>Miks on vajalik autovakuum? Autovakuum tuleb teatud hetkel, p\u00f6\u00f6rdub andmebaasi poole ja k\u00fcsib: \"Palun anna mulle k\u00f5ige vanema tehingu id, mis on praegu andmebaasis avatud.\" Andmebaas tagastab selle id. Ja autovakuum tuginedes sellele l\u00e4bib tabeli read. Ja kui ta n\u00e4eb, et teatud read on muutunud palju vanemate tehingute t\u00f5ttu, siis on tal \u00f5igus neid m\u00e4rgistada ridadena, mida saame tulevikus uuesti kasutada, kirjutades sinna uusi andmeid. See on taustprotsess.<\/p>\n<p><\/p>\n<p>Selle ajal j\u00e4tkame andmebaasiga t\u00f6\u00f6tamist, j\u00e4tkame tabelis muudatuste tegemist. Ja nendele ridadele, mida saame uuesti kasutada, kirjutame uusi andmeid. Nii et meil tekib ringk\u00e4ik, st seal tekib pidevalt m\u00f5ningaid vanu surnud ridad, mille asemel kirjutame uusi ridu, mis meile vajalikud. Ja see on PostgreSQL-i t\u00f6\u00f6tamise normaalne seisund.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/98dd4451a7ca5f418775f72822c2840c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mis juhtus avarii ajal? Kuidas see protsess seal toimus?<\/p>\n<p><\/p>\n<p>Meil oli mingisugune tabel, m\u00f5ned read olid elavad ja m\u00f5ned surnud. Siis tuli automaatne vaakum. See k\u00fcsis andmebaasist, milline on meie vanim tehing ja mis on selle ID. Ta sai selle ID, mis v\u00f5ib olla mitu tundi vana v\u00f5i k\u00fcmme minutit vana. See s\u00f5ltub sellest, kui suur on koormus teie andmebaasis. Ja ta l\u00e4ks otsima ridu, mida ta saaks m\u00e4rgistada taaskasutatavateks. Ja ta ei leidnud meie tabelis selliseid ridu. <\/p>\n<p><\/p>\n<p>Aga samal ajal j\u00e4tkame me tabeliga t\u00f6\u00f6tamist. Teeme seal midagi, uuendame, muudame andmeid. Ja mida andmebaas sel ajal teeb? Tal ei j\u00e4\u00e4 muud \u00fcle, kui kirjutada uusi ridu olemasoleva tabeli l\u00f5ppu. Ja seel\u00e4bi meie tabeli suurus hakkab paisuma. <\/p>\n<p><\/p>\n<p>Tegelikult vajame me t\u00f6\u00f6tamiseks rohelisi ridu. Aga sellise probleemi ajal on meil nii, et roheliste ridade protsent kogu tabeli mahus on \u00e4\u00e4rmiselt madal. <\/p>\n<p><\/p>\n<p>Ja kui me sooritame p\u00e4ringu, peab andmebaas l\u00e4bi k\u00e4ima k\u00f5ik read: nii punased kui ka rohelised, et leida vajalik rida. Ja tabeli paisumise m\u00f5ju, mis sisaldab kasutu teavet, nimetatakse \"bloat\", mis s\u00f6\u00f6b \u00e4ra meie kettaruumi. Kas m\u00e4letate, oli 2 MB, n\u00fc\u00fcd on 300 MB? N\u00fc\u00fcd vahetage megabaitide asemel gigabaitide ja te v\u00f5ite kiiresti kaotada kogu oma kettaruumi.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/fe7cb6b5c99610744ebcfe5ad7235d1e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Millised tagaj\u00e4rjed v\u00f5ivad meile olla? <\/p>\n<p><\/p>\n<ul>\n<li>Minu n\u00e4ites kasvas tabel ja indeks 150 korda. M\u00f5nel meie kliendil on olnud isegi t\u00f5sisemaid juhtumeid, kui kettaruumi hakkas otsa saama. <\/li>\n<li>Tabelite suurus ei v\u00e4hene kunagi iseenesest. Automaatne vaakum v\u00f5ib m\u00f5nel juhul tabeli sabajupi \u00e4ra l\u00f5igata, kui seal on ainult surnud read. Aga kuna toimub pidev rotatsioon, v\u00f5ib \u00fcks roheline rida l\u00f5pus j\u00e4\u00e4da seisma ja mitte uuenduda, samas kui k\u00f5ik teised kirjutatakse kuskil tabeli algusesse. Aga see on nii ebat\u00f5en\u00e4oline s\u00fcndmus, et teie tabel ise mingil m\u00e4\u00e4ral v\u00e4heneks, mis ei ole midagi, millele tasuks loota. <\/li>\n<li>Andmebaas peab l\u00e4bi t\u00f6\u00f6tama kogu hulga m\u00f5ttetuid ridu. Ja me kulutame kettaruumi, kulutame protsessori ressursse ja elektrit. <\/li>\n<li>Ja see m\u00f5jutab otseselt meie rakendust, kuna kui alguses kulutasime p\u00e4ringule 10 millisekundit ja meie koodile samuti 10 millisekundit, siis avarii ajal hakkasime kulutama p\u00e4ringule \u00fche sekundi ja koodile 10 millisekundit, st rakenduse j\u00f5udlus v\u00e4henes oluliselt. Kui avarii l\u00f5petati, kulus meil 20 millisekundit p\u00e4ringule ja 10 millisekundit koodile. See t\u00e4hendab, et meie j\u00f5udlus langes endiselt 1,5 korda. Ja see k\u00f5ik oli tingitud \u00fchest tehingust, mis j\u00e4i pidama, ilmselt meie enda s\u00fc\u00fcl. <\/li>\n<li>Ja k\u00fcsimus on: 'Kuidas k\u00f5ik tagasi saada?', et meie s\u00fcsteem toimiks taas sama kiiresti nagu enne avariid. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/1bf46e8cd9b28ca2862f978f2ca85819.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selleks on olemas kindel t\u00f6\u00f6ts\u00fckkel, mida tuleb j\u00e4rgida. <\/p>\n<p><\/p>\n<p>Esiteks peame leidma probleemsed tabelid, mis on paisunud. Me m\u00f5istame, et teatud tabelitesse toimub aktiivsem kirjutamine, teistesse aga v\u00e4hem. Selleks kasutatakse laiendust <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/pgstattuple.html\">pgstattuple<\/a><\/noindex>. P\u00e4rast selle laienduse installimist saate kirjutada p\u00e4ringuid, mis aitavad leida piisavalt paisunud tabeleid. <\/p>\n<p><\/p>\n<p>P\u00e4rast nende tabelite leidmist tuleb need kokku v\u00f5tta. Selleks on olemas t\u00f6\u00f6riistad. Meie ettev\u00f5ttes kasutame kolme t\u00f6\u00f6riista. Esimene on sisseehitatud VACUUM FULL. See on karm, range ja halastamatu, kuid m\u00f5nikord on see v\u00e4ga kasulik. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/reorg\/pg_repack\">Pg_repack<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pgcompacttable\">pgcompacttable<\/a><\/noindex> \u2013 need on kolmandate osapoolte utiliidid tabelite kokku pakkumiseks. Need on andmebaasi suhtes \u00f5rnemad. <\/p>\n<p><\/p>\n<p>Neid kasutatakse s\u00f5ltuvalt sellest, mis teile mugavam on. Kuid sellest r\u00e4\u00e4gin ma l\u00f5pupoole. Peamine on see, et meil on kolm t\u00f6\u00f6riista. On, mida valida. <\/p>\n<p><\/p>\n<p>P\u00e4rast k\u00f5igi parandamist ja veendumist, et k\u00f5ik on h\u00e4sti, peame teadma, kuidas tulevikus selliseid olukordi \u00e4ra hoida:<\/p>\n<p><\/p>\n<ul>\n<li>Seda on \u00fcsna lihtne v\u00e4ltida. Tuleb j\u00e4lgida seansside kestvust Master-serveris. <strong>Eriti ohtlikud seansid on olukorras idle in transaction<\/strong>. Need on need, kus avati tehing, tehti midagi ja mindi minema v\u00f5i lihtsalt j\u00e4i pidama, kadus koodi sisse. <\/li>\n<li>Ja teie, kui arendajad, peate oma koodi testima selliste olukordade tekkimise hetkel. See ei ole keeruline. See on kasulik kontroll. Te v\u00e4ltite paljusid 'laste' probleeme, mis on seotud pikemate tehingutega. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/d55465d96c4018db733954867d23aaba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nendel graafikutes soovisin n\u00e4idata, kuidas tabel ja andmebaasi k\u00e4itumine muutusid p\u00e4rast seda, kui ma l\u00e4ksin selles konkreetses juhul VACUUM FULL tabelis. See pole mul tootmisserver.<\/p>\n<p><\/p>\n<p>Tabeli suurus naasis kohe normaalsesse t\u00f6\u00f6olekusse paariks megabaitiks. See ei avaldanud keskmisele serveri vastusajale suurt m\u00f5ju. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/cbb07ad24dba899395223d1ca25e438e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuid meie katsetatava tabeli puhul, kus uuendasime kontode j\u00e4\u00e4ke, n\u00e4eme, et keskmine vastusaja andmete uuendamise p\u00e4ringus on v\u00e4henenud enne avariide taset. Protsessori ressursid, mida selle p\u00e4ringu t\u00e4itmiseks tarbiti, on samuti langenud enne avariide taset. Ja paremal alumises graafikus n\u00e4eme, et n\u00fc\u00fcd leiame kohe t\u00e4pselt selle rea, mida vajame, ilma et peaksime l\u00e4bi k\u00e4ima hulk surnud reasid, mis olid enne tabeli tihendamist. Ja keskmine p\u00e4ringute aeg on peaaegu samal tasemel p\u00fcsinud. Aga siin on mul pigem minu seadme viga.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/c1d90c5442e02fce209dc40e048a8ca2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sellega esimene lugu l\u00f5ppes. See on k\u00f5ige levinum. Ja see juhtub k\u00f5igil, s\u00f5ltumata kliendi kogemusest v\u00f5i kui kvalifitseeritud programmistid seal on. Varem v\u00f5i hiljem see juhtub. <\/p>\n<p><\/p>\n<p>Teine lugu, kus jagame koormust ja optimeerime serveri ressursse.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/cda421c554d1329107ddc935045cc1b9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Me oleme juba kasvanud ja saanud t\u00f5sisteks m\u00e4ngijateks. Ja m\u00f5istame, et meil on replikatsioon ja oleks hea koormust tasakaalustada: kirjutades Meistrile ja lugedes replikatsioonilt. See olukord tekib tavaliselt, kui soovime koostada m\u00f5ningaid aruandeid v\u00f5i ETL. Ja \u00e4ri on selle \u00fcle v\u00e4ga r\u00f5\u00f5mus. Nad soovivad v\u00e4ga erinevaid aruandeid koos keeruka anal\u00fc\u00fctikaga. <\/li>\n<li>Aruanded on mitu tundi, kuna keerukat anal\u00fc\u00fcsi ei saa sekundite jooksul arvutada. Me, kui julged poisid, kirjutame koodi. Teeme rakenduses sisestusi, et me kirjutame Meistrile, aruandeid teeme replikatsioonilt. <\/li>\n<li>Jagame koormust. <\/li>\n<li>K\u00f5ik t\u00f6\u00f6tab suurep\u00e4raselt. Me oleme tublid. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/e94c8c492197a5015ac8aae79389a4c2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas see olukord v\u00e4lja n\u00e4eb? Konkreetselt nendel graafikutel lisasin ma veel replikatsiooniga tehingute kestuse. K\u00f5ik \u00fclej\u00e4\u00e4nud graafikud kuuluvad ainult Meistriserverile. <\/p>\n<p><\/p>\n<p>Raportide tabel minu k\u00e4esoleval hetkel on kasvanud. Neid on rohkem. N\u00e4eme, et serveri keskmine reageerimisaeg on stabiilne. N\u00e4eme, et replika peal on meil pikaajaline tehing, mis kestab juba 2 tundi. N\u00e4eme rahulikku automaatv\u00f5rgu t\u00f6\u00f6d, mis t\u00f6\u00f6tleb surnud ridu. Ja meie olukord on hea. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/2da8acf098d12d6f146ab9b9dcb54b81.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetselt katsetatava tabeli osas j\u00e4tkame seal kontode j\u00e4\u00e4kide v\u00e4rskendamist. Ja meil on samuti stabiilne reageerimisaeg p\u00e4ringutele, stabiilne ressursi tarbimine. Meie olukord on hea. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/3621ef723017bac6fb635caf0a5f4de6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00f5ik on h\u00e4sti seni, kuni meie raportid ei hakka pihta replikeerimise konfliktiga. Ja nad p\u00f5rkavad kokku pideva perioodilisusega. <\/p>\n<p><\/p>\n<p>Uurime internetti ja hakkame lugema, miks see juhtub. Ja leiame lahenduse. <\/p>\n<p><\/p>\n<p>Esimene lahendus on suurendada replikeerimise viivitust. Me teame, et meie raport t\u00f6\u00f6tab 3 tundi. Seame replikeerimise viivituseks 3 tundi. K\u00e4ivitame k\u00f5ik, kuid meil on siiski j\u00e4tkuvalt probleeme, et raportid m\u00f5nikord katkestatakse. <\/p>\n<p><\/p>\n<p>Soovime, et k\u00f5ik oleks t\u00e4iuslik. Uurime edasi. Ja leiame internetist suurep\u00e4rase seadistuse \u2013 hot_standby_feedback. L\u00fclitame selle sisse. Hot_standby_feedback v\u00f5imaldab meil peatada automaatv\u00f5rgu t\u00f6\u00f6 Masteris. Seega saame t\u00e4ielikult vabaneda replikeerimise konfliktidest. Ja meie raportid toimivad k\u00f5ik h\u00e4sti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/ee3c315168bdd3f392d2e8a1c5861004.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aga mis toimub sel ajal meie Master-serveriga? Master-serveris on t\u00e4ielik katastroof. Praegu vaatame graafikuid, kui l\u00fclitasin sisse m\u00f5lemad seadistused. Ja n\u00e4eme, et sessioon replika peal hakkas mingil moel m\u00f5jutama olukorda Master-serveris. Ta t\u00f5epoolest m\u00f5jutab, sest see peatas automaatv\u00f5rgu, mis puhastab surnud ridu. Meie tabeli suurus on taas t\u00f5usnud. Keskmine p\u00e4ringute t\u00e4itmise aeg kogu andmebaasis on samuti t\u00f5usnud. Automaatv\u00f5rgud on natuke pingestunud. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/980611dcce8b189dc50f422ffd3d2d72.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetselt meie tabeli osas n\u00e4eme, et andmete v\u00e4rskendamine on samuti t\u00f5usnud. Protsessori ressursi tarbimine on samuti v\u00e4ga palju suurenenud. Meie k\u00e4est on tagasi sonteerunud suur hulk surnud ja kasutut rida. Ja vastuse aeg selle tabeli osas, tehingute arv on langenud. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/a648fd313a5dccf45f0056dc13c54263.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas see v\u00e4lja n\u00e4eks, kui me ei tea, millest ma seni r\u00e4\u00e4kisin?<\/p>\n<p><\/p>\n<ul>\n<li>Alustame probleemide otsimist. Kui me kohtasime probleeme esimese osaga, siis teame, et see v\u00f5ib olla seotud pika tehinguga ja uurime Masterit. Probleem on meil Masteris. See j\u00e4relp\u00f5rutab. See kuumeneb, selle koormuse keskmine on saja ringis. <\/li>\n<li>Seal t\u00f5kked p\u00e4ringud, kuid me ei n\u00e4e seal mingeid pikaajalisi tehinguid. Ja ei saa aru, mis toimub. Ei saa aru, kus otsida. <\/li>\n<li>Kontrollime serveri riistvara. V\u00f5ib-olla on meil raid purunenud. V\u00f5ib-olla on meil m\u00e4lukaart tuksis. Midagi v\u00f5ib juhtuda. Aga ei, serverid on uued, k\u00f5ik t\u00f6\u00f6tab suurep\u00e4raselt. <\/li>\n<li>K\u00f5ik jooksevad ringi: administraatorid, arendajad ja direktor. Miski ei aita. <\/li>\n<li>Ja mingil hetkel hakkab k\u00f5ik ootamatult iseenesest taastuma. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/7d4f6417bc5cb3cec33679d843c6661d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Meil on replika ajal seal p\u00e4ring t\u00f6\u00f6tatud ja lahkunud. Saime aruande. \u00c4ri on endiselt rahul. Nagu n\u00e4eme, on meie tabel taas kasvanud ja ei plaani v\u00e4heneda. Seansside graafikul j\u00e4tsin t\u00fcki sellest pikast tehingust replikast, et saaksite hinnata, kui kaua aega kulub, kuni olukord stabiliseerub. <\/p>\n<p><\/p>\n<p>Seanss lahkus. Ja alles m\u00f5ne aja p\u00e4rast tuleb server enam-v\u00e4hem korras tagasi. Ja p\u00e4ringute keskmine vastusaeg Master-serveris normaliseerub. Sest l\u00f5puks sai autovakumeerimine v\u00f5imaluse surnud read puhastada ja m\u00e4rgistada. Ja ta hakkas oma t\u00f6\u00f6d tegema. Ja nii kiiresti kui ta seda teeb, nii kiiresti me saame end korda.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/547d195e08de1566da818150a47218eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Testitavas tabelis, kus me uuendame kontode j\u00e4\u00e4ke, n\u00e4eme t\u00e4iesti sama pilti. Keskmine konto uuendamise aeg normaliseerub ka j\u00e4rk-j\u00e4rgult. Protsessori tarbimisressursid v\u00e4henevad samuti. Ja tehingute arv sekundis naaseb normaali. Kuid taas ei normaliseeru see selliseks, nagu oli enne katastroofi. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/29372a5e9124690931485a7aea65befc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Juhul, kui me saame ikka tootmisv\u00f5imekuse languse, nagu esimesel juhul, poolteise kuni kahe korra v\u00f5rra, m\u00f5nikord isegi rohkem. <\/p>\n<p><\/p>\n<p>Me paistame, et oleme k\u00f5ik \u00f5igesti teinud. Jaotame koormust. Riistvara ei seisa. Oleme arukalt jaganud p\u00e4ringud, aga ikkagi l\u00e4ks k\u00f5ik halvasti. <\/p>\n<p><\/p>\n<ul>\n<li>Kas on soovitatav mitte lubada hot_standby_feedback? Jah, seda ei soovitata ilma heade p\u00f5hjusteta lubada. Sest see seade m\u00f5jutab otseselt Peaseeni ja peatab seal automaatse vakuumi t\u00f6\u00f6. Kui te j\u00e4tate selle lubatuks mingisuguses koopias ja unustate selle, v\u00f5ite tappa Peaseeni ning tekitada suuri probleeme rakenduses. <\/li>\n<li>Kas on soovitatav suurendada max_standby_streaming_delay? Jah, see on t\u00f5si aruannete puhul. Kui teil on kolm tundi kestnud aruanne ja te ei soovi, et see kukuks replikatsioonide konfliktide t\u00f5ttu, suurendage lihtsalt viivitust. Pikad aruanded ei vaja kunagi andmeid, mis on just n\u00fc\u00fcd andmebaasi j\u00f5udnud. Kui tegemist on kolm tundi kestva aruandega, siis k\u00e4ivitate selle vanade andmete ajavahemiku kohta. Ja kas teil on kolm tundi viivitust v\u00f5i kuus tundi viivitust \u2013 ei oma mingit t\u00e4htsust, aga te saate stabiilselt aruandeid ja ei koge nende \u00e4kilisi kukkumisi. <\/li>\n<li>Loomulikult tuleb kontrollida pikki sessioone koopiatel, eriti kui olete otsustanud lubada hot_standby_feedback koopial. Sest juhtuda v\u00f5ib \u00fcksk\u00f5ik, mis. Andsite selle koopia arendajale, et ta testiks p\u00e4ringuid. Ta kirjutas meeletu p\u00e4ringu. K\u00e4ivitas ja l\u00e4ks teed jooma, samas kui meie saime Peaseeni \u00fclekoormuse. V\u00f5i lubasime sinna vale rakenduse. Situatsioonid on mitmekesised. Sessioone koopiatel tuleb kontrollida sama hoolikalt nagu Peaseeni puhul. <\/li>\n<li>Ja kui teil on kiireid ja pikki p\u00e4ringuid koopiatel, siis on sel juhul parem koormuse jaotamiseks need jagada. See viitab streaming_delay'le. Kiirete jaoks on soovitatav kasutada \u00fchte koopiat v\u00e4ikese replikatsiooniviivitusega. Pikemate aruannete p\u00e4ringute jaoks on soovitatav kasutada koopiat, mis v\u00f5ib viibida 6 tundi v\u00f5i kuni terve p\u00e4eva. See on t\u00e4iesti normaalne olukord. <\/li>\n<\/ul>\n<p><\/p>\n<p>Eemaldame tagaj\u00e4rjed ikka sama viisi kaudu:<\/p>\n<p><\/p>\n<ul>\n<li>Otsime \u00fcles paisutatud tabelid.<\/li>\n<li>Ja surume need kokku sobivama t\u00f6\u00f6riistaga, mis meile meeldib. <\/li>\n<\/ul>\n<p><\/p>\n<p>Teine lugu on selles l\u00f5ppenud. L\u00e4hme kolmandasse lugu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/c8784e0be27883640cb8f6919a1c25e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00fcllaltki tavaline meie jaoks, kus me teeme migratsiooni. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/a04b9cd88a0e7e8a3b960ef930eb2657.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Iga tarkvaratoode kasvab. N\u00f5udmised 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. <\/li>\n<li>Vana andmevorming ei sobi. Oletame, et p\u00f6\u00f6rdume n\u00fc\u00fcd teise tabeli poole, kus mul on need kontode tehingud. Ja oletame, et need olid rubla, kuid me otsustasime suurendada t\u00e4psust ja teha neid kopeekades. Selleks peame tegema uuenduse: tehingu summaarv korrutada sajaga. <\/li>\n<li>Kaasaegses maailmas kasutame andmebaasi versioonihalduse automatiseeritud vahendeid. Oletame, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.liquibase.org\/\">Liquibase<\/a><\/noindex>. Kirjutame sinna meie migreerimise. Testime seda meie testandmebaasis. K\u00f5ik on suurep\u00e4rane. Uuendus l\u00e4heb l\u00e4bi. See blokeerib t\u00f6\u00f6 m\u00f5neks ajaks, kuid saame v\u00e4rskendatud andmed. Ja saame sellel p\u00f5hinedes uusi funktsioone k\u00e4ivitada. Oleme k\u00f5ik testinud, kontrollinud. K\u00f5ik on kinnitatud. <\/li>\n<li>Teostasime kavandatud t\u00f6\u00f6d, viisime l\u00e4bi migreerimise. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/9e046583f7b1723fc1eaf61a03900918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin on teie ees esitatud migreerimine koos uuendusega. Kuna mul on tehingud kontode l\u00f5ikes, oli tabeli suurus 15 GB. Ja kuna me uuendame iga rida, paisus tabel uuenduse t\u00f5ttu kaks korda, sest me kirjutasime iga rea \u00fcle. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/06120c98ea43d0568045e71935c23592.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Migreerimise ajal ei saanud me sellega midagi teha, kuna k\u00f5ik p\u00e4ringud sellele seisis j\u00e4rjekorras ja ootasid, kuni see uuendus l\u00f5ppeb. Kuid siinkohal tahan juhtida teie t\u00e4helepanu vertikaalsel teljel olevatele numbritele. See t\u00e4hendab, et meil oli keskmine p\u00e4ringu aeg enne migreerimist umbes 5 millisekundit ja protsessori koormus, m\u00e4ludiskilt loetud blokeerimise operatsioonide arv on v\u00e4iksem kui 7,5. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/69a3ba4d1d0cec7d39284e09e9d3055b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Viisime l\u00e4bi migreerimise ja saime j\u00e4lle probleeme. <\/p>\n<p><\/p>\n<p>Migreerimine l\u00e4ks edukalt, kuid:<\/p>\n<p><\/p>\n<ul>\n<li>Vana funktsionaalsus hakkas t\u00f6\u00f6tama aeglasemalt. <\/li>\n<li>Tabel kasvas taas suuruse poolest. <\/li>\n<li>Serveri koormus on taas suurem kui oli. <\/li>\n<li>Ja loomulikult, seni kuni me veel tegeleme heade t\u00f6\u00f6dega, oleme seda veidi parandanud. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ja see on j\u00e4lle bloat, mis rikub meie elu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/becd7cce3a1c8821c81c96257f41202b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin demonstreerin, et tabel, nagu ka eelnevatel juhtudel, ei kavatse naasta eelmistele suurustele. Serveri keskmine koormus tundub olevat vastuv\u00f5etav. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/4d703a60d43a3460bc3782d49865b690.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kui me vaatame arve tabelit, siis n\u00e4eme, et meie p\u00e4ringu keskmine aeg on kahekordistunud. Protsessori koormus ja m\u00e4lus l\u00e4bi vaadatud ridade arv on t\u00f5usnud \u00fcle 7,5, kuigi see oli alla. Protsessorite puhul t\u00f5usis see kaks korda, plokkoperatsioonide puhul aga 1,5 korda, st oleme saanud serveri j\u00f5udluse languse. Ja selle tagaj\u00e4rjel - meie rakenduse j\u00f5udluse languse. Samuti j\u00e4i kutsete arv ligikaudu samale tasemele. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/80772afa0643b29f5314a2482c9dfe0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siinkohal on oluline m\u00f5ista, kuidas \u00f5igesti selliseid migreerimise protsesse teha. Ja neid on oluline teha. Teeme neid \u00fcsna regulaarselt.<\/p>\n<p><\/p>\n<ul>\n<li>Selliseid suures mahus migreerimisi ei tehta automaatselt. Need peavad alati olema kontrolleeritud. <\/li>\n<li>Kontroll peab olema teadliku inimese poolt. Kui teie meeskonnas on andmebaasi administraator (DBA), siis las teeb seda tema. See on tema t\u00f6\u00f6. Kui ei, siis las teeb seda k\u00f5ige kogenum inimene, kes teab, kuidas andmebaasidega t\u00f6\u00f6tada. <\/li>\n<li>Uus andmebaasi skeem, isegi kui uuendame ainult \u00fchte veergu, valmistame me alati ette etappide kaupa, st enne, kui rakenduse uus versioon v\u00e4lja viiakse:<\/li>\n<li>Lisatakse uued v\u00e4ljad, kuhu salvestame just uuendatud andmed. <\/li>\n<li>Kandame andmed vanast v\u00e4ljast uude v\u00e4hehaaval. Miks me seda teeme? Esiteks kontrollime me alati selle protsessi kulgu. Teame, et oleme juba \u00fcle kandnud teatud hulga ja meil on veel nii palju \u00fcle kandmata. <\/li>\n<li>Teiseks positiivne efekt on see, et iga sellise erandi vahel sulgeme tehingu, avame uue ja see v\u00f5imaldab automaatvakumeerida tabelis, m\u00e4rgistades surnud read taaskasutamiseks. <\/li>\n<li>Ridade puhul, mis ilmuvad rakenduse t\u00f6\u00f6 k\u00e4igus (meie vana rakendus t\u00f6\u00f6tab veel), lisame katse, mis salvestab uued v\u00e4\u00e4rtused uuteks v\u00e4ljadeks. Meie puhul - see on vana v\u00e4\u00e4rtuse korrutamine saja. <\/li>\n<li>Kui me oleme t\u00e4iesti jonnakad ja tahame sama v\u00e4li, siis k\u00f5igi migreerimiste l\u00f5ppedes ja enne uue rakenduse versiooni v\u00e4ljalaskmist, lihtsalt muutame v\u00e4ljade nimed. Vanad saame mingi v\u00e4lja m\u00f5eldud nimeks, uued v\u00e4ljad muutume j\u00e4lle vanadeks. <\/li>\n<li>Ja alles seej\u00e4rel k\u00e4ivitame uue rakenduse versiooni. <\/li>\n<\/ul>\n<p><\/p>\n<p>Sellega me ei saa bloat'i ja meie j\u00f5udlus ei lange. <\/p>\n<p><\/p>\n<p>Selle l\u00f5ppes kolmas lugu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/2afab2906b5ccd30e4c8772248818057.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pg-utils\/blob\/master\/sql\/table_bloat.sql\">https:\/\/github.com\/dataegret\/pg-utils\/blob\/master\/sql\/table_bloat.sql<\/a><\/noindex><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pg-utils\/blob\/master\/sql\/table_bloat_approx.sql\">https:\/\/github.com\/dataegret\/pg-utils\/blob\/master\/sql\/table_bloat_approx.sql<\/a><\/noindex><\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd pisut p\u00f5hjalikumalt t\u00f6\u00f6riistadest, millest ma esimeses loos r\u00e4\u00e4kisin. <\/p>\n<p><\/p>\n<p>Enne kui bloat'i otsima hakkate, peate kindlasti paigaldama laienduse. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/pgstattuple.html\">pgstattuple<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Et te ei peaks p\u00e4ringute loomisega vaevama, oleme oma t\u00f6\u00f6s juba need p\u00e4ringud kirja pannud. Saate neid kasutada. Siin on esitatud kaks p\u00e4ringut. <\/p>\n<p><\/p>\n<ul>\n<li>Esimene t\u00f6\u00f6tab \u00fcsna kaua, kuid see n\u00e4itab teile bloat'i t\u00e4pseid v\u00e4\u00e4rtusi tabelis. <\/li>\n<li>Teine t\u00f6\u00f6tab kiiremini ja on v\u00e4ga t\u00f5hus, kui on vaja kiiresti hinnata \u2013 kas tabelis on bloat v\u00f5i mitte. Ja peaksite aru saama, et Postgres'i tabelites on bloat alati. See on tema MVCC mudeli erip\u00e4ra. <\/li>\n<li>Ja 20% bloat on enamikul juhtudel tabelite jaoks normaalne. S.t. te ei pea muretsema ja seda tabelit kokku suruma. <\/li>\n<\/ul>\n<p><\/p>\n<p>Kuidas tuvastada tabelid, mis on meie jaoks paisunud, oleme juba aru saanud, sealhulgas, kui need on paisunud kasutud andmed. <\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd r\u00e4\u00e4gime bloat'i parandamisest:<\/p>\n<p><\/p>\n<ul>\n<li>Kui meil on v\u00e4ike tabel ja head kettad, s.t. kui tabeli suurus on alla gigabaidi, on t\u00e4iesti v\u00f5imalik kasutada VACUUM FULL-i. See v\u00f5tab eksklusiivse lukustuse tabelil paariks sekundiks ja see on okei, kuna see teeb kiiresti ja t\u00f5husalt k\u00f5ik vajalikud toimingud. Mida teeb VACUUM FULL? See v\u00f5tab eksklusiivse lukustuse tabelil ja kirjutab elavad read uude tabelisse vanadest tabelitest. Ja l\u00f5puks vahetab nad omavahel kohad. Vanad failid kustutab, uued asendab vanadega. Kuid oma t\u00f6\u00f6 ajal v\u00f5tab ta eksklusiivse lukustuse tabelist. See t\u00e4hendab, et te ei saa selle tabeliga mitte midagi teha: ei saa kirjutada, ei saa lugeda, ei saa muuta. Ja VACUUM FULL n\u00f5uab lisaruumi kettal, et andmeid salvestada.<\/li>\n<li>J\u00e4rgmine t\u00f6\u00f6riist <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/reorg\/pg_repack\">pg_repack<\/a><\/noindex>. Oma p\u00f5him\u00f5ttelt on see v\u00e4ga sarnane VACUUM FULL-ile, kuna see kirjutab samuti andmed vanadest failidest uutesse ja asendab need tabelis. Kuid see ei v\u00f5ta alguses eksklusiivset lukustust tabelil, vaid v\u00f5tab selle alles siis, kui tal on juba valmis andmed failidega asendamiseks. Temaga seotud kettaressursside n\u00f5uded on VACUUM FULL-iga sarnased. Teil on vaja kettal lisaruumi, mis v\u00f5ib m\u00f5nikord olla kriitiline, kui teil on terabaiti suuruseid tabeleid. Ja ta on ka \u00fcsna ressursin\u00f5udlik protsessorilt, kuna tegeleb aktiivselt sisendi-v\u00e4ljundi t\u00f6\u00f6ga. <\/li>\n<li>Kolmas utiliit on <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pgcompacttable\">pgcompacttable<\/a><\/noindex>. Ta on ressursse s\u00e4\u00e4stvam, kuna t\u00f6\u00f6tab natuke erinevatel p\u00f5him\u00f5tetel. Pgcompacttable peamine idee on see, et see uuendustega viib k\u00f5ik elavad read tabeli algusesse. Ja siis k\u00e4ivitab selle tabeli \u00fclevaatuse, kuna me teame, et meil on alguses elavad ja l\u00f5pus surnud read. \u00dclevaatus l\u00f5ikab selle saba \u00e4ra, st see ei vaja palju t\u00e4iendavat kettaruumi. Ja lisaks on seda veel v\u00f5imalik ressursside osas v\u00e4hendada. <\/li>\n<\/ul>\n<p><\/p>\n<p>T\u00f6\u00f6riistadega on k\u00f5ik. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat&#039;i tekkimiseni PostgreSQL-is. Andrei Salnikovi\" src=\"\/wp-content\/uploads\/2020\/05\/4187915e54e54a0b85a342fe0280f78f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kui teema bloat tundub teile huvitav ja soovite s\u00fcgavamale minna, siis siin on m\u00f5ned kasulikud lingid:<\/p>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.slideshare.net\/alexius2Mb\/where-is-the-space-postgres\">https:\/\/www.slideshare.net\/alexius2Mb\/where-is-the-space-postgres<\/a><\/noindex> \u2013 see on minu kolleegi ettekande pealkiri. See on \u00fcldine \u00fclevaade sellest, kuhu Postgres'is ruum kaob tema t\u00f6\u00f6 ja elu jooksul. Seal on v\u00e4ga suur ja detailselt tehniline osa andmebaasihalduritele bloat'i kohta. <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pg-utils\">https:\/\/github.com\/dataegret\/pg-utils<\/a><\/noindex> \u2013 see on link meie hoidlasse, kus hoiame hulga kasulikke skripte andmebaasi seisundi kontrollimiseks. Seal leiate skripte bloat'i otsimiseks. <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/reorg\/pg_repack\">Kolmas<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pgcompacttable\">neljas<\/a><\/noindex> linkide kohta, mis aitavad teil tabelite suurust v\u00e4hendada. <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/blog.dataegret.com\/2Mb018\/03\/postgresql-bloatbusters.html\">http:\/\/blog.dataegret.com\/2Mb018\/03\/postgresql-bloatbusters.html<\/a><\/noindex> \u2013 see on minu kolleegi postitus. Seal k\u00e4sitleb ta \u00fcsna p\u00f5hjalikult ja tehniliselt bloat'i just haldurite tasemel. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ma p\u00fc\u00fcdsin siin rohkem n\u00e4idata hirmutust arendajatele, kuna nad on meie andmebaaside otsesed kliendid ja peavad m\u00f5istma, millised on teod ja nende tagaj\u00e4rjed. Loodan, et mul \u00f5nnestus. Ait\u00e4h t\u00e4helepanu eest!<\/p>\n<p><\/p>\n<p>K\u00fcsimused<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Te r\u00e4\u00e4kisite, kuidas probleeme tuvastada. Kuidas neid ennetada? Mul oli olukord, kus p\u00e4ringud j\u00e4id seisma mitte ainult seet\u00f5ttu, et need kasutasid m\u00f5nda v\u00e4list teenust. Seal olid lihtsalt m\u00f5ned tobedad liitmise p\u00e4ringud. Seal oli m\u00f5ni \u00fcsna kahjutu mikrop\u00e4ring, mis j\u00e4i p\u00e4evaks seisma ja seej\u00e4rel hakkas toimetama mingit jama. See on v\u00e4ga sarnane sellele, mida te kirjeldasite. Kuidas seda j\u00e4lgida? Kas peaksin pidevalt vaatama, milline p\u00e4ring on seisma j\u00e4\u00e4nud? Kuidas seda ennetada?<\/em><\/p>\n<p><\/p>\n<p>Sel juhul \u2013 see on \u00fclesanne teie ettev\u00f5tte halduritele, mitte tingimata DBA-dele.<\/p>\n<p><\/p>\n<p><em>Ma olen haldur.<\/em><\/p>\n<p><\/p>\n<p>PostgreSQL'is on selline vaade nagu pg_stat_activity, kus kuvatakse seisma j\u00e4\u00e4nud p\u00e4ringud. Ja te saate n\u00e4ha, kui kaua need seal olnud on.<\/p>\n<p><\/p>\n<p><em>Kas ma pean iga 5 minuti tagant sisse logima ja vaatama?<\/em><\/p>\n<p><\/p>\n<p>Seadke cron t\u00f6\u00f6 ja kontrollige. Kui teil on pikk p\u00e4ring, saatke kiri ja k\u00f5ik. T. e. teil ei ole vaja silmadega vaadata, see on automatiseeritav. Te saate kirja, millele reageerite. V\u00f5ite ka automaatselt vastata.<\/p>\n<p><\/p>\n<p><em>Kas on ilmsed p\u00f5hjused, miks see juhtub?<\/em><\/p>\n<p><\/p>\n<p>M\u00f5ned neist olen \u00e4ra nimetanud. Teised on keerulisemad n\u00e4ited. Ja seal v\u00f5ib jutt pikaks minna.<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Soovin t\u00e4psustada utiliiti pg_repack. Kui see ei tee eksklusiivset lukku, siis...<\/em><\/p>\n<p><\/p>\n<p>See teeb eksklusiivset lukku. <\/p>\n<p><\/p>\n<p>\u2026 <em>siis ma v\u00f5in potentsiaalselt andmeid kaotada. Minu rakendus ei tohi sel ajal midagi kirjutada?<\/em><\/p>\n<p><\/p>\n<p>Ei, see t\u00f6\u00f6tab rahulikult tabeliga, t. e. pg_repack t\u00f5stab esimesena \u00fcles k\u00f5ik elavread, mis seal on. Loomulikult toimub seal mingisugune kirjutamine tabelisse. Ta lihtsalt lisab selle saba juurde. <\/p>\n<p><\/p>\n<p><em>T. e. ta siiski teeb l\u00f5pus?<\/em><\/p>\n<p><\/p>\n<p>L\u00f5pus v\u00f5tab ta eksklusiivse lukustuse, et neid faile omavahel vahetada. <\/p>\n<p><\/p>\n<p><em>Kas see on kiirem kui VACUUM FULL?<\/em><\/p>\n<p><\/p>\n<p>VACUUM FULL, kui see k\u00e4ivitub, v\u00f5tab kohe eksklusiivse lukustuse. Ja seni, kuni ta k\u00f5ike ei tee, ei vabasta ta seda. Ja pg_repack v\u00f5tab eksklusiivse lukustuse ainult failide asendamise hetkel. Sel ajal te ei saa sinna kirjutada, kuid andmed ei kao, k\u00f5ik on korras. <\/p>\n<p><\/p>\n<p><em>Tere! R\u00e4\u00e4kisite automaatse vakumeerimise t\u00f6\u00f6st. Seal oli graafik punaste, kollaste ja roheliste rakkudega. T. e. kollased \u2013 ta m\u00e4rkis need kustutatuks. Ja seet\u00f5ttu v\u00f5ib neisse midagi uut kirjutada?<\/em><\/p>\n<p><\/p>\n<p>Jah. Postgres ei kustuta ridu. Tal on selline erip\u00e4ra. Kui me rida uuendame, m\u00e4rgime vana kustutatuks. Seal tuleb id tehingu, mis selle rida muutis, ja me kirjutame uue rea. Ja meil on sessioonid, mis potentsiaalselt v\u00f5ivad neid lugeda. Teatud hetkel muutuvad need v\u00e4ga vanaks. Ja automaatse vakumeerimise eesm\u00e4rk on see, et ta l\u00e4bib need read ja m\u00e4rgib need kui mittevajalikud. Ja sinna saab andmeid taas kirjutada. <\/p>\n<p><\/p>\n<p><em>Sain aru. Kuid k\u00fcsimus ei ole t\u00e4iesti selles. Ma ei l\u00f5petanud. Oletame, et meil on tabel. Seal on muutuva suurusega v\u00e4ljad. Ja kui ma p\u00fc\u00fcan midagi uut sisestada, siis see ei pruugi lihtsalt vanasse rakku mahtuda.<\/em> <\/p>\n<p><\/p>\n<p>Ei, seal igal juhul uuendatakse kogu rida. Postgres'el on kaks andmeid salvestamise mudelit. See valib andmete t\u00fc\u00fcbi j\u00e4rgi. 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\u00f5ik on sama. Lihtsalt on need eraldi v\u00e4lja t\u00f5stetud. <\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Kui m\u00f5istlik on kasutada p\u00e4ringute kestuse piiramiseks statement timeout'i?<\/em><\/p>\n<p><\/p>\n<p>See on v\u00e4ga vastuv\u00f5etav. Me kasutame seda igal pool. Kuna meil pole oma teenuseid, pakume eemalt tuge, on klientuur \u00fcsna mitmekesine. Ja k\u00f5ik on selle peale t\u00e4iesti rahul. S.t. meil on \u00fclesanded cron'is, mis kontrollivad seda. Lihtsalt kliendiga lepime kokku seansside kestuse, millest varem me ei katkesta. See v\u00f5ib olla minut, see v\u00f5ib olla 10 minutit. See s\u00f5ltub andmebaasi koormusest ja selle eesm\u00e4rgist. Kuid k\u00f5ik kasutavad pg_stat_activity't.<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! P\u00fc\u00fcan teie ettekannet oma rakendustele kohandada. Tundub, et me alustame k\u00f5ikjal tehingut, l\u00f5petame selle selgelt. Kui mingi exception toimub, siis rollback ikkagi toimub. Ja siis ma m\u00f5tlesin. Sest tehing v\u00f5ib alata ka mitte selgelt. See on ilmselt vihje t\u00fcdrukule. Kui ma lihtsalt uuendan kirjet, kas tehing algab PostgreSQL'is ja l\u00f5petatakse alles siis, kui \u00fchendus katkeb?<\/em><\/p>\n<p><\/p>\n<p>Kui r\u00e4\u00e4gite praegu rakenduse tasemest, siis see s\u00f5ltub kasutatavast draiverist, sellest ORM'ist, mida kasutatakse. Seal on palju seadeid. Kui teil on auto commit sisse l\u00fclitatud, siis tehing algab kohe ja sulgub kohe.<\/p>\n<p><\/p>\n<p><em>S.t. see sulgub kohe p\u00e4rast uuendamist?<\/em><\/p>\n<p><\/p>\n<p>See s\u00f5ltub seadetest. \u00dche seade, mida ma mainisin. See on auto commit on. See on \u00fcsna levinud. Kui see on sisse l\u00fclitatud, avatakse tehing ja suletakse. Kui te ei ole selgelt \u00f6elnud 'start transaction' ja 'end transaction', vaid lihtsalt k\u00e4ivitasite sessioonis p\u00e4ringu. <\/p>\n<p><\/p>\n<p><em>Tere! Ait\u00e4h ettekande eest! Kujutame ette, et meil on andmebaas, mis paisub ja paisub ja siin serveris l\u00f5peb ruum. Kas on mingeid t\u00f6\u00f6riistu, et seda olukorda parandada?<\/em> <\/p>\n<p><\/p>\n<p>Serveri ruumi tuleks t\u00f5epoolest j\u00e4lgida. <\/p>\n<p><\/p>\n<p><em>N\u00e4iteks DBA l\u00e4ks teed jooma, oli puhkuse ajal jne.<\/em><\/p>\n<p><\/p>\n<p>Kui failis\u00fcsteem luuakse, siis seal luuakse v\u00e4hemalt mingit reserveeritud ruumi, kuhu andmeid ei kirjutata. <\/p>\n<p><\/p>\n<p><em>Aga kui k\u00f5ik on t\u00e4iesti t\u00fchi?<\/em><\/p>\n<p><\/p>\n<p>Seal nimetatakse seda reserveeritud ruumiks, st selle saab vabastada ja s\u00f5ltuvalt 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\u00e4biviimiseks. V\u00f5ite kustutada m\u00f5ne tabeli, mis on teile garanteeritult \u00fcleliigne. <\/p>\n<p><\/p>\n<p><em>Teisi t\u00f6\u00f6riistu ei ole?<\/em><\/p>\n<p><\/p>\n<p>See on alati k\u00e4sit\u00f6\u00f6. Ja kohapeal tuvastatakse, mida teha, kuna andmed on kriitilised ja on mitte-kriitilised. Iga andmebaasi ja rakenduse jaoks, mis seda kasutab, s\u00f5ltub see \u00e4rist. See otsustatakse alati kohapeal. <\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Mul on kaks k\u00fcsimust. Esiteks, te tutvustasite slaide, kus n\u00e4idati, et kui tehingud hanguvad, suureneb nii tabeli ruumi maht kui ka indeksi suurus. Ja seej\u00e4rel ettekandes oli palju utiliite, mis paketivad tabelit. Mis toimub indeksi puhul?<\/em><\/p>\n<p><\/p>\n<p>Need paketivad ka neid. <\/p>\n<p><\/p>\n<p><em>Aga vacuum ei m\u00f5juta indeksi?<\/em><\/p>\n<p><\/p>\n<p>M\u00f5ned t\u00f6\u00f6tavad indeksi kallal. N\u00e4iteks pg_rapack, pgcompacttable. Vacuum loob indekseid uuesti, m\u00f5jutab neid. VACUUM FULLi olemus on see, et k\u00f5ik uuesti kirjutada, st see t\u00f6\u00f6tab k\u00f5igi kallal. <\/p>\n<p><\/p>\n<p><em>Ja teine k\u00fcsimus. Ma ei saanud aru, miks aruanded replikates nii palju s\u00f5ltuvad ise replikatsioonist. Tundus, et aruanded on lugemine ja replikatsioon on kirjutamine.<\/em> <\/p>\n<p><\/p>\n<p>Kus tekib replikatsiooni konflikt? Meil on Master, kus toimuvad protsessid. Meil toimub automaatne vacuum. Automaatne vacuum, mis see tegelikult teeb? See eemaldab m\u00f5ned vanad read. Kui meil samal ajal toimub replikas p\u00e4ring, mis loeb neid vanu ridu, ja Masteris on juhtunud, et automaatne vacuum on need read v\u00f5imalike kirjutamiseks m\u00e4rkinud, siis me need uuesti kirjutame. Ja me saame andmepaketi ajal, kui peame uuesti kirjutama need read, mis on replikas p\u00e4ringule vajalikud, siis replikatsiooni protsess ootab seda seadistatud ajavahemikku. Seej\u00e4rel otsustab PostgreSQL, mis on tema jaoks olulisem. Ja replikatsioon on tema jaoks olulisem kui p\u00e4ring ja ta katkestab p\u00e4ringu, et teha need muudatused replikas. <\/p>\n<p><\/p>\n<p><em>Andrej, mul on k\u00fcsimus. Need imelised graafikud, mida te n\u00e4itasite esitluse ajal, on teie t\u00f6\u00f6riista tulemus? Millega graafikud koostati?<\/em><\/p>\n<p><\/p>\n<p>See on teenus <noindex><a rel=\"nofollow\" href=\"https:\/\/okmeter.io\/\">Okmeter<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><em>Kas see on kaubanduslik toode?<\/em><\/p>\n<p><\/p>\n<p>Jah. See on kaubanduslik toode.<\/p>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/501040\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430\u0447\u0430\u043b\u0430 2016 \u0433\u043e\u0434\u0430 \u0410\u043d\u0434\u0440\u0435\u044f \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432\u0430 &quot;\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql&quot; \u0412 \u0434\u0430\u043d\u043d\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u044f \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442 \u043d\u0430 \u044d\u0442\u0430\u043f\u0435 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u043a\u043e\u0434\u0430 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0418 \u0432\u043e\u0437\u044c\u043c\u0443 \u0442\u043e\u043b\u044c\u043a\u043e \u0442\u0435 \u043e\u0448\u0438\u0431\u043a\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 Postgresql. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u044d\u0442\u043e \u043d\u0430\u0447\u0430\u043b\u043e \u043a\u043e\u043d\u0446\u0430 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":81090,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-81089","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430\u0447\u0430\u043b\u0430 2016 \u0433\u043e\u0434\u0430 \u0410\u043d\u0434\u0440\u0435\u044f \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432\u0430 &quot;\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql&quot; \u0412 \u0434\u0430\u043d\u043d\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u044f \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql. \u0410\u043d\u0434\u0440\u0435\u0439 \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430\u0447\u0430\u043b\u0430 2016 \u0433\u043e\u0434\u0430 \u0410\u043d\u0434\u0440\u0435\u044f \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432\u0430 &quot;\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql&quot; \u0412 \u0434\u0430\u043d\u043d\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u044f \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-10T23:42:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-10T23:42:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat'ni postgresql'is. Andrei S\u00f5lnikov | ProHoster","description":"Soovitan tutvuda 2016. aasta alguses Andrei S\u00f5lnikovi esitatud ettekande \"T\u00fc\u00fcpilised vead rakendustes, mis viivad bloat'ni postgresql'is\" sisukirjaga. Selles ettekandes anal\u00fc\u00fcsin p\u00f5hiaspekte.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql. \u0410\u043d\u0434\u0440\u0435\u0439 \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432 | ProHoster","og:description":"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430\u0447\u0430\u043b\u0430 2016 \u0433\u043e\u0434\u0430 \u0410\u043d\u0434\u0440\u0435\u044f \u0421\u0430\u043b\u044c\u043d\u0438\u043a\u043e\u0432\u0430 &quot;\u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043e\u0448\u0438\u0431\u043a\u0438 \u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0435\u0434\u0443\u0442 \u043a bloat \u0432 postgresql&quot; \u0412 \u0434\u0430\u043d\u043d\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u044f \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0435.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/tipovye-oshibki-v-prilozheniyah-kotorye-vedut-k-bloat-v-postgresql-andrej-salnikov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-10T23:42:24+00:00","article:modified_time":"2020-05-10T23:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"81089","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:05:22","updated":"2022-09-27 16:01:50","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/81089","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=81089"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/81089\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/81090"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=81089"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=81089"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=81089"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}