Типични грешки в приложението, които водят до раздуване на postgresql. Андрей Салников

Предлагам да прочетете стенограмата на доклада от началото на 2016 г. от Андрей Салников „Типични грешки в приложенията, които водят до раздуване в postgresql“

В този доклад ще анализирам основните грешки в приложенията, които възникват на етапа на проектиране и писане на код на приложението. И ще взема само онези грешки, които водят до раздуване в Postgresql. По правило това е началото на края на производителността на вашата система като цяло, въпреки че първоначално не се виждаха предпоставки за това.

Радвам се да приветствам всички! Този доклад не е толкова технически, колкото предишния от моя колега. Този разговор е насочен към разработчиците на бек-енд системи главно защото имаме доста голям брой клиенти. И всички правят едни и същи грешки. Ще ви разкажа за тях. Ще обясня до какво фатално и лошо водят тези грешки.

Защо се допускат грешки? Те се изпълняват по две причини: на случаен принцип, може би ще работи поради непознаване на някои механизми, които се случват на ниво между базата и приложението, както и в самата база.

Ще ви дам три примера с ужасни картини как нещата се влошиха. Ще опиша накратко механизма, който се случва там. И как да се справите с тях, кога са се случили и какви превантивни методи да използвате, за да предотвратите грешки. Ще ви разкажа за помощни инструменти и ще дам полезни връзки.

Използвах тестова база данни, където имах две таблици. Едната табелка със сметки на клиенти, другата с операции по тези сметки. И с известна периодичност актуализираме салдата по тези сметки.

Първоначалните данни на табелата: тя е доста малка, 2 MB. Времето за реакция на базата данни и конкретно на табелата също е много добро. И доста добро натоварване - 2 операции в секунда на плочата.

И чрез този доклад ще ви покажа графики, за да е ясно какво се случва. Винаги ще има 2 слайда с графики. Първият слайд е какво се случва като цяло на сървъра.

И в тази ситуация виждаме, че наистина имаме малка чиния. Индексът е малък - 2 MB. Това е първата графика вляво.

Средното време за отговор в сървъра също е стабилно, малко. Това е горната дясна графика.

Долната лява графика е с най-дългите транзакции. Виждаме, че транзакциите се извършват бързо. И тук автовакуумът още не работи, защото - беше старт-тест. Тогава ще работи и ще ни бъде полезно.

Вторият слайд винаги ще бъде посветен на тестовата плоча. В тази ситуация ние постоянно актуализираме наличностите по сметката на клиента. И виждаме, че средното време за отговор за операцията по актуализиране е доста добро, по-малко от милисекунда. Виждаме, че ресурсите на процесора (това е горната дясна графика) също се консумират равномерно и доста малко.

Долната дясна графика показва колко оперативна и дискова памет преминаваме в търсене на желаната от нас линия, преди да я актуализираме. И броят на операциите върху плочата е 2 в секунда, както казах в началото.

И сега имаме трагедия. По някаква причина се случва отдавна забравена транзакция. Причините обикновено са банални:

• Един от най-често срещаните е, че започнахме да осъществяваме достъп до външна услуга в кода на приложението. И тази служба не ни отговаря. Тоест отворихме транзакция, направихме промяна в базата данни и преминахме от приложението за четене на поща или към друга услуга в нашата инфраструктура и по някаква причина тя не ни отговаря. И сесията ни висна в състояние - не се знае кога ще се разреши.
• Втората ситуация е, когато по някаква причина възникне изключение в нашия код. И ние не обработихме затварянето на транзакцията в изключението. И получихме висяща сесия с отворена транзакция.
• И последното също е доста често срещано. Това е код с лошо качество. Някои рамки отварят транзакция. Той виси и може да не знаете в приложението, че го имате.

Докъде водят такива неща?

До факта, че нашите таблици и индекси започват да набъбват драстично. Това е точно същия ефект на подуване. За базата данни това ще се изрази в това, че ще имаме много рязко увеличение на времето за реакция на базата данни, ще се увеличи натоварването на сървъра на базата данни. И в резултат нашето приложение ще пострада. Защото, ако във вашия код сте изразходвали 10 милисекунди за заявка към базата данни, 10 милисекунди за вашата логика, тогава вашата функция е работила 20 милисекунди. И сега положението ви ще бъде много тъжно.

И да видим какво ще стане. Долната лява графика показва, че имаме дълга дълга транзакция. И ако погледнем горната лява графика, виждаме, че размерът на таблицата е скочил от два мегабайта на 300 мегабайта. В същото време количеството данни в таблицата не се е променило, тоест има доста голямо количество боклук.

