{"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 p\u00f5hjustavad postgreSQL-is bloat'i. Andrei S\u00f5lnikov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><strong>\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;<\/strong><\/p>\n<p><\/p>\n<p>Selles ettekandes k\u00e4sitlen peamisi vigu rakendustes, mis tekivad rakenduse projekteerimise ja koodi kirjutamise etapis. Vaatan vaid neid vigu, mis viivad postgreSQL-is bloat'ini. T\u00fc\u00fcpiliselt on see teie s\u00fcsteemi \u00fcldise j\u00f5udluse l\u00f5puga tegelemise algus, ehkki esialgu ei olnud selleks mingeid m\u00e4rke n\u00e4ha.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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 k\u00f5igile! See ettekande ei ole nii tehniline nagu minu kolleegi eelmine. See ettekande on suunatud peamiselt tagasis\u00fcsteemide arendajatele, kuna meil on piisavalt suur hulk kliente. Ja k\u00f5ik nad teevad samu vigu. Nendest r\u00e4\u00e4gin ma teile. Selgitan, millistele halbadest tagaj\u00e4rgedest need vead viivad. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/c6c84dbafc595ae3068cd8bf804ccee7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Miks tehakse vigu? Vigu tehakse kahe p\u00f5hjuse t\u00f5ttu: lootuses, et \u00e4kki l\u00e4heb l\u00e4bi, ja teadmatusest teatud mehhanismide osas, mis toimuvad andmebaasi ja rakenduse vahel, aga ka andmebaasis endas. <\/p>\n<p><\/p>\n<p>Ma toon teile kolm n\u00e4idet kohutavatest piltidest, mis n\u00e4itavad, kuidas k\u00f5ik halvasti l\u00e4ks. L\u00fchidalt r\u00e4\u00e4gin mehhanismist, mis seal toimub. Ja kuidas nendega tegeleda, kui need juhtuvad, ning milliseid ennetusmeetodeid kasutada vigade v\u00e4ltimiseks. R\u00e4\u00e4gin abivahenditest ja jagan kasulikke linke. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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 arvetega seotud tehingutega. Ja mingite ajavahemike j\u00e4rel uuendame nende arvete j\u00e4\u00e4ke.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/1d2a21278b095b07546e1bb870819dbf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Algandmed tabelist: see on piisavalt v\u00e4ike, 2 MB. Andmebaasi vastuse aeg ja konkreetne tabeli vastuse aeg on samuti v\u00e4ga hea. Ja piisavalt suur koormus \u2013 2000 tehingut sekundis selle tabeli kohta.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/dea5a4b1ac7952f8cfed0e2e1cfc10dd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja selle ettekande kaudu n\u00e4itan teile graafikuid, et oleks selgelt aru saada, mis toimub. Alati on kaks slaidi graafikutega. Esimene slaid \u2013 see, mis toimub serveris \u00fcldiselt. <\/p>\n<p><\/p>\n<p>Ja antud olukorras n\u00e4eme, et meie tabel on t\u00f5epoolest v\u00e4ike. Indeks on j\u00e4llegi v\u00e4ike, 2 MB. See on esimene graafik vasakul. <\/p>\n<p><\/p>\n<p>Serveri keskmine vastusaeg on samuti stabiilne ja madal. See on parem \u00fclemine diagramm. <\/p>\n<p><\/p>\n<p>Vasak alumine diagramm n\u00e4itab pikimaid tehinguid. Me n\u00e4eme, et tehingud viiakse kiiresti l\u00f5pule. Ja automaatne vaakum ei t\u00f6\u00f6ta veel siin, kuna see oli algtest. 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 p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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. Antud juhul uuendame pidevalt kliendi kontode j\u00e4\u00e4ke. Ja me n\u00e4eme, et keskmine vastusaeg uuenduste operatsioonide jaoks on piisavalt hea, alla \u00fche millisekundi. N\u00e4eme, et protsessori ressursid (see on parem \u00fclemine diagramm) tarbitakse samuti \u00fchtlaselt ja on piisavalt v\u00e4ikesed. <\/p>\n<p><\/p>\n<p>Parem alumine diagramm n\u00e4itab, kui palju operatiiv- ja kettam\u00e4lu me otsime meie vajaliku rea leidmiseks, enne kui seda uuendame. Ja tehingute arv tabelis \u2013 2000 sekundis, nagu ma alguses \u00fctlesin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/84760d52716209b8dcfffb462c67a8e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd juhtub meil trag\u00f6\u00f6dia. Mikski p\u00e4rast tekib pikk unustatud tehing. P\u00f5hjused on tavaliselt k\u00f5ik banaalsed: <\/p>\n<p><\/p>\n<ul>\n<li>\u00dcks levinumaid olukordi on see, et rakenduse koodis hakkame v\u00e4listeenusega suhtlema ning see teenus ei vasta meile. See t\u00e4hendab, et oleme avanud tehingu, teinud muudatuse andmebaasis ja l\u00e4inud rakendusest posti vaatama v\u00f5i m\u00f5nda teise teenusesse meie infrastruktuuris, ning see ei vasta mingil p\u00f5hjusel. Ja meil on sessioon, mis on seiskunud seisundis \u2013 teadmata, millal see lahendust leiab.<\/li>\n<li>Teine olukord on see, et meie koodis on mingil p\u00f5hjusel toimunud erand (exception). Ja me ei ole erandi k\u00e4sitlemisel tehingu sulgemist t\u00f6\u00f6tlenud. Ja me saime seiskunud sessiooni avatud tehinguga. <\/li>\n<li>Ja viimane \u2013 see on samuti \u00fcsna levinud juhtum. See on kehva kvaliteediga kood. M\u00f5ned raamistikud avavad tehingu, see j\u00e4\u00e4b seisma ja te v\u00f5ite oma rakenduses mitte teada, et see on seiskunud. <\/li>\n<\/ul>\n<p><\/p>\n<p>Mida sellised asjad endaga kaasa toovad? <\/p>\n<p><\/p>\n<p>Meie tabelid ja indeksid hakkavad j\u00e4rsult paisuma. See on just see bloat efekt. Andmebaasi jaoks v\u00e4ljendub see selles, et andmebaasi vastusaeg suureneb j\u00e4rsult ja andmebaasi serveri koormus t\u00f5useb. L\u00f5ppkokkuv\u00f5ttes kannatab rakendus. Kui varem kulus koodis andmebaasi p\u00e4ringule 10 millisekundit ja oma loogikale 10 millisekundit, siis funktsioon t\u00f6\u00f6tas 20 millisekundit. N\u00fc\u00fcd on olukord palju kehvem. <\/p>\n<p><\/p>\n<p>Vaadakem siis, mis juhtub. Vasaku alumise graafiku j\u00e4rgi on meil pikk ja aeglane tehing. Ja kui vaatame vasakus \u00fclemises graafikus, n\u00e4eme, et tabeli suurus on kahe megabaidi pealt j\u00e4rsult t\u00f5usnud 300 megabaidini. Samas tabeli andmete hulk ei ole muutunud, st seal on piisavalt palju pr\u00fcgi.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/b1947f6487e440a770a1251a955e62d2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00dcldine olukord serveri keskmise vastusaaja osas on samuti muutunud mitme korra v\u00f5rra. See t\u00e4hendab, et k\u00f5ik serveri p\u00e4ringud hakkasid t\u00f5siselt langema. Samuti k\u00e4ivitusid Postgresis sisemised protsessid nagu autovakuu, mis \u00fcritavad midagi teha ja tarbivad ressursse.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/8e91f035d1dd04e72e842d714cc611a5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mis toimub meie tabeliga? Sama asi. Tabeli keskmine vastusaeg on t\u00f5usnud mitu korda. Kui r\u00e4\u00e4kida kasutatud ressurssidest, siis n\u00e4eme, et protsessori koormus on oluliselt suurenenud. See on paremal \u00fclemisel graafikul. Koormus on suurenenud, kuna protsessor peab l\u00e4bi kammima hulgaliselt kasutu ridu, et leida \u00fcks vajalik. See on paremal alumisel graafikul. Tulemusena on meie sekundis tehtud p\u00e4ringute arv langenud oluliselt, kuna andmebaas ei j\u00f5ua sama palju p\u00e4ringutest t\u00f6\u00f6tleda. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/424685ce852bc5f3ef77151f8d3d7289.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Me peame tagasi elama hakkama. Uurime internetist, et pikad tehingud p\u00f5hjustavad probleemi. Leiame ja l\u00f5petame selle tehingu. Ja k\u00f5ik muutub 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 samamoodi nagu enne avarii. P\u00e4ringud t\u00f6\u00f6tlevad siiski aeglasemalt, oluliselt aeglasemalt. Minu n\u00e4ite puhul on see poolteist kuni kaks korda aeglasem. Serveri koormus on samuti k\u00f5rgem kui see oli enne avariid. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/ee3037719a31f8d18fc42745716c4da5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00fcsimus on: \u201eMis juhtub andmebaasi sel hetkel?\u201c. Andmebaasis toimub j\u00e4rgmine olukord. Tehingute graafikul n\u00e4ete, et see on peatanud ja seal t\u00f5epoolest ei ole pikki tehinguid. Kuid tabeli suurused on h\u00e4daolukorra ajal oluliselt kasvanud. Ja sellest ajast alates ei ole nad v\u00e4henenud. Andmebaasi keskmine aeg on stabiliseerunud. Ja vastused n\u00e4ivad liikuvat adekvaatselt meie jaoks vastuv\u00f5etava kiiruseni. Automaatne vakumeerimine on muutunud aktiivsemaks ja on hakanud tabeliga midagi ette v\u00f5tma, sest tal on vaja \u00fcmber t\u00f6\u00f6tada suurem hulk andmeid. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/f6205242c4024dc3ed4cade5844dbf76.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetse tabeli osas, kus me muudame j\u00e4\u00e4ke: p\u00e4ringu vastamisaeg on nagu tagasi normaali. Kuid tegelikult on see poolteist korda k\u00f5rgem.<\/p>\n<p><\/p>\n<p>Ja protsessorikoormuse osas n\u00e4eme, et protsessori koormus ei ole naasnud vajalikule tasemele enne h\u00e4daolukorda. Ja p\u00f5hjused peituvad seal paremas alanurgas oleva graafiku juures. N\u00e4ha on, et seal toimub mingisugune m\u00e4lu \u00fcletamine. See t\u00e4hendab, et vajaliku rea leidmiseks kulutame andmebaasi serveri ressursse kasutu andmete l\u00e4bivaatamisele. Tehingute arv sekundis on stabiliseerunud. <\/p>\n<p><\/p>\n<p>\u00dcldiselt on olukord hea, kuid see on halvenenud v\u00f5rreldes varasemaga. Andmebaasi selge degradatsioon, mis tuleneb meie rakendusest, mis t\u00f6\u00f6tab selle andmebaasiga. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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 pole eelmisel ettekandel olnud, siis veidi teooriat. Teooria sisemisest protsessist. Miks on automaatne vaakum ja mida see teeb?<\/p>\n<p><\/p>\n<p>L\u00fchidalt arusaamiseks. Teatud hetkel on meil tabel. Tabelis on read. Need read v\u00f5ivad olla aktiivsed, elusad, meie jaoks hetkel vajalikud. Pildil on need m\u00e4rgitud rohelise v\u00e4rviga. Ja on ka surnud read, mis on juba t\u00f6\u00f6tanud, on uuendatud ja mille kohta on ilmunud uued kirjed. Need on juba t\u00e4histatud, et nad pole andmebaasi jaoks enam huvitavad. Aga nad j\u00e4\u00e4vad tabelisse PostgreSQL erip\u00e4ra t\u00f5ttu.<\/p>\n<p><\/p>\n<p>Miks on autovakuum vajalik? Autovakuum j\u00f5uab mingil hetkel andmebaasi, p\u00f6\u00f6rdub selle poole ja k\u00fcsib: \"Palun anna mulle k\u00f5ige vanema tehingu ID, mis on praegu andmebaasis avatud.\" Andmebaas tagastab selle ID. Autovakuum, tuginedes sellele, l\u00e4bib tabelis olemasolevad read. Kui ta n\u00e4eb, et m\u00f5ni rida on muutunud palju vanemate tehingute t\u00f5ttu, on tal \u00f5igus need markeerida ridadena, mida saame tulevikus taaskasutada, kirjutades sinna uusi andmeid. See on taustaprotsess.<\/p>\n<p><\/p>\n<p>Selle aja jooksul j\u00e4tkame andmebaasiga t\u00f6\u00f6tamist, teeme tabelis mingeid muudatusi. Ja nendele ridadele, mida saame taaskasutada, kirjutame uusi andmeid. Niimoodi toimub meil ringk\u00e4ik, st pidevalt tekivad sinna vanad surnud read, asemele kirjutame uued read, mida vajame. See on PostgreSQL-i t\u00f6\u00f6 normaalne seisund.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/98dd4451a7ca5f418775f72822c2840c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mis juhtus \u00f5nnetuse ajal? Kuidas see protsess seal toimus?<\/p>\n<p><\/p>\n<p>Meil oli tabel, kus olid m\u00f5ned elavad ja m\u00f5ned surnud read. Siis tuli automaatne vaakum. Ta k\u00fcsis andmebaasilt, 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 teie andmebaasi koormus. Ning ta asus otsima ridu, mida ta saaks m\u00e4rgistada taaskasutatavateks, kuid ei leidnud meie tabelist selliseid rive. <\/p>\n<p><\/p>\n<p>Aga samal ajal j\u00e4tkame me tabeliga t\u00f6\u00f6tamist. Teeme seal midagi, uuendame ja muudame andmeid. Mis aga andmebaasile sel ajal j\u00e4\u00e4b? Tal ei j\u00e4\u00e4 muud \u00fcle, kui kirjutada uued read olemasoleva tabeli l\u00f5ppu. Seega hakkab meie tabeli suurus paisuma. <\/p>\n<p><\/p>\n<p>Tegelikkuses on meile t\u00f6\u00f6ks vajalikud rohelised read. Kuid sellise probleemi ajal on meil olukord, kus roheliste ridade protsent on kogu tabeli mahus \u00e4\u00e4rmiselt madal. <\/p>\n<p><\/p>\n<p>Kui me teeme 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, mida t\u00e4idavad kasutud andmed, nimetatakse \u201ebloat\u201d, mis veel s\u00f6\u00f6b meie ketta ruumi. Kas m\u00e4letate, et oli 2 MB, n\u00fc\u00fcd on 300 MB? N\u00fc\u00fcd asendage megabaitid gigabaidiga ja te kaotate oma kettaressursid \u00fcsna kiiresti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/fe7cb6b5c99610744ebcfe5ad7235d1e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Millised on meie jaoks tagaj\u00e4rjed? <\/p>\n<p><\/p>\n<ul>\n<li>Minu n\u00e4ites kasvas tabel ja indeks 150 korda. M\u00f5nel meie kliendil on olnud isegi halvemad juhtumid, kus kettaruumi hakkas lihtsalt nappima. <\/li>\n<li>Tabelite suurus iseenesest kunagi ei v\u00e4hene. Automaatne t\u00fchjendamine v\u00f5ib m\u00f5nel juhul l\u00f5igata tabeli sabanema, kui seal on ainult surnud read. Kuid kuna toimub pidev rotatsioon, v\u00f5ib \u00fcks roheline rida l\u00f5puks kinni j\u00e4\u00e4da ja mitte uuenduda, samas kui k\u00f5ik teised kirjutatakse kuskil tabeli algusesse. Kuid see on niiv\u00f5rd ebat\u00f5en\u00e4oline s\u00fcndmus, et te ei peaks lootma, et teie tabel iseenesest v\u00e4heneb. <\/li>\n<li>Andmebaas peab l\u00e4bi k\u00e4ima kogu selle kasutu rivi. See kulutab meie diskiruume, protsessorite ressursse ja energiat. <\/li>\n<li>See m\u00f5jutab meie rakendust otseselt, sest kui alguses kulus meil p\u00e4ringule 10 millisekundit ja meie koodile 10 millisekundit, siis avarii ajal hakkasime p\u00e4ringule kulutama sekundi ja koodile 10 millisekundit. See t\u00e4hendab, et rakenduse j\u00f5udlus on langenud korra v\u00f5rra. Ja kui avarii lahendus leiti, kulub meil n\u00fc\u00fcd 20 millisekundit p\u00e4ringule ja 10 millisekundit koodile. See t\u00e4hendab, et oleme ikkagi poole v\u00e4hem efektiivsed. Ja see k\u00f5ik juhtus \u00fche tehingu t\u00f5ttu, mis kukkus kinni, mis v\u00f5ib-olla on ka meie s\u00fc\u00fc. <\/li>\n<li>Ja k\u00fcsimus on: 'Kuidas k\u00f5ik tagasi tuua?', et meil oleks k\u00f5ik korras ja p\u00e4ringud t\u00f6\u00f6taksid taas sama kiiresti kui enne avariid. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/1bf46e8cd9b28ca2862f978f2ca85819.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selleks on kindel t\u00f6\u00f6ts\u00fckkel, mis tuleb l\u00e4bi viia. <\/p>\n<p><\/p>\n<p>Esimene asi, mida peame tegema, on leida probleemsed tabelid, mis on paisunud. Me m\u00f5istame, et teatud tabelite kirjutamine toimub aktiivsemalt, teistel v\u00e4hem aktiivselt. Ja selleks kasutatakse laiendust. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/pgstattuple.html\">pgstattuple<\/a><\/noindex>. Paigaldades selle laienduse, saate esitada p\u00e4ringuid, mis aitavad leida tabeleid, mis on piisavalt paisunud. <\/p>\n<p><\/p>\n<p>P\u00e4rast nende tabelite leidmist tuleb need tihendada. Selleks on juba olemas t\u00f6\u00f6riistad. Meie ettev\u00f5ttes kasutame kolme t\u00f6\u00f6riista. Esimene on sisseehitatud VACUUM FULL. See on karm, ranged 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 on kolmanda osapoole utiliidid tabelite tihendamiseks. Ja need on andmebaasi suhtes \u00f5rnemad. <\/p>\n<p><\/p>\n<p>Nende kasutamine s\u00f5ltub sellest, mis on teile mugavam. Kuid sellest r\u00e4\u00e4gin ma l\u00f5puks. Peamine on see, et on kolm t\u00f6\u00f6riista. On, mida valida. <\/p>\n<p><\/p>\n<p>P\u00e4rast seda, kui oleme k\u00f5ik korda saanud ja veendunud, et k\u00f5ik on h\u00e4sti, peame teadma, kuidas selliseid olukordi tulevikus v\u00e4ltida:<\/p>\n<p><\/p>\n<ul>\n<li>Seda on piisavalt lihtne v\u00e4ltida. Tuleb j\u00e4lgida sessioonide kestvust Meistriserveris. <strong>Eriti ohtlikud on sessioonid, mis on idle in transaction<\/strong>. Need on need, mis avasid tehingu, tegid midagi ja lahkusid v\u00f5i lihtsalt j\u00e4id seisma, kadusid koodi sisse. <\/li>\n<li>Arendajatele on oluline testida koodi, kui esinevad sellised olukorrad. Seda ei ole keeruline teha. See on kasulik kontroll, mis aitab v\u00e4ltida paljusid \"lapsep\u00f5lve\" probleeme, mis on seotud pikaajaliste tehingutega. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/d55465d96c4018db733954867d23aaba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nendel graafikutel soovisin n\u00e4idata, kuidas tabel ja andmebaasi k\u00e4itumine muutusid p\u00e4rast seda, kui kasutasin antud juhul VACUUM FULL'i tabeli peal. See ei ole tootmiskeskkond.<\/p>\n<p><\/p>\n<p>Tabeli suurus naasis kiiresti normaalsesse t\u00f6\u00f6seisundisse paar megabaiti. See ei m\u00f5jutanud serveri keskmist vastusaega m\u00e4rkimisv\u00e4\u00e4rselt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/cbb07ad24dba899395223d1ca25e438e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuid meie katsetatava tabeli osas, kus me uuendasime kontode j\u00e4\u00e4ke, n\u00e4eme, et andmete uuendamise p\u00e4ringute keskmine vastamisaeg on v\u00e4henenud h\u00e4daolukorra eelsetele tasemetele. Protsessorile rakendatud ressursid selle p\u00e4ringu t\u00e4itmiseks on samuti langenud h\u00e4daolukorra eelsetele tasemetele. Ja parempoolne alumine graafik n\u00e4itab, et n\u00fc\u00fcd leiame otse selle rea, mida vajame, ilma et peaksime l\u00e4bima hulk surmaga l\u00f5ppenud rease, mis olid enne tabeli kokkusurumist. Ja keskmine p\u00e4ringute aeg on umbes samal tasemel p\u00fcsinud. Kuid mul on siin pigem minu riistvara talitlush\u00e4ire.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/c1d90c5442e02fce209dc40e048a8ca2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Selleks esimesed lood on l\u00f5ppenud. See on k\u00f5ige levinum ja juhtub k\u00f5igiga, s\u00f5ltumata kliendi kogemusest, kui oskuslikud on programmeerijad. Varem v\u00f5i hiljem juhtub see. <\/p>\n<p><\/p>\n<p>Teine lugu, kus me jaotame koormust ja optimeerime serveri ressursse<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/cda421c554d1329107ddc935045cc1b9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Oleme juba kasvanud ja oleme t\u00f5sised tegijad. M\u00f5istame, et meil on replika ja oleks hea jaotada koormust: kirjutada Master'il ja lugeda replikalt. See olukord tekib tavaliselt siis, kui soovime koostada aruandeid v\u00f5i ETL-i. Ja \u00e4ri on sellest v\u00e4ga r\u00f5\u00f5mus. Ta soovib v\u00e4ga erinevaid aruandeid koos keeruka anal\u00fc\u00fcsiga. <\/li>\n<li>Aruanded v\u00f5tavad palju tunde, sest keerulist anal\u00fc\u00fcsi ei saa arvutada millisekunditega. Me, nagu tublid tegijad, kirjutame koodi. Teeme rakenduses sisestusi, et kandu oleks Master'il, aruandeid t\u00e4idame replikal. <\/li>\n<li>Jaotame 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 p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/e94c8c492197a5015ac8aae79389a4c2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas see situatsioon v\u00e4lja n\u00e4eb? Konkreetselt nende graafikute p\u00f5hjal lisasin ma ka tehingute kestvuse replikalt. K\u00f5ik teised graafikud kuuluvad ainult Master-serverile. <\/p>\n<p><\/p>\n<p>Aruannete tabel on selleks ajaks mul kasvanud. Need on muutunud rohkemaks. N\u00e4eme, et serveri keskmine vastamisaeg on stabiilne. N\u00e4eme, et replikal on pikaajaline tehing, mis kestab 2 tundi. N\u00e4eme rahulikku automaatset t\u00fchjendamist, mis t\u00f6\u00f6tleb surnud ridu. Ja k\u00f5ik on meil h\u00e4sti. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/2da8acf098d12d6f146ab9b9dcb54b81.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetse katse tabeli osas j\u00e4tkame saldo v\u00e4rskendamist kontodel. Samuti on meil stabiilne vastuse aeg p\u00e4ringule ja stabiilne ressursikasutus. Meil on k\u00f5ik h\u00e4sti. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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, kuni meie raportid hakkavad tulistama replikatsiooni konflikti t\u00f5ttu. Ja need tulistuvad pideva perioodilisusega. <\/p>\n<p><\/p>\n<p>Me h\u00f5ivame interneti ja hakkame lugema, miks see juhtub. Ja leiame lahenduse. <\/p>\n<p><\/p>\n<p>Esimene lahendus on suurendada replikatsiooni viivitust. Me teame, et meie raport t\u00f6\u00f6tab 3 tundi. Seame replikatsiooni viivituseks 3 tundi. K\u00e4ivitame k\u00f5ik, kuid meil j\u00e4tkuvad probleemid, et raportid m\u00f5nikord tulistuvad. <\/p>\n<p><\/p>\n<p>Me soovime, et k\u00f5ik oleks ideaalne. J\u00e4tkame uurimist. Ja leiame internetis suurep\u00e4rase seadistuse \u2013 hot_standby_feedback. L\u00fclitame selle sisse. Hot_standby_feedback v\u00f5imaldab meil peatada autovakumeerimise t\u00f6\u00f6 Meistris. Nii vabaneme t\u00e4ielikult replikatsiooni konfliktidest. Ja meil on k\u00f5ik raportitega h\u00e4sti.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/ee3c315168bdd3f392d2e8a1c5861004.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aga mis siis juhtub meie Peaserveriga? Peaserveriga on meil totaalne h\u00e4da. Praegu j\u00e4lgime graafikuid, kui aktiveerisin m\u00f5lemad seaded. Ja me n\u00e4eme, et replika seanss on mingil viisil hakanud m\u00f5jutama olukorda Peaserveris. See t\u00f5esti m\u00f5jutab, sest see on peatama pannud autovakuumi, mis puhastab surnud read. Meie tabeli suurus on taas taevasse t\u00f5usnud. Keskmine p\u00e4ringute t\u00e4itmise aeg kogu andmebaasis on samuti j\u00e4rsult t\u00f5usnud. Autovakuumid on natuke \u00fcle koormatud. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/980611dcce8b189dc50f422ffd3d2d72.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Konkreetse tabeli osas n\u00e4eme, et andmete v\u00e4rskendamise aeg on samuti j\u00e4rsult t\u00f5usnud. Protsessori ressursikasutuse tarbimine on samuti v\u00e4ga suurenenud. Me uuesti suuname suurt hulka surnud, kasutu read. Ja selle tabeli vastamisaeg, tehingute arv on langenud. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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\u00e4eb, kui me ei tea, millest ma enne r\u00e4\u00e4kisin?<\/p>\n<p><\/p>\n<ul>\n<li>Alustame probleemide otsimist. Kui me oleme esimeses osas probleemidega kokku puutunud, teame, et see v\u00f5ib tuleneda pikaajalisest tehingust ning vaatame Masti. Probleem on meil Masti juures. See on \u00fcle koormatud. See kuumeneb, Load Average on l\u00e4henenud sajale. <\/li>\n<li>K\u00fcsimused seal tunnivad, kuid seal ei n\u00e4e me mingeid pikki tehinguid. Ja ei saa aru, milles on asi. Ei saa aru, kust otsida. <\/li>\n<li>Kontrollime serveri riistvara. V\u00f5ib-olla on meil raid kokku kukkunud. V\u00f5ib-olla on m\u00e4luplokk l\u00e4bi kukkunud. Mis iganes v\u00f5ib juhtuda. Kuid ei, serverid on uued, k\u00f5ik t\u00f6\u00f6tab suurep\u00e4raselt. <\/li>\n<li>K\u00f5ik jooksevad: administraatorid, arendajad ja direktor. Miski ei aita. <\/li>\n<li>Ja mingil hetkel hakkab k\u00f5ik ootamatult iseenesest paranema. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/7d4f6417bc5cb3cec33679d843c6661d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Replikas t\u00f6\u00f6tas meil sel ajal p\u00e4ring ja l\u00e4ks. Saime aruande. \u00c4rikliendil on endiselt hea meel. Nagu n\u00e4eme, on meie tabel taas kasvanud ja ei plaani v\u00e4heneda. Sessioonide graafikul olen j\u00e4tnud t\u00fckikese sellest pikast tehingust replikast, et saaksite hinnata, kui kaua olukorra stabiliseerumine aega v\u00f5tab. <\/p>\n<p><\/p>\n<p>Seans on kadunud. Ja alles m\u00f5ne aja p\u00e4rast hakkab server enam-v\u00e4hem korda saama. Ja keskmine vastamisaeg p\u00e4ringutele Master-serveris stabiliseerub. Sest l\u00f5puks on automaatne vakumeerimine saanud v\u00f5imaluse surnud read puhastada ja m\u00e4rgistada. Ja ta on hakanud oma t\u00f6\u00f6d tegema. Nii kiiresti, kui ta seda teeb, tuleme me korda.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/547d195e08de1566da818150a47218eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Katsetataval tabelil, kus uuendame saldoid, n\u00e4eme t\u00e4pselt sama pilti. Keskmine saldo uuendamise aeg normaliseerub samuti j\u00e4rk-j\u00e4rgult. Protsessori poolt tarbitavad ressursid v\u00e4henevad samuti. Ja tehingute arv sekundis naaseb normaali. Kuid normaali mitte sellisena, nagu see oli enne \u00f5nnetust. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/29372a5e9124690931485a7aea65befc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Igal juhul saame me j\u00f5udluses languse nagu esimesel korral, poolteise kuni kahe korra v\u00f5rra, vahel isegi rohkem. <\/p>\n<p><\/p>\n<p>Me n\u00e4isime tegevat k\u00f5ik \u00f5igesti. Jagasime koormust. Seade ei seisa. Targalt jagasime p\u00e4ringud, kuid ikkagi l\u00e4ks k\u00f5ik halvasti. <\/p>\n<p><\/p>\n<ul>\n<li>Kas hot_standby_feedback'i mitte lubada? Jah, seda ei soovitata lubada ilma olulise p\u00f5hjuseta. Sest see reguleerija m\u00f5jutab otseselt Meistri serverit ja peatab seal automaatvakumimist. Kui te lubate seda m\u00f5nes replikas ja unustate selle, v\u00f5ite tappa Meistri ja saada suuri probleeme rakendusega. <\/li>\n<li>Kas max_standby_streaming_delay'd suurendada? Jah, aruannete puhul \u2013 see on nii. Kui teil on kolmekordne aruanne ja te ei soovi, et see probleemide t\u00f5ttu kokku kukuks, lihtsalt suurendage viivitust. Pikaajaline aruanne ei vaja kunagi andmeid, mis on just praegu andmebaasi tulnud. Kui see on kolmekordne, t\u00e4hendab see, et k\u00e4itate seda m\u00f5ne vanema andmeperioodi jaoks. Ja kas teie jaoks on kolm v\u00f5i kuus tundi viivitust \u2013 see ei m\u00e4ngi mingit rolli, kuid nii saate stabiilselt aruandeid ja ei pea nende kadumise p\u00e4rast muretsema. <\/li>\n<li>Muidugi on oluline j\u00e4lgida pikki sessioone replikates, eriti kui olete otsustanud lubada hot_standby_feedback replikas. Sest v\u00f5ib juhtuda \u00fcksk\u00f5ik mis. Oleme andnud selle replikatsiooni arendajale, et ta testiks p\u00e4ringute kohta. Ta kirjutas p\u00f6\u00f6rase p\u00e4ringu. K\u00e4ivitas selle ja l\u00e4ks teed juua, ning meie saime kokku pandud Masteri. V\u00f5i me lubasime sinna vale rakenduse. Olukordi on palju. Sessioone replikates tuleb j\u00e4lgida sama p\u00f5hjalikult kui Masteris. <\/li>\n<li>Ja kui teil on replikate seas kiireid ja pikka aega kesta p\u00e4ringuid, siis on sel juhul parem laadija jaotamiseks need jagada. See viitab streaming_delay'le. Kiirete jaoks tuleks omada \u00fchte replikat v\u00e4ikese replikeerimise viivitusega. Pikkade aruandlike p\u00e4ringute jaoks tuleks omada replikat, mis v\u00f5ib j\u00e4\u00e4da 6 tunni v\u00f5i p\u00e4eva v\u00f5rra maha. See on t\u00e4iesti normaalne olukord. <\/li>\n<\/ul>\n<p><\/p>\n<p>Eemaldame tagaj\u00e4rjed ikka sama meetodiga:<\/p>\n<p><\/p>\n<ul>\n<li>Leidke paisutatud tabelid.<\/li>\n<li>Ja surume kokku k\u00f5ige sobivama t\u00f6\u00f6riistaga, mis meile sobib. <\/li>\n<\/ul>\n<p><\/p>\n<p>Teine lugu sai siin otsa. Liigume kolmanda loo juurde. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/c8784e0be27883640cb8f6919a1c25e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ka see on meile \u00fcsna tavaline, kus me teeme migreerimise. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/a04b9cd88a0e7e8a3b960ef930eb2657.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<ul>\n<li>Iga tarkvara areneb. N\u00f5uded tema suhtes muutuvad. Me tahame igal juhul areneda. Ja juhtub, et peame andmeid tabelis uuendama, just viima l\u00e4bi v\u00e4rskenduse meie migratsiooni plaanis uue funktsionaalsuse jaoks, mille me oma arendustegevuses juurutame. <\/li>\n<li>Vana andmeformaat ei sobi. \u00dctleme, et vaatame teisele tabelile, kus mul on tehingud nende kontode osas. Ja \u00fctleme, et need olid rublades, kuid oleme otsustanud t\u00e4psust t\u00f5sta ja teha kopikates. Selleks peame tegema uuenduse: tehingu summa v\u00e4li tuleb korrutada sajaga. <\/li>\n<li>Kaasaegses maailmas kasutame automatiseeritud andmebaasi versioonikontrolli vahendeid. \u00dctleme, et <noindex><a rel=\"nofollow\" href=\"https:\/\/www.liquibase.org\/\">Liquibase<\/a><\/noindex>. Kirjutame sinna meie migratsiooni. Testime seda meie testandmebaasis. K\u00f5ik l\u00e4heb h\u00e4sti. Uuendus toimub. See blokeerib t\u00f6\u00f6 m\u00f5neks ajaks, aga saame uuendatud andmed. Ja saame k\u00e4ivitada sellel meie uue funktsionaalsuse. K\u00f5ik on testitud, kontrollitud. K\u00f5ik on kinnitatud. <\/li>\n<li>Teostasime plaanilised t\u00f6\u00f6d, viisime l\u00e4bi migratsiooni. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/9e046583f7b1723fc1eaf61a03900918.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin on migreerimise v\u00e4rskendus, mida teie ees esitatakse. Kuna need on minu arvelduse operatsioonid, oli tabeli maht 15 GB. Ja kuna me uuendame iga rida, suurendasime tabeli suurust kahekordseks, sest kirjutasime iga rea \u00fcle. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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 selle tabeliga midagi teha, sest k\u00f5ik p\u00e4ringud olid j\u00e4rjekorras ja ootasid, kuni see uuendus l\u00f5pule j\u00f5uab. Kuid siin tahan ma juhtida teie t\u00e4helepanu vertikaalsel teljel olevatele numbritele. St. meil oli keskmine p\u00e4ringu aeg enne migreerimist umbes 5 millisekundit ning protsessori koormus, ketta m\u00e4lust lugemise plokkoperatsioonide arv oli v\u00e4iksem kui 7,5. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/69a3ba4d1d0cec7d39284e09e9d3055b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Migreerimine toimus, aga j\u00e4lle tekkisid probleemid. <\/p>\n<p><\/p>\n<p>Migreerimine \u00f5nnestus, kuid:<\/p>\n<p><\/p>\n<ul>\n<li>Vana funktsionaalsus hakkas t\u00f6\u00f6tama kauem. <\/li>\n<li>Tabel kasvas j\u00e4lle suuremaks. <\/li>\n<li>Serveri koormus suurenes j\u00e4lle suuremaks, kui oli. <\/li>\n<li>Ja loomulikult j\u00e4tkame veel selle funktsionaalsuse kallal t\u00f6\u00f6tamist, mis t\u00f6\u00f6tas h\u00e4sti, ning oleme seda veidi parandanud. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ja see on j\u00e4lle bloat, mis h\u00e4irib meid taas. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/becd7cce3a1c8821c81c96257f41202b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin ma demonstreerin, et tabel, nagu eelnevatel kahel juhul, ei plaanita tagasi varasematele m\u00f5\u00f5tmetele naasta. Serveri keskmine koormus n\u00e4ib olevat normaalne. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/4d703a60d43a3460bc3782d49865b690.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja kui me vaatame arvetega tabelit, siis n\u00e4eme, et meie keskmine p\u00e4ringu aeg on kahekordistunud. Protsessori koormus ja m\u00e4lu tarvitamine on t\u00f5usnud \u00fcle 7,5, kui see oli varem madalam. Protsessorite puhul on t\u00f5us olnud kahekordne, plokkoperatsioonide puhul 1,5 korda, st me oleme saanud serveri j\u00f5udluse halvenemise. Selle tagaj\u00e4rjel ka meie rakenduse j\u00f5udlus. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/80772afa0643b29f5314a2482c9dfe0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Oluline on m\u00f5ista, kuidas selliseid migratsioone \u00f5igesti teha. Ja neid on vajalik teostada. Teeme neid \u00fcsna tihti.<\/p>\n<p><\/p>\n<ul>\n<li>Selliseid suuri migratsioone ei tehta automaatselt. Need peavad olema alati kontrolli all. <\/li>\n<li>T\u00f6\u00f6taja \u00f5igete teadmiste j\u00e4relevalve on vajalik. Kui teie meeskonnas on DBA, siis las see teeb DBA. See on tema t\u00f6\u00f6. Kui ei ole, siis las seda teostab k\u00f5ige kogenum inimene, kes oskab andmebaasidega t\u00f6\u00f6tada. <\/li>\n<li>Uus andmebaasi skeem, isegi kui me uuendame ainult \u00fcht veergu, valmistame alati etappidena, st eelnevalt enne uue rakenduse versiooni v\u00e4ljalaskmist:<\/li>\n<li>Lisatakse uusi v\u00e4lju, kuhu salvestame just v\u00e4rskendatud andmed. <\/li>\n<li>Kandime andmeid vanast v\u00e4ljast uude v\u00e4ljast v\u00e4ikeste osade kaupa. Miks me seda teeme? Esiteks, me kontrollime alati protsessi k\u00e4iku. Me teame, et oleme juba nii palju partiiid viinud ja meil on veel nii palju j\u00e4\u00e4nud. <\/li>\n<li>Teine positiivne aspekt on see, et iga sellise partii vahel sulgeme transaktsiooni, avame uue ja see v\u00f5imaldab automaatset vaakumit tabeli suhtes t\u00f6\u00f6tada, m\u00e4rgistada surnud read taaskasutamiseks. <\/li>\n<li>Ridade jaoks, mis ilmuvad rakenduse t\u00f6\u00f6 k\u00e4igus (meil on endiselt aktiivne vana rakendus), lisame vallandaja, mis salvestab uued v\u00e4\u00e4rtused uutesse v\u00e4ljadessse. Meie puhul - see on vana v\u00e4\u00e4rtuse korrutamine sajaga. <\/li>\n<li>Kui me oleme t\u00f5eliselt kangekaelsed ja soovime sama v\u00e4lja, siis p\u00e4rast k\u00f5iki migratsioone ja enne uue rakenduse versiooni k\u00e4ivitamist lihtsalt nimetame v\u00e4ljaanded \u00fcmber. Vanad mingiks v\u00e4ljam\u00f5eldud nimeks ja uued v\u00e4ljad nimetame vanadeks. <\/li>\n<li>Ainult p\u00e4rast seda k\u00e4ivitame uue versiooni rakendusest. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ja sellega ei teki meil bloat'i ega ole meil j\u00f5udluse kaotust. <\/p>\n<p><\/p>\n<p>Sellega l\u00f5ppes kolmas lugu. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"T\u00fc\u00fcpilised vead rakendustes, mis p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" 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>N\u00fc\u00fcd r\u00e4\u00e4gime veidi rohkem t\u00f6\u00f6riistadest, millest mainisin k\u00f5ige esimeses loos. <\/p>\n<p><\/p>\n<p>Enne kui otsite bloat'i, on kindlasti vajalik paigaldada laiendus. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.postgresql.org\/docs\/current\/pgstattuple.html\">pgstattuple<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Kuna te ei pea ise p\u00e4ringuid v\u00e4lja m\u00f5tlema, oleme oma t\u00f6\u00f6s need p\u00e4ringud juba valmis kirjutanud. Te saate neid kasutada. Siin on esitatud kaks p\u00e4ringut. <\/p>\n<p><\/p>\n<ul>\n<li>Esimene t\u00f6\u00f6tab \u00fcsna kaua, kuid n\u00e4itab t\u00e4pseid bloat'i v\u00e4\u00e4rtusi tabeli l\u00f5ikes. <\/li>\n<li>Teine t\u00f6\u00f6tab kiiremini ja on v\u00e4ga efektiivne, kui tuleb kiiresti hinnata \u2013 kas tabelis on bloat v\u00f5i ei. Ja te peaksite m\u00f5istma, et bloat Postgresi tabelites on alati olemas. See on MVCC mudeli omadus. <\/li>\n<li>Ja 20% bloat on enamasti tabelite puhul normaalne. See t\u00e4hendab, et te ei pea muretsema ja seda tabelit kompresseerima. <\/li>\n<\/ul>\n<p><\/p>\n<p>Kuidas tuvastada vale suurusega tabeleid, oleme aru saanud, kui nad paisuvad kasututest andmetest. <\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd r\u00e4\u00e4gime, kuidas paisumist parandada:<\/p>\n<p><\/p>\n<ul>\n<li>Kui meil on v\u00e4ike tabel ja head kettad, st kuni \u00fche gigabaidini tabeliis on t\u00e4iesti v\u00f5imalik kasutada VACUUM FULL. See annab teile eksklusiivse lukustuse tabelile paariks sekundiks, aga teeb selle kiiresti ja efektiivselt. Mida teeb VACUUM FULL? See v\u00f5tab eksklusiivse lukustuse tabelile ja kirjutab vanad read uude tabelisse. L\u00f5pus vahetab need omavahel. Vanad failid kustutab ja uued asendab vanadega. Ent oma t\u00f6\u00f6 ajal v\u00f5tab see eksklusiivse lukustuse tabelilt. See t\u00e4hendab, et te ei saa selle tabeliga midagi teha: ei saa kirjutada, lugeda ega muuta. Ja VACUUM FULL vajab diskil lisaruumi andmete salvestamiseks.<\/li>\n<li>J\u00e4rgmine t\u00f6\u00f6riist <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/reorg\/pg_repack\">pg_repack<\/a><\/noindex>. Selle p\u00f5him\u00f5te on v\u00e4ga sarnane VACUUM FULL-ile, kuna see kirjutab samuti andmed vanadest failidest uutesse ja asendab neid tabelis. Kuid see ei v\u00f5ta alguses eksklusiivset lukku tabelile, vaid ainult siis, kui andmed on juba valmis failide asendamiseks. Diskiruumi n\u00f5udmised on sarnased VACUUM FULL-iga. Teil on vaja t\u00e4iendavat ruumi kettal, mis v\u00f5ib vahel olla kriitiline, kui teil on terabaidised tabelid. Samuti on see \u00fcsna protsessorin\u00e4ljane, kuna teeb aktiivset sisendi-v\u00e4ljaannet. <\/li>\n<li>Kolmas utiliit on <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dataegret\/pgcompacttable\">pgcompacttable<\/a><\/noindex>. See k\u00e4sitleb ressursse s\u00e4\u00e4stlikumalt, kuna t\u00f6\u00f6tab veidi erinevatel p\u00f5him\u00f5tetel. pgcompacttable peamine idee on see, et see viib tabelis k\u00f5ik elusread algusesse uuendustega. Ja seej\u00e4rel k\u00e4ivitab vakkuumi selle tabeli peal, kuna teame, et alguses on elusread ja l\u00f5pus surnud read. Ja vakkuum ise l\u00f5ikab juba selle sabaga, st t\u00e4iendavat ketta ruumi ei n\u00f5uta palju. Samuti saab seda ressursse s\u00e4\u00e4stlikumalt suruda. <\/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 p\u00f5hjustavad postgreSQL-is bloat&#039;i. Andrei S\u00f5lnikov\" src=\"\/wp-content\/uploads\/2020\/05\/4187915e54e54a0b85a342fe0280f78f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kui teema bloat teid huvitab ja soovite s\u00fcgavamale sukelduda, 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 link. See k\u00e4sitleb \u00fcldiselt, kuhu kaob ruum Postgres'i t\u00f6\u00f6 ja elu jooksul. Seal on v\u00e4ga suur ja p\u00f5hjalik tehniline osa andmebaasi administraatoritele 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 repole, kus hoiame hulga kasulikke skripte andmebaasi seisundi kontrollimiseks. Sealt 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> lingid t\u00f6\u00f6riistadele, mis aitavad teil tabeleid kokku suruda. <\/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 link minu kolleegi postitusele. Seal k\u00e4sitleb ta bloat'i \u00fcsna t\u00f5siselt ja p\u00f5hjalikult, juba tasemel, mis on l\u00e4henev administraatoritele. <\/li>\n<\/ul>\n<p><\/p>\n<p>Ma p\u00fc\u00fcdsin rohkem n\u00e4idata hirmu sellel tasemel, mis arendajatele, sest nad on otsesed meie andmebaasi kliendid ja peavad aru saama, kuhu millised tegevused viivad. 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 hangusid mitte ainult seet\u00f5ttu, et need p\u00f6\u00f6rdusid m\u00f5ne v\u00e4listeenuse poole. Need olid lihtsalt m\u00f5ningad metsikud joins. Seal olid mingid pisikesed, kahjutud p\u00e4ringud, mis p\u00e4evad viibisid, ja siis hakkasid mingit jama tegema. See on v\u00e4ga sarnane sellele, mida te kirjeldasite. Kuidas seda j\u00e4lgida? Kas peab pidevalt vaatama, milline p\u00e4ring on kinni? Kuidas seda ennetada?<\/em><\/p>\n<p><\/p>\n<p>Antud juhul on see teie ettev\u00f5tte administraatorite \u00fclesanne, mitte tingimata DBA.<\/p>\n<p><\/p>\n<p><em>Mina olen administraator.<\/em><\/p>\n<p><\/p>\n<p>PostgreSQL-is on olemas vaade nimega pg_stat_activity, kus on n\u00e4ha kinni j\u00e4\u00e4nud p\u00e4ringud. Ja saate n\u00e4ha, kui kaua need seal on olnud.<\/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 ja kontrollige. Kui teil on pikaajaline p\u00e4ring, saatke kiri ja k\u00f5ik. Te ei pea seda visuaalselt j\u00e4lgima, see on automatiseeritav. Te saate kirja, reageerite sellele. V\u00f5ite ka automaatselt k\u00e4ituda.<\/p>\n<p><\/p>\n<p><em>Kas on selged p\u00f5hjused, miks see juhtub?<\/em><\/p>\n<p><\/p>\n<p>Mina nime olen mitmed loetledes. Teised on keerukamad n\u00e4ited. See vestlus v\u00f5ib v\u00f5tta kaua aega.<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Soovin t\u00e4psustada pg_repack utiliidi kohta. Kui see ei kehtesta eksklusiivset lukku, siis\u2026<\/em><\/p>\n<p><\/p>\n<p>See loob eksklusiivse luku. <\/p>\n<p><\/p>\n<p>\u2026 <em>Siis v\u00f5in ma 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, st pg_repack liigub esmalt k\u00f5ik elavad read, mis seal on. Loomulikult toimub seal mingisugune kirje tabelis. Ta lihtsalt lisab selle l\u00f5pu. <\/p>\n<p><\/p>\n<p><em>St l\u00f5puks teeb ta seda ikkagi?<\/em><\/p>\n<p><\/p>\n<p>L\u00f5puks v\u00f5tab ta eksklusiivse luku, et neid faile vahetada. <\/p>\n<p><\/p>\n<p><em>Kas see on kiiremini kui VACUUM FULL?<\/em><\/p>\n<p><\/p>\n<p>VACUUM FULL, kui see alustas, v\u00f5ttis kohe eksklusiivse luku. Ja seni, kuni ta ei ole k\u00f5ike l\u00f5petanud, ei vabasta ta seda. Aga pg_repack v\u00f5tab eksklusiivse luku ainult failide vahetamise hetkeks. Sel ajal ei saa te sinna kirjutada, kuid andmed ei kao, k\u00f5ik on korras. <\/p>\n<p><\/p>\n<p><em>Tere! Te r\u00e4\u00e4kisite automaatse vaakumi toimimisest. Seal oli graafik punaste, kollaste ja roheliste lahtritega. T. e. kollased \u2013 ta m\u00e4rkis need kui kustutatud. Ja seet\u00f5ttu saab neisse kirjutada midagi uut?<\/em><\/p>\n<p><\/p>\n<p>Jah. Postgres ei kustuta ridu. Sellel on selline erip\u00e4ra. Kui me uuendame rida, siis m\u00e4rkisime vana kui kustutatud. Seal on tehingu id, mis muutis seda rida, ja kirjutame uue rea. Ja meil on sessioonid, mis v\u00f5ivad neid lugeda. Mingil hetkel muutuvad nad juba t\u00e4iesti vanaks. Ja automaatse vaakumi t\u00f6\u00f6 idee on selles, et ta jookseb nende ridade vahelt l\u00e4bi ja m\u00e4rkib nad kui mittevajalikud. Ja sinna saab andmeid \u00fcle kirjutada. <\/p>\n<p><\/p>\n<p><em>M\u00f5istsin. Kuid k\u00fcsimus ei ole sellest. Ma ei l\u00f5petanud. Oletame, et meil on tabel. Seal on muutuva suurusega v\u00e4ljad. Ja kui ma \u00fcritan midagi uut lisada, siis see ei pruugi lihtsalt vanasse lahtrisse mahtuda.<\/em> <\/p>\n<p><\/p>\n<p>Ei, seal igal juhul v\u00e4rskendatakse kogu rida. Postgresis on andmete salvestamiseks kaks mudelit. See valib andme t\u00fc\u00fcbist l\u00e4htuvalt. On andmeid, mis salvestatakse otse tabelisse, ning on ka tos-andmeid. Need on suured andmehulgad: tekst, json. Need salvestatakse eraldi tabelitesse. Ja nende tabelite puhul kehtib sama lugu bloat'iga, st k\u00f5ik on sama. Lihtsalt need on eraldi v\u00e4lja toodud. <\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Kui vastuv\u00f5etav on kasutada p\u00e4ringute kestuse piiramiseks statement timeout'i?<\/em><\/p>\n<p><\/p>\n<p>V\u00e4ga vastuv\u00f5etav. Me kasutame seda igal pool. Kuna meil ei ole oma teenuseid, pakume veebip\u00f5hist tuge ning meie kliendid on \u00fcsna erinevad. K\u00f5ik on sellega t\u00e4iesti rahul. St meil on cron'is \u00fclesanded, mis kontrollivad. Lihtsalt lepitakse kliendiga kokku sessioonide kestus, mille eel me ei katkesta. See v\u00f5ib olla minut v\u00f5i 10 minutit. See s\u00f5ltub andmebaasi koormusest ja selle eesm\u00e4rgist. Kuid k\u00f5igil kasutame pg_stat_activity.<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Proovin teie ettekannet oma rakendustele rakendada. Tundub, et igal pool alustame tehingut, l\u00f5petame selle selgelt. Kui on mingisugune erand, siis ikkagi toimub rollback. Siis m\u00f5tlesin. Tehing v\u00f5ib alata ju ka mitte selgelt. See v\u00f5ib olla vihje t\u00fcdrukule, ilmselt. Kui ma lihtsalt uuendan \u0437\u0430\u043f\u0438\u0441\u0438, algab PostgreSQL\u2019is tehing ja see l\u00f5peb alles siis, kui \u00fchendus katkeb?<\/em><\/p>\n<p><\/p>\n<p>Kui r\u00e4\u00e4gite n\u00fc\u00fcd rakenduse tasemest, siis see s\u00f5ltub kasutatavast draiverist, sellest ORM-ist, mida kasutatakse. Seal on palju seadistusi. Kui teil on auto commit sisse l\u00fclitatud, siis tehing algab ja kohe sulgub.<\/p>\n<p><\/p>\n<p><em>St. t\u00e4hendab, et see sulgub kohe p\u00e4rast uuendamist?<\/em><\/p>\n<p><\/p>\n<p>See s\u00f5ltub seadistustest. \u00dcht seadistust mainisin. See on auto commit. See on \u00fcsna levinud. Kui see on sisse l\u00fclitatud, siis tehing avatakse ja suletakse. Kui te ei ole selgelt \u00f6elnud 'start transaction' ja 'end transaction', vaid lihtsalt k\u00e4ivitasite p\u00e4ringu seansis. <\/p>\n<p><\/p>\n<p><em>Tere! Ait\u00e4h ettekande eest! Kujutame ette, et meil on andmebaas, mis kasvab pidevalt ja serveris hakkab ruum otsa saama. Kas on mingeid t\u00f6\u00f6riistu, et seda olukorda parandada?<\/em> <\/p>\n<p><\/p>\n<p>Serveri ruumi tuleks kindlasti j\u00e4lgida. <\/p>\n<p><\/p>\n<p><em>N\u00e4iteks DBA l\u00e4ks teed jooma, oli kuurordis jne.<\/em><\/p>\n<p><\/p>\n<p>Kui failis\u00fcsteem luuakse, siis seal luuakse v\u00e4hemalt mingi reserveeritud ruum, kuhu andmeid ei kirjutata. <\/p>\n<p><\/p>\n<p><em>Ent kui ruum on t\u00e4iesti nullis?<\/em><\/p>\n<p><\/p>\n<p>Seal on see nimega reserved space, st seda on v\u00f5imalik vabastada ja s\u00f5ltuvalt sellest, kui suurt seda on loodud, saate vabade kohtade. Vaikimisi ei tea ma, kui palju seal on. Teises olukorras tuleb toimetada kettaid, et oleks ruumi taastamise operatsiooni l\u00e4biviimiseks. Saate eemaldada mingi tabeli, mis teil kindlasti ei ole vajalik. <\/p>\n<p><\/p>\n<p><em>Teisi t\u00f6\u00f6riistu ei ole?<\/em><\/p>\n<p><\/p>\n<p>See on alati k\u00e4sitsi tehtav t\u00f6\u00f6. Ja ruumi osas selgub, mis seal parem oleks teha, kuna andmed on kriitilised ja mitte kriitilised. Iga andmebaasi ja rakenduse puhul, mis sellega t\u00f6\u00f6tab, s\u00f5ltub see ettev\u00f5ttest. Alati toimub otsus ruumi alusel. <\/p>\n<p><\/p>\n<p><em>Ait\u00e4h ettekande eest! Mul on kaks k\u00fcsimust. Esiteks, te demonstreerisite slaide, kus n\u00e4idati, et hetkeseisus olevate tehingute korral kasvab nii tabeliruumi maht kui ka indeksi suurus. Ja edasi ettekandes oli palju utiliite, mis pakivad tabelit. Aga mis juhtub indeksiga?<\/em><\/p>\n<p><\/p>\n<p>Need pakivad ka neid. <\/p>\n<p><\/p>\n<p><em>Aga vakuum ei puuduta indexit?<\/em><\/p>\n<p><\/p>\n<p>M\u00f5ned t\u00f6\u00f6tlused puudutavad indekseid. N\u00e4iteks, pg_rapack, pgcompacttable. Vakuum taastab indeksid, see m\u00f5jutab neid. VACUUM FULL-i m\u00f5te on k\u00f5ik uuesti kirjutada, st see t\u00f6\u00f6tab k\u00f5igiga. <\/p>\n<p><\/p>\n<p><em>Ja teine k\u00fcsimus. Ma ei saanud aru, miks raportid replikaates nii palju s\u00f5ltuvad replikatsioonist. Mul tundus, et raportid on lugemine ja replikatsioon on kirjutamine.<\/em> <\/p>\n<p><\/p>\n<p>Milles seis on replikatsiooni konflikt? Meil on Master, kus toimuvad protsessid. Meil on automaatne vaakum. Mida teeb automaatne vaakum? Ta eemaldab m\u00f5ned vanad read. Kui sel ajal on replikas p\u00e4ring, mis loeb neid vanu ridu, ja Masteris on olukord, kus automaatne vaakum on need read m\u00e4rkinud kui v\u00f5imalikud kirjutamiseks, siis me kirjutame need \u00fcle. Ja me saame andmepaki, kui peame kirjutama \u00fcle need read, mis on vajalikud p\u00e4ringu jaoks replikas, siis replikatsioon ootab m\u00e4\u00e4ratud ajamisaega, mille olete seadistanud. Ja siis otsustab PostgreSQL, mis on tema jaoks olulisem. Ja replikatsioon on tema jaoks olulisem kui p\u00e4ring ning ta katkestab p\u00e4ringu, et teha need muudatused replikas. <\/p>\n<p><\/p>\n<p><em>Andrei, mul on k\u00fcsimus. Need imelised graafikud, mida te esitlemise ajal n\u00e4itasite, on need tulemused mingist teie utiliidist? Millest graafikud on koostatud?<\/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 4.9.10 - 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 \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\" \/>\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) 4.9.10\" \/>\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 \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\" \/>\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 PostgreSQL \u00fclekoormuseni. Andrei Salnikov | ProHoster","description":"Tutvustan 2016. aasta alguses Andrei Salnikovi esitatud ettekande \"T\u00fc\u00fcpilised vead rakendustes, mis viivad PostgreSQL \u00fclekoormuseni\" sisu. Selles ettekandes k\u00e4sitlen peamisi vigu, mis rakendustes tekivad projekteerimise ja koodi kirjutamise etapis. Vaatlen ainult neid vigu, mis viivad PostgreSQL \u00fclekoormuseni. Reeglina on need tuleviku j\u00f5udluse alguspunkt.","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 \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","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"},"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}]}}