Прапаную азнаёміцца з расшыфроўкай даклада пачатку 2016 года Андрэя Сальнікава "Тыпавыя памылкі ў дадатках, якія вядуць да bloat у postgresql"
У дадзеным дакладзе я разбяру асноўныя памылкі ў дадатках, якія ўзнікаюць на этапе праектавання і напісання кода прыкладання. І вазьму толькі тыя памылкі, якія вядуць да bloat у Postgresql. Як правіла, гэта пачатак канца прадукцыйнасці вашай сістэмы ў цэлым, хоць першапачаткова ніякіх перадумоў да гэтага не было бачна.
Рады ўсіх вітаць! Гэты даклад не такі тэхнічны, як папярэдні ад майго калегі. Гэты даклад арыентаваны на распрацоўшчыкаў бэкэнд-сістэм у асноўным, таму што ў нас дастаткова вялікая колькасць кліентаў. І ўсе яны здзяйсняюць адны і тыя ж памылкі. Пра іх я вам раскажу. Растлумачу да чаго фатальнага і дрэннага вядуць гэтыя памылкі.
Чаму здзяйсняюцца памылкі? Здзяйсняюцца яны па двух прычынах: на авось, можа так пракоціць і ад няведання нейкіх механізмаў, якія адбываюцца на ўзроўні паміж базай і дадаткам, а таксама ў самой базе.
Я вам прывяду тры прыклады з жудаснымі карцінкамі таго, як усё стала дрэнна. Сцісла раскажу пра механізм, які там адбываецца. І як з імі змагацца, калі яны здарыліся, і якія прэвентыўныя метады выкарыстоўваць для прадухілення памылак. Раскажу аб дапаможных інструментах і дам карысныя спасылкі.
Я выкарыстоўваў тэставую базу дадзеных, дзе ў мяне было дзве таблічкі. Адна таблічка з рахункамі кліентаў, іншая з аперацыямі па гэтых рахунках. І з нейкай перыядычнасцю мы абнаўляем рэшткі на гэтых рахунках.
Зыходныя дадзеныя таблічкі: яна дастаткова невялікая, 2 MB. Час адказу па базе і менавіта па таблічцы таксама вельмі добры. І дастаткова добрая нагрузка - 2 000 аперацый у секунду па таблічцы.
І праз гэты даклад я вам буду паказваць графікі, каб наглядна было зразумела, што адбываецца. Заўсёды будзе 2 слайда з графікамі. Першы слайд - гэта тое, што адбываецца ўвогуле на серверы.
І ў дадзенай сітуацыі мы бачым, што сапраўды ў нас таблічка невялікага памеру. Індэкс невялікі ў 2 MB. Гэта першы злева графік.
Сярэдні час адказу па серверы таксама стабільны, невялікі. Гэта правы верхні графік.
Левы ніжні графік - гэта самыя працяглыя транзакцыі. Мы бачым, што транзакцыі хутка выконваюцца. І аўтавакуум тут яшчэ не працуе, таму што - гэта быў старт-тэст. Далей ён будзе працаваць і будзе карысны нам.
Другі слайд заўсёды будзе прысвечаны падыспытнай таблічцы. У гэтай сітуацыі мы абнаўляем увесь час рэшткі па рахунках у кліента. І мы бачым тое, што сярэдні час адказу па аперацыі абнаўлення дастаткова добры, менш мілісекунды. Бачым, што рэсурсы працэсара (гэта правы верхні графік) спажываюцца таксама раўнамерна і дастаткова невялікія.
Правы ніжні графік паказвае, колькі памяці аперацыйнай і дыскавай мы перабіраем у пошуках нашага патрэбнага радка, перш чым яе абнавіць. І колькасць аперацыя па таблічцы - 2 000 у секунду, як і спачатку я казаў.
І зараз у нас адбываецца трагедыя. Па нейкай прычыне ўзнікае доўгая забытая транзакцыя. Чыннікі звычайна ўсё банальныя:
- Адна з самых распаўсюджаных - гэта тое, што мы ў кодзе прыкладання пачалі звяртацца да знешняга сэрвісу. І гэты сервіс нам не адказвае. Т. е. мы адкрылі транзакцыю, зрабілі змену ў базе і пайшлі з прыкладання пошту пачытаць ці да іншага сэрвісу ў рамках нашай інфраструктуры, і ён па нейкай прычыне нам не адказвае. І ў нас павісла сесія ў стане - невядома, калі вырашыцца.
- Другая сітуацыя, калі ў нас у кодзе па нейкай прычыне адбыўся exception. І мы ў exception не апрацавалі зачыненне транзакцыі. І ў нас атрымалася вісіць сесія з адкрытай транзакцыяй.
- І апошні - гэта таксама даволі часты выпадак. Гэта няякасны код. Некаторыя фрэймворкі адкрываюць транзакцыю. Яна вісіць, і вы можаце не ведаць у дадатку, што яна ў вас вісіць.
Да чаго вядуць такія рэчы?
Да таго, што ў нас пачынаюць рэзка раздзімацца табліцы і азначнікі. Гэта якраз гэты эфект bloat. Для базы гэта будзе выяўляцца ў тым, што ў нас вельмі рэзка павялічыцца час адказу базы даных, павялічыцца нагрузка на сервер базы даных. І як вынік у нас будзе пакутаваць дадатак. Таму што калі вы ў кодзе марнавалі 10 мілісекунд на запыт у базу, 10 мілісекунд на сваю логіку, то ў вас функцыя адпрацоўвала 20 мілісекунд. А зараз у вас сітуацыя будзе зусім сумная.
І давайце паглядзім, што адбываецца. Левы ніжні графік паказвае, што ў нас доўгая доўгая транзакцыя. І калі мы паглядзім на левы верхні графік, то мы бачым, што памер табліцы з двух мегабайт у нас рэзка скакнуў у 300 мегабайт. Пры гэтым колькасць дадзеных у табліцы не змянілася, т. е. тамака досыць вялікая колькасць смецця.
Агульная сітуацыя па сярэднім часе адказу сервера таксама змянілася на некалькі парадкаў. Т. е. усе запыты па серверы пачалі капітальна прасядаць. І пры гэтым запусціліся ўнутраныя працэсы Postgres у асобе аўтавакуума, якія нешта спрабуюць рабіць і спажываюць рэсурсы.
Што ж з нашай таблічкай адбываецца? Тое ж самае. Сярэдні час адказу па таблічцы ў нас скокнуў на некалькі парадкаў уверх. Калі менавіта па спажываных рэсурсах, то мы бачым, што вельмі моцна павялічылася нагрузка на працэсар. Гэта правы верхні графік. І павялічылася яна таму што, працэсару даводзіцца перабіраць кучу бескарысных радкоў у пошуках адной патрэбнай. Гэта правы ніжні графік. І як вынік - колькасць выклікаў у секунду ў нас пачало прасаджвацца вельмі моцна, таму што база не паспявае апрацоўваць тое ж колькасць запытаў.
Нам трэба вяртацца да жыцьця. Лезем у інтэрнэт і даведаемся, што доўгія транзакцыі прыводзяць да праблемы. Знаходзім і забіваем гэтую транзакцыю. І ў нас усё становіцца нармальна. Усё працуе як трэба.
Мы супакоіліся, але праз некаторы час пачынаем заўважаць, што прыкладанне працуе не так, як да аварыйнай сітуацыі. Запыты апрацоўваюцца ўсё роўна павольней, прычым істотна павольней. У паўтара-два разы павольней менавіта ў маім прыкладзе. Нагрузка на сервер таксама вышэйшая, чым была да аварыі.
І пытанне: "Што адбываецца з базай у гэты момант?". А з базай адбываецца наступная сытуацыя. На графіцы транзакцый вы бачыце, што яна спынілася і там сапраўды няма працяглых транзакцый. Але памеры таблічкі падчас аварыі ў нас фатальна выраслі. І з таго часу не зменшыліся. Сярэдні час па базе стабілізаваўся. І адказы быццам ходзяць адэкватна з прымальнай для нас хуткасцю. Аўтавакуум стаў больш актыўным і пачаў нешта рабіць з таблічкай, таму што яму трэба пералапачваць большую колькасць дадзеных.
Менавіта па падыспытнай таблічцы з рахункамі, дзе мы мяняем рэшткі: час адказу па запыце быццам бы вярнулася ў норму. Але насамрэч яно ў паўтара раза вышэйшае.
І па нагрузцы на працэсар мы бачым, што нагрузка на працэсар не вярнулася ў патрэбную велічыню да аварыі. І прычыны там крыюцца якраз у правым ніжнім графіку. Відаць, што там адбываецца перабор нейкай колькасці памяці. Т. е. для пошуку патрэбнага радка мы марнуем рэсурсы сервера база дадзеных пры пераборцы бескарысных дадзеных. Колькасць транзакцый за секунду стабілізавалася.
Увогуле добра, але сітуацыя горшая, чым была. Відавочная дэградацыя базы дадзеных як следства нашага прыкладання, якое працуе з гэтай базай дадзеных.
І каб разабрацца, што там адбываецца, калі вы не былі на папярэднім дакладзе, то зараз трошачкі тэорыі. Тэорыя аб працэсе ўнутраным. Навошта аўтавакуум і што ён робіць?
Літаральна сцісла для разумення. У нейкі момант часу мы маем табліцу. У табліцы ў нас знаходзяцца радкі. Гэтыя радкі могуць быць актыўныя, жывыя, патрэбныя нам зараз. На малюнку яны пазначаныя зялёным колерам. І ёсць радкі мёртвыя, якія ўжо адпрацавалі, былі абноўлены, па іх з'явіліся новыя запісы. І яны пазначаныя, што яны ўжо не цікавыя базе дадзеных. Але ляжаць у табліцы з-за асаблівасці Postgres.
Навошта патрэбен аўтавакуум? Аўтавакуум у нейкі момант прыходзіць, звяртаецца да базы дадзеных і пытаецца ў яе: "Дай мне, калі ласка, id самай старой транзакцыі, якая адкрыта на дадзены момант у базе дадзеных". База даных вяртае гэты id. І аўтавакуум абапіраючыся на яго перабірае радкі ў табліцы. І калі бачыць, што нейкія радкі былі змененыя транзакцыямі куды больш старымі, то ён мае права іх пазначыць як радкі, якія мы можам перавыкарыстоўваць у будучыні, запісаўшы туды новыя дадзеныя. Гэта фонавы працэс.
Мы ў гэты час працягваем працаваць з базай дадзеных, працягваем рабіць нейкія змены ў табліцы. І на гэтыя радкі, якія мы можам перавыкарыстоўваць, запісваем новыя дадзеныя. І такім чынам у нас атрымліваецца кругазварот, т. е. увесь час тамака ўзнікаюць нейкія мёртвыя старыя радкі, замест іх мы запісваем новыя радкі, якія нам патрэбныя. І гэты нармальны стан для працы PostgreSQL.
Што адбылося падчас аварыі? Як там адбываўся гэты працэс?
Мы мелі таблічку ў нейкім стане, нейкія жывыя, нейкія мёртвыя радкі. Прыйшоў аўтавакуум. Ён спытаў базу дадзеных аб тым, якая ў нас самая даўняя транзакцыя, які ў яе id. Атрымаў гэты id, які можа быць шматгадзіннай даўніны, можа дзесяціхвілінны. Гэта залежыць ад таго, наколькі моцная нагрузка ў вас у базе дадзеных. І пайшоў шукаць радкі, якія ён можа пазначыць як перавыкарыстоўваемыя. І не знайшоў такіх радкоў у нашай табліцы.
Але мы тым часам працягваем працаваць з табліцай. Нешта робім у ёй, абнаўляем, мяняем дадзеныя. А што базе дадзеных у гэты час рабіць? Ёй нічога не застаецца, як дапісваць новыя радкі ў канец існуючай табліцы. І тым самым у нас памер табліцы пачынае раздзімацца.
Рэальна нам для працы патрэбны зялёныя радкі. Але падчас такой праблемы ў нас атрымліваецца, што працэнт зялёных радкоў вельмі нізкі ва ўсім аб'ёме табліцы.
А калі мы выконваем запыт, базе дадзеных даводзіцца прабягацца па ўсіх радках: і чырвоным, і зялёным, каб знайсці патрэбны радок. І эфект разадзьмутыя табліцы бескарыснымі дадзенымі завецца «bloat», які яшчэ і есць наша дыскавая прастора. Памятаеце, было 2 МБ, стала 300 МБ? А зараз памяняйце мегабайты на гігабайты і вы так досыць хутка пазбавіцеся ўсіх запасаў сваіх дыскавых рэсурсаў.
Якія наступствы могуць быць для нас?
- У маім прыкладзе табліца і індэкс выраслі ў 150 разоў. У некаторых нашых кліентаў бывалі больш фатальныя выпадкі, калі проста месца на дыску пачыналася заканчвацца.
- Памер табліц сам па сабе ніколі не паменшыцца. Аўтавакуум у некаторых выпадках можа адрэзаць хвосцік табліцы, калі там толькі мёртвыя радкі. Але паколькі адбываецца пастаянная ратацыя, адзін зялёны радок можа ў канцы завіснуць і не абнаўляцца, а ўсе астатнія недзе ў пачатку таблічкі будуць запісвацца. Але гэта настолькі малаверагодная падзея, што ў вас сама па сабе табліца паменшыцца ў памерах, што не варта на гэта спадзявацца.
- Базе дадзеных трэба перабіраць увесь стос бескарысных радкоў. І мы трацім дыскавыя рэсурсы, трацім рэсурсы працэсара і электраэнергію.
- І гэта непасрэдна ўплывае на наша дадатак, таму што калі ў пачатку мы марнавалі 10 мілісекунд на запыт, 10 мілісекунд на наш код, то падчас аварыі мы сталі марнаваць секунду на запыт і 10 мілісекунд на код, т. е. на парадак прадукцыйнасць прыкладання знізілася. І калі дазволілі аварыю ў нас стала траціцца 20 мілісекунд на запыт, 10 мілісекунд на код. Гэта значыць, што мы ўсё роўна аселі ў паўтара раза па прадукцыйнасці. І гэта ўсё праз адну транзакцыю, якая падвісла, прычым, магчыма, па нашай віне.
- І пытанне: "Як усё вярнуць назад?", каб у нас стала ўсё добра і запыты забягалі таксама хутка, як да аварыі.
Для гэтага ёсць пэўны цыкл прац, які праводзіцца.
Спачатку нам неабходна знайсці праблемныя табліцы, якія надзьмуліся. Мы разумеем, што па нейкіх табліцах запіс ідзе больш актыўна, па нейкіх менш актыўнах. І для гэтага выкарыстоўваецца пашырэнне . Усталяваўшы гэта пашырэнне, вы можаце напісаць запыты, якія дапамогуць вам знайсці табліцы, якія надзьмуліся дастаткова моцна.
Пасля таго як вы знайшлі гэтыя табліцы, іх неабходна сціснуць. Для гэтага ёсць ужо прылады. У нашай кампаніі мы выкарыстоўваем тры інструменты. Першы - убудаваны VACUUM FULL. Ён жорсткі, суровы і бязлітасны, але часам ён вельмі карысны. и - гэта іншыя ўтыліты для сціску табліц. І яны больш беражліва ставяцца да базы дадзеных.
Яны выкарыстоўваюцца ў залежнасці ад таго, што вам зручней. Але пра гэта я раскажу ў самым канцы. Галоўнае, што ёсць тры інструменты. Ёсць з чаго абраць.
Пасля таго, як мы ўсё паправілі, пераканаліся, што ўсё стала добра, мы павінны ведаць, як прадухіліць гэтую сітуацыю ў будучыні:
- Прадухіляецца яна дастаткова лёгка. Трэба сачыць за працягласцю сесій на Майстар-серверы. Асабліва небяспечныя сесіі ў стане idle in transaction. Гэта тыя, якія якраз адкрылі транзакцыю, нешта зрабілі і сышлі ці проста павіслі, згубіліся ў кодзе.
- І для вас, як для распрацоўшчыкаў, важна тэставаць код на момант узнікнення дадзеных сітуацый. Гэта не складана зрабіць. Гэта будзе карысная праверка. Вы пазбегнеце вялікую колькасць «дзіцячых» праблем, злучаных з працяглымі транзакцыямі.
На гэтых графіках я вам жадаў паказаць, як змянілася таблічка і паводзіны базы дадзеных пасля таго, як я мінуў у дадзеным выпадку VACUUM FULL'ом па шыльдзе. Гэта ў мяне не production.
Памер табліцы вярнуўся адразу ў нармальны працоўны стан у пару мегабайт. На сярэдні час адказу па серверы гэта не моцна паўплывала.
Але менавіта па нашай падыспытнай таблічцы, дзе мы абнаўлялі рэшткі на рахунках, мы бачым, што сярэдні час адказу па запыце абнаўлення дадзеных у таблічцы скарацілася да дааварыйнага ўзроўня. Рэсурсы, якія спажываюцца працэсарам на выкананне гэтага запыту, таксама ўпалі да дааварыйнага ўзроўню. І правы ніжні графік паказвае, што цяпер мы знаходзім роўна той радок, які патрэбны нам адразу, не перабіраючы скоп мёртвых радкоў, якія былі да сціску табліцы. І сярэдні час запытаў прыкладна на тым самым узроўні застаўся. Але тут у мяне хутчэй хібнасць майго жалеза.
На гэтым першая гісторыя скончылася. Яна самая распаўсюджаная. І здараецца ва ўсіх, незалежна ад досведу кліента, наколькі тамака кваліфікаваныя праграмісты. Рана ці позна гэта адбываецца.
Гісторыя другая, у якой мы размяркоўваем нагрузку і аптымізуем серверныя рэсурсы
- Мы ўжо выраслі і сталі сур'ёзнымі хлопцамі. І разумеем, што ў нас ёсць рэпліка і добра б нам збалансаваць нагрузку: пісаць на Майстар, а з рэплікі чытаць. І звычайна гэтая сітуацыя ўзнікае, калі мы жадаем рыхтаваць нейкія справаздачы ці ETL. І бізнэс гэтаму вельмі радуецца. Ён вельмі хоча разнастайных справаздач з кучай аналітыкі складанай.
- Справаздачы шматгадзінныя, таму што складаную аналітыку не палічыш за мілісекунды. Мы, як бравыя хлопцы, пішам код. Які робіцца ў дадатку ўстаўкі, што запіс мы вядзем на Майстар, справаздачы выконваем на рэпліцы.
- Размяркоўваем нагрузку.
- Усё працуе выдатна. Мы малайцы.
І як гэта сытуацыя выглядае? Менавіта на гэтых графіках я яшчэ для працягласці транзакцыі дадаў працягласць транзакцый з рэплікі. Усе астатнія графікі адносяцца толькі да Майстар-серверу.
Таблічка са справаздачамі да гэтага моманту ў мяне падрасла. Іх стала больш. Мы бачым, што сярэдні час адказу сервера стабільны. Мы бачым, што на рэпліцы ў нас ёсць працяглая транзакцыя, якая працуе 2 гадзіны. Бачым спакойную працу аўтавакуума, які апрацоўвае мёртвыя радкі. І ўсё ў нас добра.
Менавіта па падыспытнай таблічцы мы працягваем тамака абнаўляць рэшткі на рахунках. І ў нас таксама стабільны час адказу па запыце, стабільнае спажыванне рэсурсаў. Усё ў нас добра.
Усё добра да моманту, пакуль у нас гэтыя справаздачы не пачынаюць адстрэльвацца па канфлікце з рэплікацыяй. І адстрэльваюцца яны з сталай перыядычнасцю.
Мы лезем у інтэрнэт і пачынаем чытаць, чаму гэта адбываецца. І знаходзім рашэнне.
Першае рашэнне - павялічыць затрымку рэплікацыі. Мы ведаем, што ў нас справаздача працуе 3 гадзіны. Ставім затрымку рэплікацыі - 3 гадзіны. Запускаем усё, але ў нас усё роўна працягваюцца праблемы з тым, што справаздачы часам адстрэльваюцца.
Мы жадаем, каб у нас усё было ідэальна. Лезем далей. І знаходзім у інтэрнэце класную настройку - hot_standby_feedback. Уключаем яго. Hot_standby_feedback дазваляе нам прытрымаць працу аўтавакуума на Майстры. Тым самым мы зусім пазбаўляемся канфліктаў рэплікацыі. І нас усё працуе добра са справаздачамі.
А што тым часам у нас адбываецца з Майстар-серверам? А з Майстар-серверам у нас адбываецца татальная бяда. Цяпер мы назіраем графікі, калі я ўключыў абедзве гэтыя наладкі. І мы бачым, што сэсія на рэпліцы ў нас нейкім чынам стала ўплываць на сытуацыю на Майстар-сэрвэры. Яна сапраўды ўплывае, таму што яна прыпыніла аўтавакуум, які вычышчае мёртвыя радкі. У нас памер табліцы зноў скакнуў у нябёсы. Сярэдні час выканання запытаў па ўсёй базе дадзеных таксама скокнуў у нябёсы. Аўтавакуумы крыху паднапружыліся.
Менавіта па нашай шыльдзе мы бачым, што па ёй абнаўленне дадзеных таксама скокнула ў нябёсы. Спажыванне рэсурсаў працэсара аналагічна вельмі моцна павялічылася. Мы зноў перабіраем вялікую колькасць мёртвых бескарысных радкоў. І час адказу па гэтай таблічцы, колькасць транзакцый упала.
Як гэта будзе выглядаць, калі мы не ведаем, пра што я казаў раней?
- Мы пачынаем шукаць праблемы. Калі мы сутыкаліся з праблемамі ў першай частцы, мы ведаем, што гэта можа быць прычына ў доўгай транзакцыі і лезем на Майстар. Праблема ў нас на Майстры. Каўбасіць яго. Ён грэецца, у яго Load Average пад сотню.
- Запыты там тармозяць, але мы там не бачым ніякіх працяглых транзакцый. І не разумеем, у чым справа. Не разумеем, дзе шукаць.
- Правяраем сервернае абсталяванне. Можа быць у нас разваліўся raid. Можа, у нас згарэла планка памяці. Ды што заўгодна можа быць. Але не, серверы новыя, усё працуе выдатна.
- Бегаюць усё: адміністратары, распрацоўшчыкі і дырэктар. Нічога не памагае.
- І ў нейкі момант усё нечакана само пачынае выпраўляцца.
На рэпліцы ў нас тым часам запыт адпрацаваў і сышоў. Мы атрымалі справаздачу. Бізнэс усё яшчэ задаволены. Як бачым, таблічка ў нас вырасла зноў і не збіраецца памяншацца. На графіцы з сесіямі я пакінуў кавалачак вось гэтай доўгай транзакцыі з рэплікі, каб вы маглі ацаніць, наколькі працяглы час праходзіць, пакуль сітуацыя стабілізуецца.
Сесія сышла. І толькі праз нейкі час сервер прыходзіць больш-менш у парадак. І сярэдні час адказу па запытах на Майстар-серверы прыходзіць у норму. Таму што, нарэшце, аўтавакуум атрымаў магчымасць вычышчаць, адзначаць гэтыя мёртвыя радкі. І ён пачаў рабіць сваю працу. І наколькі хутка ён яе робіць, настолькі хутка мы прыйдзем у парадак.
Па падыспытнай таблічцы, дзе мы абнаўляем рэшткі па рахунках, мы бачым сапраўды такую ж карціну. Сярэдні час абнаўлення рахунку таксама нармалізуецца паступова. Рэсурсы, якія спажываюцца працэсарам, таксама памяншаюцца. І колькасць транзакцый за секунду вяртаецца ў норму. Але зноў у норму не ў такую, як была ў нас да аварыі.
Мы ў любым выпадку атрымліваем прасадку па прадукцыйнасці як і ў першым выпадку ў паўтара-два разы, а часам і больш.
Мы быццам зрабілі ўсё правільна. Размяркуй нагрузку. Абсталяванне не прастойвае. Па розуме разбілі запыты, але ўсё роўна ўсё дрэнна атрымалася.
- Ня ўключаць hot_standby_feedback? Так, яго без асабліва моцных прычын не рэкамендуецца ўключаць. Таму што гэтая круцілка непасрэдна ўплывае на Майстар-сервер і прыпыняе працу аўтавакуума там. Уключыўшы яго на нейкі рэпліцы і забыўшыся пра гэта, вы можаце забіць Майстар і атрымаць вялікія праблемы з дадаткам.
- Павялічваць max_standby_streaming_delay? Так, для справаздач - гэта так. Калі ў вас трохгадзінная справаздача і вы не хочаце, каб яна ў вас падала з-за канфліктаў рэплікацый, то проста павялічце затрымку. Працяглая справаздача ніколі не патрабуе дадзеных, якія прыйшлі ў базу прама зараз. Калі ён у вас трохгадзінны, значыць, вы яго запускаеце за нейкі стары перыяд дадзеных. І вам, што тры гадзіны затрымкі, што шэсць гадзін затрымкі - ніякай ролі не адыграе, але затое вы будзеце стабільна атрымліваць справаздачы і не ведаць праблем з падзеннем іх.
- Натуральна, трэба кантраляваць працяглыя сесіі на рэпліках, асабліва, калі вы вырашылі ўключыць hot_standby_feedback на рэпліцы. Бо можа быць што заўгодна. Далі гэтую рэпліку распрацоўніку, каб ён патэставаў запыты. Ён напісаў вар'ят запыт. Запусціў і сышоў піць гарбату, а мы атрымалі які склаўся Майстар. Ці мы туды пусцілі не тое дадатак. Сітуацыі разнастайныя. Сесіі на рэпліках неабходна кантраляваць таксама дакладна, як і на Майстры.
- І калі ў вас ёсць хуткія і працяглыя запыты па рэпліках, то ў дадзеным выпадку лепш для размеркавання нагрузкі разбіць іх. Гэта спасылачка да streaming_delay. Для хуткіх мець адну рэпліку з невялікай затрымкай рэплікацыі. Для працяглых запытаў справаздачных мець рэпліку, якая можа адставаць на 6 гадзін на суткі. Гэта цалкам нармальная сітуацыя.
Ухіляем наступствы ўсё тым жа спосабам:
- Знаходзім разадзьмутыя табліцы.
- І сціскаем найболей зручнай прыладай, які нам падыходзіць.
Гісторыя другая на гэтым завяршылася. Пераходзім да гісторыі трэцяй.
Таксама даволі звычайная для нас, у якой мы робім міграцыю.
- Любы праграмны прадукт расце. Змяняюцца да яго патрабаванні. Мы ў любым выпадку жадаем развівацца. І бывае так, што нам неабходна абнавіць дадзеныя ў табліцы, менавіта прагнаць апдэйт у плане нашай міграцыі пад новы функцыянал, які мы ўкараняем у рамках нашага развіцця.
- Стары фармат даных не задавальняе. Дапусцім, мы зараз звернемся да другой таблічкі, дзе ў мяне аперацыі па гэтых рахунках. І, дапусцім, што яны былі ў рублях, а мы вырашылі павысіць дакладнасць і рабіць у капейках. І для гэтага нам трэба зрабіць апдэйт: поле з сумай аперацыі памножыць на сто.
- У сучасным свеце мы выкарыстоўваем аўтаматызаваныя сродкі кантролю версій базы даных. Дапушчальны, . Прапісваем туды нашу міграцыю. Тэсціруем яе на нашай тэставай базе. Усё выдатна. Апдэйт праходзіць. Блакуе працу на некаторы час, але затое мы атрымліваем абноўленыя дадзеныя. І можам запускаць новы функцыянал на гэтым. Усё адтэставалі, праверылі. Усё пацвердзілі.
- Правялі планавыя працы, правялі міграцыю.
Вось міграцыя з апдэйтам прадстаўлена перад вамі. Так як гэта ў мяне аперацыі па рахунках, таблічка была ў 15 Гб. І так як мы абнаўляем кожны радок, мы апдэйтам раздзьмулі таблічку ў два разы, таму што мы перазапісалі кожны радок.
У час міграцыі мы нічога не маглі рабіць з гэтай таблічкай, таму што ўсе запыты да яе ўсталі ў чаргу і чакалі, пакуль скончыцца гэты апдэйт. Але тут я хачу звярнуць вашу ўвагу на лічбы, якія на вертыкальнай восі. Т. е. мы маем сярэдні час запыту да міграцыі ў раёне 5 мілісекунд і нагрузкі на працэсар, колькасць блокавых аперацый па чытанні памяці дыска менш, чым у 7,5.
Правялі міграцыю і атрымалі зноў праблемы.
Міграцыя прайшла паспяхова, але:
- Стары функцыянал пачаў выконвацца даўжэй.
- Табліца зноў вырасла ў памерах.
- Нагрузка на сервер зноў стала большай, чым была.
- І, натуральна, мы пакуль яшчэ важдаемся з тым функцыяналам, які працаваў добра, мы яго крыху палепшылі.
І гэта зноў bloat, які нам зноў псуе жыцьцё.
Тут я дэманструю, што табліца, як і папярэдніх двух выпадках, не збіраецца вяртацца да папярэдніх памераў. Сярэдняя нагрузка па серверы быццам бы адэкватная.
А калі мы звернемся да табліцы з рахункамі, то мы ўбачым, што сярэдні час запыту ў нас вырас у два разы да гэтай таблічкі. Нагрузка на працэсар і колькасць якія перабіраюцца радкоў у памяці скакнула вышэй 7,5, а было ніжэй. І скокнула ў выпадку працэсараў у 2 разы, у выпадку блокавых аперацый у 1,5 разы, т. е. мы атрымалі дэградацыю прадукцыйнасці сервера. І як следства - дэградацыю прадукцыйнасці нашага прыкладання. Пры гэтым колькасць выклікаў засталася прыкладна на тым жа ўзроўні.
І тут галоўнае разумець, як правільна рабіць такія міграцыі. А іх трэба рабіць. Мы даволі стала які робіцца гэтыя міграцыі.
- Такія вялікія міграцыі не робяць аўтаматычна. Яны заўжды павінны быць падкантрольныя.
- Неабходны кантроль з боку дасведчанага чалавека. Калі ў вас есць DBA ў камандзе, то няхай гэта робіць DBA. Гэта ягоная праца. Калі не, то найбольш дасведчаны чалавек няхай гэта робіць, які ведае, як працаваць з базамі дадзенымі.
- Новая схема базы дадзеных, нават у выпадку, калі мы абнаўляем адзін слупок, мы заўсёды падрыхтоўваем этапамі, т. е. загадзя да таго, як выкаціцца новая версія прыкладання:
- Дадаюцца новыя палі, у якія будзем запісваць як раз абноўленыя дадзеныя.
- Пераносім дадзеныя са старога поля ў новае поле невялікімі часткамі. Чаму мы гэта які робіцца? Па-першае, мы заўсёды кантралюем працэс гэтага працэсу. Мы ведаем, што мы перанеслі ўжо столькі батчоў і нам засталося столькі.
- А другі станоўчы эфект у тым, што паміж кожным такім батчам мы закрываем транзакцыю, адкрываем новую і гэта дае магчымасць аўтавакууму адпрацаваць па таблічцы, пазначыць мёртвыя радкі да перавыкарыстання.
- Для радкоў, якія будуць з'яўляцца ў працэсе працы прыкладання (у нас яшчэ працуе стары дадатак) дадаем трыгер, які запісвае новыя значэння ў новыя палі. У нашым выпадку - гэта множанне на сто старога значэння.
- Калі мы зусім упартыя і хочам тое ж самае поле, то па завяршэнні ўсіх міграцый і перад накатам новай версіі прыкладання, мы проста пераназываем поля. Старыя ў якую-небудзь прыдуманую назву, а новыя палі пераназываем у старыя.
- І толькі пасля гэтага запускаем новую версію прыкладання.
І пры гэтым мы не атрымаем bloat і не просядзем па прадукцыйнасці.
На гэтым трэцяя гісторыя скончылася.
І зараз крыху больш падрабязна пра інструменты, якія я згадваў у самай першай гісторыі.
Да таго, як шукаць bloat, трэба абавязкова паставіць пашырэнне .
Каб вам не прыдумляць запыты, мы ў сваёй працы ўжо напісалі гэтыя запыты. Вы можаце іх выкарыстоўваць. Тут прадстаўлены два запыты.
- Першы даволі доўга працуе, але затое ён вам пакажа дакладныя значэнні bloat па табліцы.
- Другі працуе барзджэй і вельмі эфектыўны, калі трэба хутка ацаніць – ёсць bloat ці не bloat па табліцы. І яшчэ вы павінны разумець, што bloat у табліцы Postgres ёсць заўсёды. Гэта асаблівасць яго мадэлі MVCC.
- І 20% bloat - гэта нармальна для табліц у большасці выпадкаў. Т. е. вам не варта перажываць і сціскаць гэтую табліцу.
Як выяўляць табліцы, якія ў нас распухлі, мы разабраліся, прычым, калі распухлі бескарыснымі дадзенымі.
Цяпер пра тое, як выпраўляць bloat:
- Калі ў нас невялікая таблічка і добрыя дыскі, т. е. на таблічцы да гігабайта суцэль магчыма выкарыстоўваць VACUUM FULL. Возьме ён у вас блакіроўку на табліцу эксклюзіўную на некалькі секунд і добра, затое хутка і цвёрда ўсё зробіць. Што робіць VACUUM FULL? Ён бярэ эксклюзіўнае блакаванне на табліцу і са старых табліц перапісвае жывыя радкі ў новую табліцу. І ў канцы падмяняе іх месцамі. Старыя файлы выдаляе, новыя падстаўляе замест старых. Але на час сваёй працы ён бярэ эксклюзіўнае блакаванне табліцы. Гэта азначае, што вы з гэтай табліцай нічога не зможаце зрабіць: ні пісаць у яе, ні чытаць у яе, ні мадыфікаваць яе. І VACUUM FULL патрабуе дадатковае месца на дыску, каб запісаць дадзеныя.
- Наступны інструмент . Па сваім прынцыпе ён вельмі падобны на VACUUM FULL, таму што ён таксама перапісвае дадзеныя са старых файлаў у новыя і падмяняе іх у табліцы. Але пры гэтым не бярэ эксклюзіўнае блакаванне на табліцу ў самага пачатку сваёй працы, а бярэ толькі ў момант, калі ў яго ўжо гатовыя дадзеныя для таго, каб падмяніць файлікі. Патрабаванні па дыскавых рэсурсах у яго аналагічныя як у VACUUM FULL. Вам трэба дадатковае месца на дыску, а гэта часам бывае крытычна, калі ў вас тэрабайтныя табліцы. І ён даволі пражэрлівы па працэсары, таму што вядзе актыўную працу з уводам-вывадам.
- Трэцяя ўтыліта - гэта . Яна больш беражліва ставіцца да рэсурсаў, таму што працуе крыху па іншых прынцыпах. Асноўная сутнасць у pgcompacttable у тым, што яна апдэйтамі ў табліцы пераносіць усе жывыя радкі ў пачатак табліцы. І потым запускае вакуум па гэтай табліцы, таму што мы ведаем, што ў нас у пачатку жывыя, а ў канцы мёртвыя радкі. І вакуум ужо сам адразае гэты хвосцік, т. е. дадатковай дыскавай прасторы ён не моцна патрабуе. І пры гэтым яго яшчэ можна па рэсурсах уціскаць.
З інструментамі ўсё.
Калі вам тэма з bloat здасца цікавай у плане пакапацца далей унутр, то вось вам некаторыя карысныя спасылкі:
- - Гэта даклад майго калегі. Ён агульны аб тым, куды дзяецца месца ў Postgres падчас яго працы і жыцці. І там вельмі вялікі і падрабязны кавалак тэхнічны для адміністратараў баз даных аб bloat.
- - гэта спасылка на наш рэпазітар, дзе мы захоўваем кучу карысных скрыптоў на праверку стану базы дадзеных. Там вы можаце знайсці скрыпты па пошуку bloat.
- и спасылкі на інструменты, якія вам дапамогуць уціскаць таблічкі.
- - Гэта пост майго калегі. Тамака ён даволі сур'ёзна і падрабязна тэхнічна разбірае bloat менавіта ўжо на ўзроўні блізкаму да адміністратараў.
Я тут больш пастараўся паказаць страшылку для дэвелапераў, таму што яны з'яўляюцца непасрэднымі нашымі кліентамі баз дадзеных і павінны разумець, да чаго і якія дзеянні вядуць. Спадзяюся, у мяне гэта атрымалася. Дзякуй за ўвагу!
пытанні
Дзякуй за даклад! Вы казалі аб тым, як можна выяўляць праблемы. А як іх можна папярэджваць? Т. е. у мяне была сітуацыя, калі запыты віселі не толькі з прычыны таго, што яны звярталіся да нейкіх знешніх сэрвісаў. Гэта былі проста нейкія дзікія joins. Былі нейкія малюсенькія запыты бяскрыўдныя, якія суткі віселі, а потым пачыналі тварыць нейкае глупства. Т. е. вельмі падобна на тое, што вы апісваеце. Як гэта адсочваць? Сядзець і ўвесь час глядзець, які запыт завіс? Як гэта можна папярэдзіць?
У дадзеным выпадку - гэта задача для адміністратараў вашай кампаніі, неабавязкова для DBA.
Я адміністратар.
У PostgreSQL ёсць такое ўяўленне, як pg_stat_activity, у якім паказаны віслыя запыты. І вы можаце ўбачыць, наколькі доўга ён там вісіць.
Я павінна кожныя 5 хвілін заходзіць і глядзець?
Наладзьце cron і правярайце. Калі ў вас узнік працяглы запыт, пішыце ліст і ўсё. Т. е. вам не трэба вачыма глядзець, гэта можна аўтаматызаваць. Вам прыйдзе ліст, вы на яго рэагуеце. А можаце аўтаматычна адстрэльваць.
Ёсць відавочныя прычыны, чаму гэта адбываецца?
Я некаторыя пералічыў. Іншыя больш складаныя прыклады. І там размова надоўга можа быць.
Дзякуй за даклад! Пра ўтыліту pg_repack хацеў удакладніць. Калі яна не робіць эксклюзіўную блакіроўку, то…
Яна робіць эксклюзіўную блакіроўку.
... то я патэнцыйна магу страціць дадзеныя. Маё дадатак нічога не павінна запісваць у гэты час?
Не, яно спакойна працуе з табліцай, т. е. pg_repack пераносіць спачатку ўсе жывыя радкі, якія ёсць. Натуральна, там нейкі запіс у табліцу адбываецца. Ён проста гэты хвосцік дакідвае.
Т. е. ён у канцы ўсё-ткі робіць?
У канцы ён бярэ эксклюзіўную блакіроўку на тое, каб падмяняць месцамі гэтыя файлы.
Гэта будзе хутчэй, чым VACUUM FULL?
VACUUM FULL, як стартануў, адразу ўзяў эксклюзіўную блакіроўку. І пакуль ён усё не зробіць, ён яе не адпусціць. А pg_repack бярэ эксклюзіўнае блакаванне толькі на момант замены файлаў. У гэты момант вы туды не запішыце, але даныя не згубяцца, усё будзе ў парадку.
Добры дзень! Вы расказвалі пра працу аўтавакуума. Там быў графік з чырвонымі, жоўтымі і зялёнымі ячэйкамі запісу. Т. е. жоўтыя - ён пазначыў як выдаленыя. І ў сьледзтва ў іх можна нешта запісаць новае?
Так. Postgres не выдаляе радкі. У яго такая спецыфіка. Калі мы абнавілі радок, мы старую пазначылі як выдалены. Там устае id транзакцыі, які змяніў гэты радок, і запісваем новы радок. І ў нас ёсць сесіі, якія патэнцыйна могуць іх чытаць. У нейкі момант яны ўжо зусім старымі робяцца. І сутнасць працы аўтавакуума ў тым, што ён прабягаецца па гэтых радках і пазначае іх як непатрэбныя. І туды можна перазапісаць дадзеныя.
Я зразумеў. Але пытанне крыху не пра гэта. Я не дагаварыў. Дапусцім, што ў нас ёсць табліца. У ёй ёсць палі пераменнага памеру. І калі я паспрабую нешта ўставіць новае, то гэта можа ў старое вочка проста не ўлезці.
Не, тамака ў любым выпадку ўвесь радок абнаўляецца. У Postgres ёсць дзве мадэлі захоўвання дадзеных. Ён выбірае ад тыпу даных. Ёсць дадзеныя, якія захоўваюцца непасрэдна ў табліцы, а ёсць яшчэ tos-дадзеныя. Гэта вялікі аб'ём дадзеных: тэкст, json. Яны захоўваюцца ў асобных таблічках. І па гэтых таблічках адбываецца тая ж гісторыя з bloat, т. е. усё тое ж самае. Проста асобна яны вынесены.
Дзякуй за даклад! Наколькі прымальна выкарыстоўваць для абмежавання працягласці запыты statement timeout?
Вельмі прымальна. Мы ўсюды гэта выкарыстоўваем. І т. к. у нас сваіх сэрвісаў няма, мы аказваем выдаленую падтрымку, то даволі разнастайныя кліенты ёсць. І ўсіх суцэль задавальняе гэта. Т. е. у нас ёсць заданні ў cron, якія правяраюць. Проста з кліентам агаворваецца працягласць сесій, раней якой мы не прыбіваем. Гэта можа быць хвіліна, гэта можа быць 10 хвілін. Гэта залежыць ад нагрузкі на базу і яе мэты. Але ва ўсіх мы выкарыстоўваем pg_stat_activity.
Дзякуй за даклад! Спрабую прымерыць ваш даклад да сваіх прыкладанняў. І быццам бы мы ўсюды стартуем транзакцыю, усюды відавочна яе завяршаем. Калі нейкі exception, тое ўсё роўна rollback адбываецца. І тут я задумаўся. Бо можа транзакцыя стартануць не яўна. Гэта падказка дзяўчыне, мусіць. Калі я проста раблю абнаўленне запісу, транзакцыя стартанет у PostgreSQL і завершыцца яна толькі тады, калі адбудзецца адключэнне злучэння?
Калі вы кажаце зараз аб узроўні прыкладання, то гэта залежыць ад таго драйвера, які вы карыстаецеся, ад таго ORM, які выкарыстоўваецца. Тамака вельмі шмат налад. Калі ў вас уключаны auto commit on, то там стартуе транзакцыя, тут жа зачыняецца.
Т. е. зачыняецца яна адразу пасля апдэйта?
Гэта залежыць ад настроек. Адну настройку я назваў. Гэта auto commit on. Яна даволі распаўсюджаная. Калі яна ўключана, то адкрылася-зачынілася транзакцыя. Калі вы відавочна не сказалі "start transaction" і "end transaction", а проста запусцілі ў сесію запыт.
Добры дзень! Дзякуй за даклад! Уявім, што ў нас ёсць база, якая пухне-пухне і тут на серверы канчаецца месца. Ёсць нейкія інструменты, каб выправіць гэтую сітуацыю?
Месца на серверы па-добраму трэба маніторыць.
Напрыклад, DBA пайшоў піць гарбату, быў на курорце і т. д.
Калі ствараецца файлавая сістэма, то тамака прынамсі нейкае рэзервовае месца ствараецца, куды не пішуцца дадзеныя.
А калі зусім пад нуль?
Там так і называецца reserved space, г. зн. яго можна вызваліць і ў залежнасці ад таго, наколькі вялікім яго стварылі, вы атрымалі свабоднае месца. Па змаўчанні я не ведаю, колькі тамака. А ў іншым выпадку - дастаўляць дыскі, каб у вас было месца правесці аперацыю аднаўленчую. Можна выдаліць нейкую табліцу, якая вам гарантавана не патрэбна.
Іншых інструментаў няма?
Гэта заўсёды ручная праца. І па месцы выяўляецца, што там лепш зрабіць, бо ёсць дадзеныя крытычныя, ёсць некрытычныя. І для кожнай базы і прыкладанні, якое з ёй працуе, гэта залежыць ад бізнэсу. Заўсёды па месцы вырашаецца.
Дзякуй за даклад! У мяне два пытанні. Па-першае, вы дэманстравалі слайды, дзе паказвалася, што ў выпадку якія завіслі транзакцый расце як і аб'ём таблічнай прасторы, так і памер азначніка. І далей па дакладзе была куча ўтыліт, якія пакуюць таблічку. А што з азначнікам?
Яны таксама пакуюць іх.
Але вакуум не закранае азначнік?
Некаторыя працуюць з азначнікам. Напрыклад, pg_rapack, pgcompacttable. Вакуум перастварае індэксы, закранае іх. У VACUUM FULL сутнасць у тым, каб усё перазапісаць, т. е. ён са ўсімі працуе.
І другое пытанне. Я не зразумеў, чаму справаздачы на рэпліках так моцна залежаць ад рэплікацыі. Мне здавалася, што справаздачы - гэта чытанне, а рэплікацыя - гэта запіс.
У чым узнікае канфлікт рэплікацыі? У нас ёсць Майстар, на якім адбываюцца працэсы. У нас адбываецца аўтавакуум. Аўтавакуум па факце, што робіць? Ён выпілоўвае нейкія старыя радкі. Калі ў нас у гэты час на рэпліцы ідзе запыт, які чытае гэтыя старыя радкі, а на Майстры адбылася сітуацыя, што аўтавакуум пазначыў гэтыя радкі як магчымыя для перазапісу, то мы іх перазапісалі. І ў нас прыйшоў пакет дадзеных, калі мы павінныя перазапісаць тыя радкі, якія патрэбныя запыту на рэпліцы, то працэс рэплікацыі пачакае той тайм аўт, які вы наладзілі. І потым PostgreSQL будзе вырашаць, што важней для яго. А рэплікацыя для яго важнейшая, чым запыт і ён адстрэліць запыт, каб выканаць гэтыя змены на рэпліцы.
Андрэй, ёсць пытанне. Вось гэтыя цудоўныя графікі, якія вы паказвалі падчас прэзентацыі, гэта вынік работ, нейкай вашай утыліты? Чым будавалі графікі?
Гэта сэрвіс .
Гэта камерцыйны прадукт?
Так. Гэта камерцыйны прадукт.
Крыніца: habr.com