Общата ситуация по отношение на средното време за отговор на сървъра също се е променила с няколко порядъка. Тоест, всички заявки на сървъра започнаха напълно да пропадат. И в същото време бяха пуснати вътрешните процеси на Postgres в лицето на autovacuum, които се опитват да направят нещо и да консумират ресурси.

Какво се случва с чинията ни? Същото. Средното време за реакция на таблета скочи с няколко порядъка. Ако конкретно по отношение на консумираните ресурси, тогава виждаме, че натоварването на процесора се е увеличило значително. Това е горната дясна графика. И се е увеличил, защото процесорът трябва да премине през куп безполезни редове в търсене на този, от който се нуждаете. Това е долната дясна графика. И в резултат на това броят на обажданията в секунда започна да намалява много, защото базата данни няма време да обработи същия брой заявки.

Трябва да се върнем към живота. Качваме се в интернет и откриваме, че дългите транзакции водят до проблем. Ние намираме и убиваме тази транзакция. И всичко ни върви добре. Всичко работи както трябва.

Успокоихме се, но след известно време започваме да забелязваме, че приложението не работи както преди спешния случай. Заявките се обработват все по-бавно и много по-бавно. Един и половина до два пъти по-бавно конкретно в моя пример. Натоварването на сървъра също е по-високо, отколкото беше преди инцидента.

И въпросът: "Какво се случва с базата в този момент?". А с основата има следната ситуация. На графиката на транзакциите можете да видите, че тя е спряла и наистина няма дългосрочни транзакции. Но размерите на плочата по време на инцидента нараснаха фатално. И оттогава не е намаляла. Средното време на базата се стабилизира. И отговорите изглежда вървят адекватно с приемлива за нас скорост. Autovacuum се активизира и започна да прави нещо с таблета, защото трябва да рине повече данни.

По-конкретно, на тестовото табло, където променяме балансите: времето за отговор на заявката изглежда се е върнало към нормалното. Но всъщност е един и половина пъти по-висок.

И по натоварването на процесора виждаме, че натоварването на процесора не се е върнало до желаната стойност преди срива. И причините за това се крият точно в долната дясна графика. Вижда се, че има търсене на някакво количество памет. Тоест, за да търсим желания ред, ние изразходваме ресурсите на сървъра на базата данни, когато сортираме безполезни данни. Броят на транзакциите в секунда се стабилизира.

Като цяло добре, но положението е по-лошо, отколкото беше. Изрично влошаване на базата данни като следствие от нашето приложение, което работи с тази база данни.

И за да разберете какво се случва там, ако не сте били на предишния доклад, сега малко теория. Теория за вътрешния процес. Защо автовакуум и какво прави?

Буквално накратко за разбиране. В даден момент имаме маса. Имаме редове в таблицата. Тези линии могат да бъдат активни, живи, имаме нужда сега. На снимката са маркирани в зелено. И има мъртви линии, които вече са работили, актуализирани са, на тях са се появили нови записи. И те са маркирани, че вече не са интересни за базата данни. Но те лежат в таблицата поради особеностите на Postgres.

Защо ви е необходим автовакуум? Autovacuum идва в някакъв момент, извиква базата данни и я пита: "Моля, дайте ми идентификатора на най-старата транзакция, която в момента е отворена в базата данни." Базата данни връща този идентификатор. И автовакуумът, разчитайки на него, минава през редовете в таблицата. И ако види, че някои редове са променени от много по-стари транзакции, тогава той има право да ги маркира като редове, които можем да използваме повторно в бъдеще, като записваме нови данни там. Това е фонов процес.

По това време продължаваме да работим с базата данни, продължаваме да правим някои промени в таблицата. И на тези редове, които можем да използваме повторно, записваме нови данни. И по този начин получаваме цикъл, тоест там постоянно се появяват някакви мъртви стари редове, вместо тях записваме нови редове, от които се нуждаем. И това е нормалното състояние, за да работи PostgreSQL.

Какво се случи по време на инцидента? Как се осъществи този процес?

Имахме табела в някакво състояние, някои живи, някои мъртви линии. Автовакуумът пристигна. Той попита базата данни коя е най-старата ни транзакция, какъв е нейният идентификатор. Получих този идентификатор, който може да е на много часове, може би на десет минути. Зависи колко голямо е натоварването на базата данни. И той отиде да търси редове, които може да маркира като повторно използвани. И не намерих такива редове в нашата таблица.

Но по това време продължаваме да работим с масата. Правим нещо в него, актуализираме го, променяме данните. Какво трябва да прави базата данни в този момент? Тя няма друг избор, освен да добави нови редове в края на съществуващата таблица. И по този начин при нас размерът на масата започва да се раздува.

Наистина се нуждаем от зелени линии, за да работим. Но по време на такъв проблем се оказва, че процентът на зелените линии е изключително нисък в целия обем на таблицата.

И когато изпълним заявка, базата данни трябва да премине през всички редове, червени и зелени, за да намери правилния ред. А ефектът от надуване на таблицата с безполезни данни се нарича "подуване", което също изяжда дисковото ни пространство. Помните ли, че беше 2 MB, сега е 300 MB? Сега сменете мегабайтите на гигабайти и ще загубите всичките си дискови ресурси доста бързо.

Какви са последиците за нас?

• В моя пример таблицата и индексът са нараснали 150 пъти. Някои от нашите клиенти са имали повече фатални случаи, когато дисковото пространство просто започва да свършва.
• Масите никога няма да се свият сами. Автовакуумът в някои случаи може да отреже опашката на масата, ако има само мъртви линии. Но тъй като има постоянно въртене, една зелена линия може да виси в края и да не се актуализира, а всички останали някъде в началото на табелата ще бъдат записани. Но това е толкова малко вероятно събитие, че самата ви маса ще намалее по размер, така че не трябва да се надявате на това.
• Базата данни трябва да сортира цялата купчина безполезни редове. А ние хабим дискови ресурси, хабим процесорни ресурси и електроенергия.
• И това пряко засяга нашето приложение, защото ако в началото сме изразходвали 10 милисекунди за заявка, 10 милисекунди за нашия код, тогава по време на срива започнахме да изразходваме секунда за заявка и 10 милисекунди за код, т.е. производителността на приложенията намаля. И когато аварията беше разрешена, започнахме да изразходваме 20 милисекунди на заявка, 10 милисекунди на код. Това означава, че все още сме потънали един път и половина по отношение на представянето. И всичко това е заради една транзакция, която висеше и може би по наша вина.
• И въпросът: „Как мога да върна всичко?“ Така че всичко да е наред с нас и заявките да вървят толкова бързо, колкото преди аварията.

За това има определен цикъл от работа, който се извършва.

Първо трябва да намерим проблемните маси, които са се раздули. Разбираме, че някои таблици записват по-активно, други по-малко активно. И за това използваме разширението pgstattuple. Като инсталирате това разширение, можете да пишете заявки, които да ви помогнат да намерите таблици, които са достатъчно раздути.

След като намерите тези таблици, те трябва да бъдат компресирани. Вече има инструменти за това. В нашата компания използваме три инструмента. Първият е вграденият VACUUM FULL. Той е жесток, суров и безмилостен, но понякога е много полезен. pg_repack и pgcompacttable са помощни програми на трети страни за компресиране на таблици. И те са по-внимателни към базата данни.

Използват се в зависимост от това, което ви е по-удобно. Но за това ще говоря в самия край. Основното е, че има три инструмента. Има много за избор.

След като коригираме всичко, като се уверим, че всичко е наред, трябва да знаем как да предотвратим тази ситуация в бъдеще:

• Сравнително лесно е да се предотврати. Трябва да следите продължителността на сесиите на главния сървър. Особено опасни сесии в състояние на неактивност в транзакция. Това са тези, които току-що са отворили транзакция, направили са нещо и са си тръгнали, или просто са увиснали, изгубили са се в кода.
• А за вас, като разработчици, е важно да тествате кода в момента, в който възникнат тези ситуации. Не е трудно да се направи. Това ще бъде полезна проверка. Ще избегнете много "детски" проблеми, свързани с дълги транзакции.

На тези графики исках да ви покажа как таблицата и поведението на базата данни се промениха, след като в този случай предадох VACUUM FULL на таблицата. Това не е моя продукция.

Размерът на таблицата веднага се върна към нормалното си работно състояние от няколко мегабайта. Това не повлия значително на средното време за реакция в сървъра.

Но конкретно в нашата тестова таблица, където актуализирахме балансите по сметки, виждаме, че средното време за отговор на искане за актуализиране на данните в таблета е намалено до нивото преди инцидента. Ресурсите, консумирани от процесора за изпълнение на тази заявка, също паднаха до нивата преди срива. А долната дясна графика показва, че сега намираме точно реда, от който се нуждаем веднага, без да преминаваме през купчината мъртви редове, които са били преди таблицата да бъде компресирана. И средното време за заявка остана приблизително на същото ниво. Но тук имам по-скоро грешката на моя хардуер.

Тук свършва първата история. Тя е най-често срещаната. И това се случва на всеки, независимо от опита на клиента, колко квалифицирани програмисти има. Рано или късно се случва.

Втората история, в която разпределяме натоварването и оптимизираме сървърните ресурси

• Пораснахме и станахме сериозни момчета. И ние разбираме, че имаме реплика и би било добре за нас да балансираме товара: пишете на Учителя и четете от репликата. И обикновено тази ситуация възниква, когато искаме да подготвим някакви отчети или ETL. И бизнесът е много доволен от това. Той наистина иска разнообразни отчети с куп сложни анализи.
• Отчетите продължават много часове, тъй като сложните анализи не могат да бъдат изчислени за милисекунди. Ние, като смели момчета, пишем код. Ние правим в приложението за вмъкване, което записваме на Master, извършваме отчети на репликата.
• Ние разпределяме товара.
• Всичко работи перфектно. страхотни сме

И как изглежда тази ситуация? По-конкретно, на тези диаграми добавих и продължителността на транзакциите от репликата за продължителността на транзакцията. Всички други графики се отнасят само за главния сървър.

По това време моята отчетна дъска беше нараснала. Има повече от тях. Виждаме, че средното време за отговор на сървъра е стабилно. Виждаме, че имаме дълготрайна транзакция на репликата, която работи 2 часа. Виждаме тихата работа на автовакуума, който обработва мъртвите линии. И всички сме добре.

По-конкретно, според тестовия таблет, ние продължаваме да актуализираме салдата по сметките там. Освен това имаме стабилно време за реакция при заявка, стабилно потребление на ресурси. При нас всичко е наред.

Всичко е наред до момента, в който тези доклади започват да ни отвръщат на конфликт с репликация. И те отвръщат на редовни интервали.

Влизаме онлайн и започваме да четем защо това се случва. И намираме решение.

Първото решение е да се увеличи латентността на репликацията. Знаем, че докладът ни продължава 3 часа. Задайте забавянето на репликацията на 3 часа. Започваме всичко, но продължаваме да имаме проблеми с факта, че докладите понякога се отхвърлят.

Искаме всичко да е перфектно. Да отидем по-нататък. И ние намираме готина настройка в интернет - hot_standby_feedback. Включваме го. Hot_standby_feedback ни позволява да поддържаме автовакуума работещ на Master. Така напълно се отърваваме от конфликтите при репликация. И всички работим добре с отчетите.

И какво се случва с главния сървър в момента? А с главния сървър имаме пълна катастрофа. Сега виждаме диаграми с включени и двете настройки. И виждаме, че сесията на репликата по някакъв начин започна да влияе на ситуацията на главния сървър. Това наистина оказва влияние, защото е спряло автовакуума, който почиства мъртвите линии. Размерът на нашата маса отново скочи до небето. Средното време за изпълнение на заявката в цялата база данни също скочи рязко. Автовакуумите се стегнаха малко.

По-конкретно, на нашата табела виждаме, че актуализацията на данните върху нея също скочи в небето. Потреблението на процесорни ресурси също се е увеличило значително. Ние отново итерираме върху голям брой мъртви безполезни редове. И времето за реакция на този таблет, броят на транзакциите е намалял.

Как ще изглежда, ако не знаем за какво говорих преди?

• Започваме да търсим проблеми. Ако сме срещнали проблеми в първата част, знаем, че това може да е причината за дълга транзакция и се качваме на Master. Проблемът е в Майстора. Кренвирши го. Той загрява, има средно натоварване под сто.
• Заявките се забавят там, но не виждаме никакви дългосрочни транзакции там. И не разбираме какво става. Не знаем къде да търсим.
• Проверка на сървърния хардуер. Може би рейдът ни се е провалил. Може би сме изгорили лентата с памет. Да, всичко може да бъде. Но не, сървърите са нови, всичко работи добре.
• Всички работят: администратори, разработчици и директор. Нищо не помага.
• И в един момент всичко изведнъж започва да се коригира.

На репликата по това време заявката се получи и замина. Получихме доклад. Бизнесът все още е щастлив. Както можете да видите, нашата маса отново нарасна и няма да намалява. На графиката със сесии оставих част от тази дълга транзакция от репликата, за да можете да прецените колко време отнема, докато ситуацията се стабилизира.

Сесията я няма. И само след известно време сървърът идва повече или по-малко в ред. И средното време за реакция за заявки на главния сървър се връща към нормалното. Защото най-накрая автопрахосмукачката получи възможността да изчисти, да маркира тези мъртви линии. И започна да си върши работата. И колко бързо го прави, толкова бързо ще се оправим.

На тестовата таблица, където актуализираме балансите по сметката, виждаме абсолютно същата картина. Средното време за актуализиране на акаунта също се нормализира постепенно. Ресурсите, консумирани от процесора, също са намалени. И броят на транзакциите в секунда се върна към нормалното. Но отново, обратно към нормалното, не същото, което имахме преди инцидента.

Във всеки случай получаваме спад в производителността, както в първия случай, един и половина до два пъти, а понякога дори повече.

Изглежда сме направили всичко както трябва. Разпределете товара. Оборудването не е бездействащо. Според ума те нарушиха заявките, но въпреки това всичко се оказа зле.

• Не активирайте hot_standby_feedback? Да, не се препоръчва да го включвате без особено сериозни причини. Защото този обрат засяга директно главния сървър и спира работата на автовакуума там. Като го включите на някоя реплика и забравите за него, можете да убиете Учителя и да получите големи проблеми с приложението.
• Увеличаване на max_standby_streaming_delay? Да, за докладите е така. Ако имате тричасов отчет и не искате той да се срине поради конфликти при репликация, тогава просто увеличете забавянето. Дългият отчет никога не изисква данни, които са влезли в базата данни точно сега. Ако го имате за три часа, значи го използвате за някакъв стар период от данни. И вие, че три часа закъснение, че шест часа закъснение - няма да играе никаква роля, но ще получавате доклади постоянно и да не знаете проблемите с падането им.
• Естествено, трябва да контролирате дългите сесии на реплики, особено ако решите да активирате hot_standby_feedback на реплика. Защото може да е всичко. Дадохме тази забележка на разработчика, за да тества заявките. Написа безумна молба. Той започна и отиде да пие чай и получихме установения Учител. Или сме стартирали грешното приложение там. Ситуациите са най-различни. Сесиите на реплики трябва да се контролират толкова внимателно, колкото и на Master.
• И ако имате бързи и дълги заявки за реплики, тогава в този случай е по-добре да ги разделите, за да разпределите натоварването. Това е връзка към streaming_delay. За бързо да имате една реплика с малко забавяне на репликацията. За дългосрочни заявки за отчитане имайте реплика, която може да изостава с 6 часа, с ден. Това е напълно нормална ситуация.

Отстраняваме последствията по същия начин:

• Намираме раздути маси.
• И компресираме с най-удобния инструмент, който ни подхожда.

Втората история свършва тук. Да преминем към третата история.

Също така често срещано за нас, в което извършваме миграцията.

• Всеки софтуерен продукт расте. Изискванията се променят. Във всеки случай искаме да се развиваме. И се случва, че трябва да актуализираме данните в таблицата, а именно да стартираме актуализацията по отношение на нашата миграция към новата функционалност, която внедряваме като част от нашата разработка.
• Старият формат на данните не е подходящ. Да кажем, че сега се обръщаме към втората таблица, където имам операции по тези сметки. И да кажем, че бяха в рубли и решихме да увеличим точността и да го направим в копейки. И за това трябва да направим актуализация: умножете полето със сумата на операцията по сто.
• В днешния свят ние използваме автоматизирани инструменти за създаване на версии на бази данни. Да речем Liquibase. Ние регистрираме нашата миграция там. Тестваме го на нашата тестова база. Всичко е наред. Актуализацията се изпълнява. Блоковете работят известно време, но получаваме актуализирани данни. И можем да стартираме нова функционалност за това. Всичко тествано и проверено. Всички потвърдени.
• Извършена планирана работа, извършена миграция.

Ето миграцията с актуализацията, представена пред вас. Тъй като имам операции по сметки, табелата беше 15 GB. И тъй като актуализираме всеки ред, ние удвоихме размера на таблицата, защото сме презаписали всеки ред.

По време на миграцията не можахме да направим нищо с този етикет, защото всички заявки за него бяха поставени на опашка и чакаха тази актуализация да завърши. Но тук искам да насоча вниманието ви към числата, които са на вертикалната ос. Тоест имаме средно време за заявка преди миграция в района на 5 милисекунди и натоварване на процесора, броят на блоковите операции за четене на дисковата памет е по-малък от 7,5.

Мигрирахме и отново получихме проблеми.

Миграцията беше успешна, но:

• Старата функционалност започна да работи по-дълго.
• Масата отново е пораснала.
• Натоварването на сървъра отново стана повече, отколкото беше.
• И, разбира се, все още се занимаваме с функционалността, която работи добре, подобрихме я малко.

И това отново е подуване, което отново разваля живота ни.

Тук демонстрирам, че таблицата, подобно на предишните два случая, няма да се върне към предишните размери. Средното натоварване на сървъра изглежда адекватно.

И ако се обърнем към таблицата със сметки, тогава ще видим, че средното време за заявка се е удвоило за тази таблица. Натоварването на процесора и броят редове за сортиране в паметта скочиха над 7,5, но бяха по-ниски. И скочи при процесорите 2 пъти, при блоковите операции 1,5 пъти, т.е. получихме влошаване на производителността на сървъра. И като резултат - влошаване на производителността на нашето приложение. В същото време броят на повикванията остава приблизително на същото ниво.

И тук основното е да разберете как да правите правилно такива миграции. И те трябва да бъдат направени. Правим тези миграции доста редовно.

• Такива големи миграции не се извършват автоматично. Те винаги трябва да бъдат контролирани.
• Има нужда от надзор от опитен човек. Ако имате DBA в екипа, оставете DBA да го направи. Негова работа. Ако не, нека го направи най-опитният човек, който знае как да работи с бази данни.
• Новата схема на базата данни, дори ако актуализираме една колона, ние винаги подготвяме на етапи, т.е. предварително, преди да се появи новата версия на приложението:
• Добавени са нови полета, в които ще записваме само актуализираните данни.
• Прехвърляме данни от старото поле в новото поле на малки части. Защо правим това? Първо, ние винаги контролираме процеса на този процес. Знаем, че вече сме прехвърлили толкова много партиди и ни остават толкова много.
• И вторият положителен ефект е, че между всяка такава партида затваряме транзакция, отваряме нова и това дава възможност автовакуумът да работи според табелата, да маркира срокове за повторно използване.
• За редовете, които ще се появят по време на работа на приложението (все още имаме старото приложение), добавяме тригер, който записва нови стойности в нови полета. В нашия случай това е умножение по сто от старата стойност.
• Ако сме напълно упорити и искаме същото поле, тогава след приключване на всички миграции и преди пускане на новата версия на приложението, просто преименуваме полетата. Старите в някакво измислено име, а новите полета преименуваме на старите.
• И едва след това стартираме нова версия на приложението.

И в същото време няма да се подуем и няма да отслабнем в представянето.

Това е краят на третата история.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

А сега малко повече за инструментите, които споменах в първата история.

Преди да търсите раздуване, трябва да инсталирате разширението pgstattuple.

За да не измисляте заявки, ние вече сме написали тези заявки в нашата работа. Можете да ги използвате. Тук има две искания.

• Първият отнема доста време, но ще ви покаже точните стойности на подуване според таблицата.
• Вторият работи по-бързо и е много ефективен, когато трябва бързо да прецените дали има надуване или не в таблицата. Освен това трябва да разберете, че винаги има раздуване в таблица на Postgres. Това е характеристика на неговия модел MVCC.
• И 20% раздуване е добре за масите в повечето случаи. Тоест не трябва да се притеснявате и да компресирате тази таблица.

Разбрахме как да идентифицираме таблици, които са набъбнали с нас, освен това, когато са набъбнали с безполезни данни.

Сега за това как да коригирате подуването:

• Ако имаме малка плоча и добри дискове, т.е. на плоча до гигабайт, е напълно възможно да използваме VACUUM FULL. Той ще вземе изключителна ключалка от вас за няколко секунди и добре, но ще направи всичко бързо и грубо. Какво прави VACUUM FULL? Взема изключително заключване на масата и пренаписва живите редове от старите таблици в новата таблица. И накрая ги заменя. Изтрива стари файлове, заменя стари с нови. Но по време на работата си, той изисква изключително заключване на масата. Това означава, че не можете да правите нищо с тази таблица: нито да пишете в нея, нито да я четете, нито да я променяте. И VACUUM FULL изисква допълнително дисково пространство за запис на данни.
• Следващ инструмент pg_repack. По своя принцип той е много подобен на VACUUM FULL, защото също презаписва данни от стари файлове в нови и ги замества в таблицата. Но в същото време той не взема ексклузивно заключване на масата в самото начало на работата си, а го взема само в момента, когато има готови данни, за да замени файловете. Има същите изисквания за дискови ресурси като VACUUM FULL. Имате нужда от допълнително дисково пространство и това понякога е критично, ако имате терабайтови таблици. И той е доста ненаситен към процесора, защото активно работи с I / O.
• Третата полезност е pgcompacttable. Той е по-внимателен към ресурсите, защото работи на малко по-различни принципи. Основната същност на pgcompacttable е, че премества всички живи редове в началото на таблицата с актуализации в таблицата. И тогава започва вакуумът на тази таблица, защото знаем, че имаме живи редове в началото и мъртви редове в края. И самият вакуум отрязва тази опашка, тоест не изисква много допълнително дисково пространство. И в същото време все още може да бъде притиснат от ресурси.

Всичко с инструменти.

Ако намирате темата за подуването за интересна от гледна точка на по-нататъшно копаене навътре, тогава ето някои полезни връзки за вас:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres е докладът на колегата. Общо е къде отива мястото на Postgres в хода на работата и живота му. И има много голяма и подробна техническа част за администраторите на бази данни относно раздуването.
• https://github.com/dataegret/pg-utils е връзка към нашето хранилище, където съхраняваме куп полезни скриптове за проверка на състоянието на базата данни. Там можете да намерите скриптове за търсене на надуване.
• Третият и четвъртата връзки към инструменти, които ще ви помогнат да компресирате плочите.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html Това е пост от мой колега. Там той доста сериозно и технически анализира подробно раздуването вече на ниво, близко до администраторите.

Тук се опитах да покажа една ужасна история за разработчиците, защото те са наши директни клиенти на бази данни и трябва да разберат какво и до какви действия водят. Надявам се да съм успял. Благодаря за вниманието!

Въпроси

Благодаря за доклада! Говорихте за това как могат да се идентифицират проблемите. Как могат да бъдат предупредени? Тоест, имах ситуация, в която заявките висяха не само защото се обърнаха към някои външни услуги. Това бяха просто някакви диви присъединявания. Имаше едни малки, безобидни заявки, които се мотаеха един ден и след това започнаха да правят някакви глупости. Тоест, много прилича на това, което описвате. Как да го проследя? Седи и постоянно гледа, коя заявка е заседнала? Как може да се предотврати това?

В този случай това е задача за администраторите на вашата компания, а не непременно за DBA.

Аз съм администратор.

PostgreSQL има изглед, наречен pg_stat_activity, който показва чакащи заявки. И можете да видите колко дълго виси там.

Трябва да влизам на всеки 5 минути и да гледам?

Настройте cron и проверете. Ако имате дълга заявка, напишете писмо и това е. Тоест не е нужно да гледате с очите си, това може да стане автоматизирано. Ще получите писмо, ще му отговорите. Или можете да снимате автоматично.

Има ли ясни причини това да се случва?

Изброих някои. Други по-сложни примери. И може да има дълъг разговор.

Благодаря за доклада! Исках да изясня относно помощната програма pg_repack. Ако не изисква изключително заключване, тогава...

Тя прави изключителна ключалка.

... тогава бих могъл потенциално да загубя данни. Приложението ми не трябва ли да записва нищо в този момент?

Не, работи тихо с таблицата, т.е. pg_repack първо прехвърля всички живи линии, които са там. Естествено, има някакъв рекорд в таблицата. Той просто хвърля тази конска опашка.

Тоест накрая все пак ли го прави?

В крайна сметка е необходимо изключително заключване при размяната на тези файлове.

Ще бъде ли по-бързо от VACUUM FULL?

VACUUM FULL, както започна, веднага взе изключителна ключалка. И докато не направи всичко, няма да я пусне. И pg_repack взема изключително заключване само по време на подмяна на файлове. В този момент не пишете там, но данните няма да бъдат загубени, всичко ще бъде наред.

Здравейте! Говорихте за работата на автовакуума. Имаше графика с червени, жълти и зелени клетки на записа. Тоест жълти - маркира ги като изтрити. И в резултат на това можете да напишете нещо ново в тях?

да Postgres не премахва редове. Той има такава специфика. Ако актуализирахме реда, маркирахме стария като изтрит. Идентификационният номер на транзакцията, който промени този ред, се появява там и ние пишем нов ред. И имаме сесии, които потенциално могат да ги прочетат. В един момент те доста стареят. И същността на автовакуума е, че той минава през тези линии и ги маркира като ненужни. И там можете да презапишете данните.

Разбирам. Но въпросът не е в това. Не се съгласих. Да кажем, че имаме маса. Има полета с променлив размер. И ако се опитам да вмъкна нещо ново, то може просто да не се побере в старата клетка.

Не, във всеки случай цялата линия се актуализира. Postgres има два модела за съхранение. Той избира от типа данни. Има данни, които се съхраняват директно в таблицата, а има и tos данни. Това са големи количества данни: текст, json. Те се съхраняват в отделни таблетки. И според тези таблетки се случва същата история с подуването, тоест всичко е същото. Те просто са посочени отделно.

Благодаря за доклада! Доколко приемливо е да се използват заявки за изчакване на израз за ограничаване на продължителността?

Много приемливо. Използваме го навсякъде. И тъй като нямаме собствени услуги, предоставяме дистанционна поддръжка, има доста различни клиенти. И всички са доста доволни от това. Тоест имаме задачи в cron, които проверяват. Просто продължителността на сесиите се договаря с клиента, пред което не се заковаваме. Може да е минута, може да е 10 минути. Зависи от натоварването на основата и нейното предназначение. Но ние всички използваме pg_stat_activity.

Благодаря за доклада! Опитвам се да изпробвам вашия отчет за моите приложения. И изглежда, че започваме транзакция навсякъде и изрично я завършваме навсякъде. Ако има изключение, тогава се случва едно и също връщане назад. И тогава се замислих. В крайна сметка транзакцията може да започне не изрично. Това е намек към момичето, предполагам. Ако просто направя актуализация на запис, транзакцията ще започне ли в PostgreSQL и ще завърши ли само когато връзката бъде прекъсната?

Ако сега говорите за ниво на приложение, то зависи от драйвера, който използвате, от ORM, който се използва. Там има много настройки. Ако имате активиран автоматичен ангажимент, тогава транзакцията започва там и се затваря незабавно.

Тоест затваря веднага след ъпдейта?

Зависи от настройките. Назовах една настройка. Това е включено автоматично ангажиране. Тя е доста често срещана. Ако е активиран, транзакцията е отворена и затворена. Освен ако не сте казали изрично „стартиране на транзакция“ и „край на транзакция“, а просто сте стартирали заявка в сесията.

Здравейте! Благодаря за доклада! Представете си, че имаме база данни, която набъбва и набъбва и тогава сървърът остава без място. Има ли инструменти за коригиране на тази ситуация?

Мястото на сървъра по добър начин трябва да се наблюдава.

Например, DBA отиде да пие чай, беше на курорт и т.н.

Когато се създава файлова система, се създава поне малко резервно пространство, където не се записват данни.

Ами ако е напълно нула?

Там се нарича резервирано пространство, тоест може да се освободи и в зависимост от това колко голямо е създадено, получавате свободно място. По подразбиране не знам колко са. И в друг случай доставете дискове, за да имате къде да извършите операция по възстановяване. Можете да изтриете таблица, която гарантирано няма да ви трябва.

Няма ли други инструменти?

Винаги е ръчна изработка. И на място се разкрива какво е по-добре да се направи там, защото има данни, които са критични, има и некритични. И за всяка база данни и приложение, което работи с нея, зависи от бизнеса. Винаги се решава на място.

Благодаря за доклада! Имам два въпроса. Първо, вие показахте слайдове, където беше показано, че в случай на увиснали транзакции, както количеството таблично пространство, така и размерът на индекса нарастват. И по-нататък в доклада имаше куп помощни програми, които опаковат таблета. А какво да кажем за индекса?

Опаковат ги и тях.

Но вакуумът не влияе на индекса?

Някои работят с индекс. Например pg_rapack, pgcompacttable. Вакуумът пресъздава индексите, въздейства върху тях. VACUUM FULL има същността да презаписва всичко, т.е. работи с всички.

И вторият въпрос. Не разбрах защо докладите за реплики зависят толкова много от самата репликация. Струваше ми се, че отчетите се четат, а репликацията е писане.

Какво причинява конфликт на репликация? Имаме Учител, върху който протичат процесите. Имаме автовакуум. Автовакуумът всъщност какво прави? Той изрязва някои стари редове. Ако в този момент имаме заявка на репликата, която чете тези стари редове, и на Master е имало ситуация, че автовакуумът е маркирал тези редове като възможни за презаписване, тогава ние ги презаписваме. И получихме пакет с данни, когато трябва да пренапишем редовете, от които се нуждае заявката в репликата, тогава процесът на репликация ще изчака времето за изчакване, което сте конфигурирали. И тогава PostgreSQL ще реши кое е по-важно за него. И репликацията е по-важна за него от заявката и той ще изстреля заявката, за да направи тези промени в репликата.

Андрей, имам въпрос. Тези прекрасни графики, които показахте по време на презентацията, това резултат ли е от някаква работа на вашата помощна програма? Как са направени класациите?

Това е услуга Okmeter.

Това търговски продукт ли е?

да Това е търговски продукт.

Източник: www.habr.com