Типичне грешке у апликацијама које доводе до надимања у постгрескл-у. Андреј Салников

Предлажем да прочитате транскрипт извештаја Андреја Салникова са почетка 2016. „Типичне грешке у апликацијама које доводе до надимања у постгрескл-у“

У овом извештају анализираћу главне грешке у апликацијама које настају у фази пројектовања и писања кода апликације. И узећу само оне грешке које доводе до надимања у Постгрескл-у. По правилу, ово је почетак краја перформанси вашег система у целини, иако у почетку нису били видљиви предуслови за то.

Драго ми је свима! Овај извештај није толико технички као претходни од мог колеге. Овај извештај је углавном намењен програмерима позадинских система јер имамо прилично велики број клијената. И сви праве исте грешке. Рећи ћу вам о њима. Објаснићу до каквих погубних и лоших ствари доводе ове грешке.

Зашто се праве грешке? Раде се из два разлога: насумично, можда ће и успети и због непознавања неких механизама који се јављају на нивоу између базе и апликације, као и у самој бази података.

Даћу вам три примера са страшним сликама како су ствари постале лоше. Укратко ћу вам рећи о механизму који се тамо дешава. И како се носити са њима, када су се десили и које превентивне методе користити да спречите грешке. Рећи ћу вам о помоћним алатима и пружити корисне везе.

Користио сам тестну базу података у којој сам имао две табеле. Једна плоча са рачунима клијената, друга са трансакцијама на овим рачунима. И са одређеном фреквенцијом ажурирамо стања на овим рачунима.

Почетни подаци плоче: прилично је мала, 2 МБ. Време одзива за базу података и посебно за знак је такође веома добро. И прилично добро оптерећење - 2 операција у секунди према плочи.

И кроз овај извештај ћу вам показати графиконе тако да можете јасно разумети шта се дешава. Увек ће постојати 2 слајда са графиконима. Први слајд је оно што се генерално дешава на серверу.

И у овој ситуацији видимо да заиста имамо мали знак. Индекс је мали и износи 2 МБ. Ово је први графикон са леве стране.

Просечно време одговора на серверу је такође стабилно и кратко. Ово је горњи десни графикон.

Доњи леви графикон приказује најдуже трансакције. Видимо да се трансакције брзо завршавају. А аутовакум овде још не ради, јер је то био почетни тест. Наставиће да ради и биће нам од користи.

Други слајд ће увек бити посвећен плочици која се тестира. У овој ситуацији, ми стално ажурирамо стање на клијентовим рачунима. И видимо да је просечно време одговора за операцију ажурирања прилично добро, мање од једне милисекунде. Видимо да се ресурси процесора (ово је горњи десни графикон) такође троше равномерно и прилично мало.

Доњи десни графикон показује колико оперативне и диск меморије пролазимо у потрази за жељеном линијом пре него што је ажурирамо. А број операција према знаку је 2 у секунди, као што сам рекао на почетку.

А сада имамо трагедију. Из неког разлога постоји давно заборављена трансакција. Разлози су обично банални:

• Један од најчешћих је да смо почели да приступамо спољној услузи у коду апликације. А ова служба нам не одговара. То јест, отворили смо трансакцију, извршили промену у бази података и прешли са апликације на читање поште или на другу услугу у оквиру наше инфраструктуре, а она нам из неког разлога не одговара. А наша седница је запела у стању да се не зна када ће бити решена.
• Друга ситуација је када се у нашем коду из неког разлога догоди изузетак. И у изузетку, нисмо обрадили затварање трансакције. И завршили смо са висином сесије са отвореном трансакцијом.
• И последњи је такође прилично чест случај. Ово је код ниског квалитета. Неки оквири отварају трансакцију. Виси, а можда не знате у апликацији да га имате.

Куда такве ствари воде?

До те мере да наше табеле и индекси почињу драматично да расту. Ово је потпуно исти ефекат надимања. За базу података, то ће значити да ће се време одзива базе података веома нагло повећати и оптерећење сервера базе података ће се повећати. И као резултат тога, наша апликација ће патити. Јер ако сте потрошили 10 милисекунди у свом коду на захтев бази података, 10 милисекунди на своју логику, онда је вашој функцији требало 20 милисекунди да се заврши. И сада ће ваша ситуација бити потпуно тужна.

И да видимо шта ће се десити. Доњи леви графикон показује да имамо дугу дугу трансакцију. А ако погледамо горњи леви графикон, видимо да је величина наше табеле изненада скочила са два мегабајта на 300 мегабајта. Истовремено, количина података у табели се није променила, односно постоји прилично велика количина смећа.

Општа ситуација у вези са просечним временом одзива сервера се такође променила за неколико редова величине. То јест, сви захтеви на серверу су у потпуности почели да опадају. А истовремено су покренути интерни Постгрес процеси у виду аутовакума, који покушавају нешто да ураде и троше ресурсе.

Шта се дешава са нашим знаком? Исти. Наше просечно време одзива према знаку је скочило за неколико редова величине. Конкретно у погледу утрошених ресурса, видимо да је оптерећење процесора веома порасло. Ово је горњи десни графикон. И повећао се јер процесор мора да сортира гомилу бескорисних линија у потрази за оним потребним. Ово је доњи десни графикон. И као резултат тога, наш број позива у секунди је почео веома значајно да опада, јер база података није имала времена да обради исти број захтева.

Морамо да се вратимо у живот. Идемо на интернет и сазнајемо да дуге трансакције доводе до проблема. Проналазимо и уништавамо ову трансакцију. И све нам постаје нормално. Све ради како треба.

Смирили смо се, али након неког времена почињемо да примећујемо да апликација не ради на исти начин као пре хитног случаја. Захтеви се и даље спорије обрађују и знатно спорије. Један и по до два пута спорије, конкретно у мом примеру. Оптерећење сервера је такође веће него што је било пре несреће.

И питање: „Шта се у овом тренутку дешава са базом?“ И следећа ситуација се дешава са базом. На графикону трансакција можете видети да је стало и да заиста нема дугорочних трансакција. Али величина знака се фатално повећала током несреће. И од тада се нису смањивали. Просечно време на бази се стабилизовало. И чини се да одговори стижу адекватно брзином која је нама прихватљива. Аутовакуум је постао активнији и почео је нешто да ради са знаком, јер треба да просија више података.

Конкретно, према пробној табли са рачунима, где мењамо стања: време одговора на захтев изгледа да се вратило у нормалу. Али у стварности је један и по пута већи.

А из оптерећења процесора видимо да се оптерећење на процесору није вратило на потребну вредност пре пада. А разлози тамо леже управо у доњем десном графикону. Види се да се ту тражи одређена количина меморије. То јест, да бисмо пронашли потребну линију, трошимо ресурсе сервера базе података док сортирамо бескорисне податке. Број трансакција у секунди се стабилизовао.

Генерално добро, али ситуација је гора него што је била. Јасна деградација базе података као последица наше апликације која ради са овом базом података.

А да бисте разумели шта се тамо дешава, ако нисте били у претходном извештају, хајде сада да пређемо на мало теорије. Теорија о унутрашњем процесу. Зашто аутомобилски усисивач и чему служи?

Дословно укратко за разумевање. У неком тренутку имамо сто. Имамо редове у табели. Ове линије могу бити активне, живе и оно што нам је сада потребно. На слици су означене зеленом бојом. И постоје рокови који су већ разрађени, ажурирани и на њима су се појавили нови уноси. И означени су да више нису интересантни бази података. Али они су у табели због Постгрес функције.

Зашто вам је потребан усисивач за аутомобил? У неком тренутку долази аутовакуум, приступа бази података и пита је: „Молим вас, дајте ми ИД најстарије трансакције која је тренутно отворена у бази података.“ База података враћа овај ИД. А аутовакуум, ослањајући се на њега, сортира редове у табели. А ако види да су неке линије промењене много старијим трансакцијама, онда има право да их означи као линије које можемо поново користити у будућности уписивањем нових података тамо. Ово је позадински процес.

У овом тренутку настављамо да радимо са базом података и настављамо да уносимо неке измене у табелу. И на овим линијама, које можемо поново користити, уписујемо нове податке. И тако добијамо циклус, тј. све време тамо се појављују мртви стари редови, уместо њих записујемо нове редове који су нам потребни. И ово је нормално стање за ПостгреСКЛ да ради.

Шта се десило током несреће? Како се тамо одвијао овај процес?

Имали смо знак у неком стању, неки живи, неки мртви. Стигао је ауто усисивач. Питао је базу података која је наша најстарија трансакција и који је њен ИД. Добио сам овај ИД, који би могао бити пре много сати, можда пре десет минута. Зависи од тога колико је оптерећење ваше базе података. И отишао је да тражи линије које би могао да означи као поново употребљене. И нисам нашао такве редове у нашој табели.

Али у овом тренутку настављамо да радимо са столом. Нешто радимо у њему, ажурирамо га, мењамо податке. Шта база података треба да уради у овом тренутку? Она нема другог избора осим да дода нове редове на крај постојеће табеле. И тако величина нашег стола почиње да расте.

У стварности, потребне су нам зелене линије да бисмо радили. Али током таквог проблема, испоставља се да је проценат зелених линија изузетно низак у целој табели.

А када извршимо упит, база података мора да прође кроз све редове: и црвене и зелене, да би пронашла жељену линију. А ефекат надувавања табеле са бескорисним подацима назива се „надувавање“, што такође троши наш простор на диску. Сећате се, било је 2 МБ, постало је 300 МБ? Сада промените мегабајте у гигабајте и брзо ћете изгубити све ресурсе диска.

Какве последице могу имати по нас?

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

У ту сврху постоји одређени циклус рада који се изводи.

Прво морамо пронаћи проблематичне табеле које су надувене. Разумемо да је у неким табелама снимање активније, у другим мање. И за ово користимо екстензију пгстаттупле. Инсталирањем овог проширења можете писати упите који ће вам помоћи да пронађете табеле које су прилично надувене.

Када пронађете ове табеле, потребно је да их компримујете. Већ постоје алати за ово. У нашој компанији користимо три алата. Први је уграђени ВАЦУУМ ФУЛЛ. Он је суров, оштар и немилосрдан, али понекад је веома користан. Пг_репацк и пгцомпацттабле - Ово су помоћни програми треће стране за компресију табела. И они се пажљивије односе према бази података.

Користе се у зависности од тога шта вам је згодније. Али о овоме ћу вам рећи на самом крају. Главна ствар је да постоје три алата. Има много тога за изабрати.

Након што смо све исправили и уверили се да је све у реду, морамо знати како да спречимо ову ситуацију у будућности:

• Може се прилично лако спречити. Потребно је да пратите трајање сесија на главном серверу. Посебно опасне сесије у стању мировања у стању трансакције. То су они који су управо отворили трансакцију, урадили нешто и отишли, или једноставно зависили, изгубили се у коду.
• А за вас, као програмере, важно је да тестирате свој код када се појаве такве ситуације. То није тешко урадити. Ово ће бити корисна провера. Избећи ћете велики број „детињастих“ проблема повезаних са дугим трансакцијама.

На овим графиконима, желео сам да вам покажем како су се променили знак и понашање базе података након што сам прошао кроз знак са ВАЦУУМ ФУЛЛ у овом случају. Ово за мене није продукција.

Величина табеле се одмах вратила у нормално радно стање од неколико мегабајта. Ово није у великој мери утицало на просечно време одговора за сервер.

Али посебно за наш тестни знак, где смо ажурирали стања на рачуну, видимо да је просечно време одговора на захтев за ажурирање података у знаку смањено на нивое пре хитног случаја. Ресурси које је процесор потрошио да испуни овај захтев такође су пали на нивое пре пада. А доњи десни графикон показује да сада налазимо тачно ону линију која нам је потребна одмах, без проласка кроз гомиле мртвих линија које су постојале пре него што је табела била компримована. А просечно време захтева је остало на приближно истом нивоу. Али овде имам, пре, грешку у мом хардверу.

Ту се прва прича завршава. Најчешћи је. И то се дешава свима, без обзира на искуство клијента и колико су квалификовани програмери. Пре или касније ово се деси.

Друга прича, у којој распоређујемо оптерећење и оптимизујемо ресурсе сервера

• Већ смо одрасли и постали озбиљни момци. И ми разумемо да имамо реплику и било би добро да избалансирамо оптерећење: пишите Мајстору, а читајте са реплике. И обично ова ситуација настаје када желимо да припремимо неке извештаје или ЕТЛ. И бизнис је веома срећан због овога. Он заиста жели разне извештаје са пуно сложене аналитике.
• Извештаји трају много сати, јер се сложена аналитика не може израчунати у милисекундама. Ми, као храбри момци, пишемо код. У апликацији за уметање вршимо снимање на Мастеру, а на реплици извршавамо извештаје.
• Расподела оптерећења.
• Све ради савршено. ми смо супер.

А како изгледа ова ситуација? Конкретно на овим графиконима, додао сам и трајање трансакција из реплике за трајање трансакције. Сви остали графикони се односе само на главни сервер.

До тог времена, моја табла за извештаје је порасла. Има их више. Видимо да је просечно време одговора сервера стабилно. Видимо да на реплици имамо дуготрајну трансакцију која траје 2 сата. Видимо тихи рад аутовакума, који обрађује мртве линије. А код нас је све у реду.

Конкретно, према тестираној таблици, настављамо да ажурирамо стања на рачуну. Такође имамо стабилно време одговора на захтеве, стабилну потрошњу ресурса. Код нас је све у реду.

Све је у реду до тренутка када ови извештаји почну да се враћају због сукоба са репликацијом. И узвраћају ватру у редовним интервалима.

Идемо на интернет и почињемо да читамо зашто се то дешава. И налазимо решење.

Прво решење је повећање латенције репликације. Знамо да наш извештај траје 3 сата. Поставили смо кашњење репликације на 3 сата. Покрећемо све, али и даље имамо проблема са извештајима који се понекад отказују.

Желимо да све буде савршено. Пењемо се даље. И нашли смо кул поставку на Интернету - хот_стандби_феедбацк. Хајде да га укључимо. Хот_стандби_феедбацк нам омогућава да задржимо аутовацуум на Мастер-у. Тако се потпуно ослобађамо сукоба репликације. И све нам добро функционише са извештајима.

И шта се дешава са главним сервером у овом тренутку? А ми смо у тоталној невољи са главним сервером. Сада видимо графиконе када имам омогућена оба ова подешавања. И видимо да је сесија на нашој реплици некако почела да утиче на ситуацију на Мастер серверу. Она има ефекта јер је паузирала аутовакуум, чиме се уклањају рокови. Величина нашег стола је поново нагло порасла. Просечно време извршавања упита у целој бази података је такође нагло порасло. Аутовакуми су се мало затегли.

Конкретно, са наше плоче видимо да је ажурирање података на њој такође скочило у небо. Потрошња ЦПУ-а се на сличан начин значајно повећала. Опет пролазимо кроз велики број мртвих, бескорисних редова. И време одзива за овај знак и број трансакција су опали.

Како ће то изгледати ако не знамо о чему сам раније говорио?

• Почињемо да тражимо проблеме. Ако смо наишли на проблеме у првом делу, знамо да је то можда због дуге трансакције и идемо код Мастера. Имамо проблем са Мастером. Кобасице га. Загрева се, његов просек оптерећења је око сто.
• Захтеви су спори, али тамо не видимо дуготрајне трансакције. И не разумемо шта је у питању. Не разумемо где да гледамо.
• Проверавамо серверску опрему. Можда је наш напад пропао. Можда је наш меморијски штап изгорео. Да, свашта се може догодити. Али не, сервери су нови, све ради како треба.
• Сви трче: администратори, програмери и директор. Ништа не помаже.
• И у неком тренутку све одједном почиње да се исправља.

У овом тренутку, захтев за нашу реплику је обрађен и остављен. Добили смо извештај. Посао је и даље срећан. Као што видите, наш знак је поново порастао и неће се смањити. На графикону са сесијама оставио сам део ове дугачке трансакције из реплике да бисте могли да процените колико је времена потребно док се ситуација не стабилизује.

Седница је завршена. И тек након неког времена сервер долази мање-више у ред. А просечно време одговора за захтеве на главном серверу се враћа у нормалу. Јер, коначно, аутовакуум има могућност да очисти и обележи ове рокове. И почео је да ради свој посао. И колико брзо он то уради, тако ћемо брзо доћи у ред.

Према тестираном таблету, где ажурирамо стање на рачуну, видимо потпуно исту слику. Просечно време ажурирања налога такође се постепено нормализује. Ресурси које троши процесор су такође смањени. И број трансакција у секунди се враћа у нормалу. Али опет смо се вратили у нормалу, а не као пре несреће.

У сваком случају, добијамо пад учинка, као у првом случају, један и по до два пута, а понекад и више.

Чини се да смо све урадили како треба. Распоредите оптерећење. Опрема не мирује. Поделили смо захтеве према памети, али је ипак све испало лоше.

• Немојте омогућити хот_стандби_феедбацк? Да, није препоручљиво да га укључите без посебно јаких разлога. Зато што овај обрт директно утиче на главни сервер и тамо обуставља рад аутовакума. Ако га омогућите на некој реплици и заборавите на њега, можете убити Мастер и добити велике проблеме са апликацијом.
• Повећати мак_стандби_стреаминг_делаи? Да, за извештаје је то тачно. Ако имате тросатни извештај и не желите да се сруши због сукоба репликације, једноставно повећајте кашњење. Дугорочни извештај никада не захтева податке који су тренутно стигли у базу података. Ако га имате три сата, онда га користите за неки стари период података. А за вас, да ли постоји кашњење од три сата или шест сати, неће бити никакве разлике, али ћете стално добијати извештаје и нећете имати проблема са њиховим опадањем.
• Наравно, морате да контролишете дуге сесије на репликама, посебно ако одлучите да омогућите хот_стандби_феедбацк на реплици. Јер свашта се може догодити. Ову реплику смо дали програмеру како би могао да тестира захтеве. Написао је луду молбу. Покренуо га је и отишао да попије чај, а ми смо добили успостављеног Учитеља. Или смо можда тамо ставили погрешну апликацију. Ситуације су различите. Сесије на репликама морају се пратити пажљиво као и на Мастеру.
• А ако имате брзе и дугачке упите о репликама, онда је у овом случају боље да их поделите да бисте распоредили оптерећење. Ово је веза до стреаминг_делаи. За брзе, имајте једну реплику са малим кашњењем репликације. За дуготрајне захтеве за извештавање, имајте реплику која може да касни 6 сати или један дан. Ово је сасвим нормална ситуација.

Последице отклањамо на исти начин:

• Налазимо надувене столове.
• И компресујемо га најпогоднијим алатом који нам одговара.

Друга прича се овде завршава. Пређимо на трећу причу.

Такође прилично уобичајено за нас у којима радимо миграцију.

• Сваки софтверски производ расте. Захтеви за то се мењају. У сваком случају, желимо да се развијамо. И дешава се да морамо да ажурирамо податке у табели, односно да покренемо ажурирање у смислу наше миграције за нову функционалност коју уводимо као део нашег развоја.
• Стари формат података није задовољавајући. Рецимо да сада пређемо на другу табелу, где имам трансакције на овим рачунима. И рецимо да су били у рубљама, а ми смо одлучили да повећамо тачност и урадимо то у копејкама. А за ово треба да извршимо ажурирање: помножите поље са износом трансакције са сто.
• У данашњем свету користимо аутоматизоване алате за контролу верзија базе података. Рецимо Ликуибасе. Тамо региструјемо нашу миграцију. Тестирамо га на нашој тестној бази. Све је у реду. Ажурирање је у току. На неко време блокира рад, али добијамо ажуриране податке. И можемо покренути нову функционалност на овоме. Све је тестирано и проверено. Све се потврдило.
• Спровели смо плански посао и извршили миграцију.

Ево миграције са ажурирањем представљеним пред вама. Пошто су ово моје трансакције на рачуну, плоча је била 15 ГБ. И пошто ажурирамо сваки ред, удвостручили смо величину табеле са ажурирањем, јер смо преписали сваки ред.

Током миграције, нисмо могли ништа да урадимо са овом плочом, јер су сви захтеви према њој стајали у реду и чекали док се ово ажурирање не заврши. Али овде желим да вам скренем пажњу на бројеве који се налазе на вертикалној оси. То јест, имамо просечно време захтева пре миграције од око 5 милисекунди и оптерећење процесора, број блок операција за читање меморије диска је мањи од 7,5.

Извршили смо миграцију и поново смо добили проблеме.

Миграција је била успешна, али:

• Стара функционалност сада траје дуже да се заврши.
• Стол је поново порастао.
• Оптерећење сервера је поново постало веће него раније.
• И, наравно, још увек петљамо са функционалношћу која је добро функционисала, мало смо је побољшали.

А ово је опет надутост, која нам опет уништава животе.

Овде демонстрирам да се табела, као и претходна два случаја, неће вратити на своје претходне величине. Чини се да је просечно оптерећење сервера адекватно.

А ако се окренемо табели са рачунима, видећемо да се просечно време захтева за ову табелу удвостручило. Оптерећење процесора и број сортираних линија у меморији скочио је изнад 7,5, али је био мањи. И скочио је 2 пута у случају процесора, 1,5 пута у случају блок операција, односно добили смо деградацију у перформансама сервера. И као резултат - деградација перформанси наше апликације. Истовремено, број позива је остао приближно на истом нивоу.

А овде је главна ствар разумети како правилно извршити такве миграције. И треба их урадити. Ове миграције радимо прилично доследно.

• Овако велике миграције се не дешавају аутоматски. Они увек морају бити под контролом.
• Потребан је надзор од стране упућене особе. Ако имате ДБА у свом тиму, пустите ДБА да то уради. То је његов посао. Ако не, онда нека то уради најискуснији човек који зна да ради са базама података.
• Нову шему базе података, чак и ако ажурирамо једну колону, увек припремамо у фазама, односно унапред пре него што се нова верзија апликације покрене:
• Додата су нова поља у која ћемо бележити ажуриране податке.
• Преносимо податке са старог поља на ново поље у малим деловима. Зашто ово радимо? Прво, ми увек контролишемо процес овог процеса. Знамо да смо већ пребацили толико серија и да нам је толико остало.
• А други позитиван ефекат је да између сваке такве серије затварамо трансакцију, отварамо нову, а то омогућава аутовакуму да ради према таблици, означава рокове за поновну употребу.
• За линије које ће се појавити док је апликација покренута (још увек имамо покренуту стару апликацију), додајемо окидач који уписује нове вредности у нова поља. У нашем случају, ово је множење са сто старе вредности.
• Ако смо потпуно тврдоглави и желимо исто поље, онда по завршетку свих миграција и пре него што покренемо нову верзију апликације, једноставно преименујемо поља. Старим је дато неко измишљено име, а нова поља се преименују у стара.
• И тек након тога покрећемо нову верзију апликације.

А у исто време нећемо се надимати и нећемо патити у погледу перформанси.

Ту се завршава трећа прича.

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

А сада мало детаљније о алатима које сам поменуо у првој причи.

Пре него што тражите блоат, морате инсталирати екстензију пгстаттупле.

Да не бисте морали да постављате упите, ове упите смо већ написали у нашем раду. Можете их користити. Овде су два захтева.

• Првом је потребно доста времена да ради, али ће вам показати тачне вредности надимања из табеле.
• Други делује брже и веома је ефикасан када је потребно брзо проценити да ли постоји надимање или не према табели. Такође треба да разумете да је надимање увек присутно у Постгрес табели. Ово је карактеристика његовог МВЦЦ модела.
• А 20% надимања је нормално за столове у већини случајева. То јест, не треба да бринете и сабијате ову табелу.

Схватили смо како да идентификујемо табеле које су набрекле бескорисним подацима.

Сада о томе како да поправите надимање:

• Ако имамо мали таблет и добре дискове, односно на таблету до гигабајта, сасвим је могуће користити ВАЦУУМ ФУЛЛ. Узеће вам ексклузивну браву на столу на неколико секунди и у реду, али ће све учинити брзо и оштро. Шта ради ВАЦУУМ ФУЛЛ? Потребно је ексклузивно закључавање на табели и преписује живе редове из старих табела у нову табелу. И на крају их замењује. Брише старе датотеке и замењује старе новим. Али за време свог рада, потребно је ексклузивно закључавање на столу. То значи да не можете ништа да урадите са овом табелом: нити писати у њу, нити читати у њу, нити је мењати. А ВАЦУУМ ФУЛЛ захтева додатни простор на диску за писање података.
• Следећи алат пг_репацк. По свом принципу, веома је сличан ВАЦУУМ ФУЛЛ, јер такође преписује податке из старих датотека у нове и замењује их у табели. Али у исто време, он не узима ексклузивну браву на столу на самом почетку свог рада, већ је узима само у тренутку када већ има спремне податке како би заменио датотеке. Захтеви за ресурсе диска су слични онима за ВАЦУУМ ФУЛЛ. Потребан вам је додатни простор на диску, а то је понекад критично ако имате табеле од терабајта. И прилично је гладан процесора јер активно ради са И/О.
• Трећа помоћ је пгцомпацттабле. Опрезнији је са ресурсима јер ради по мало другачијим принципима. Главна идеја пгцомпацттабле је да помера све живе редове на почетак табеле користећи ажурирања у табели. И онда се ствара вакуум на овом столу, јер знамо да имамо живе редове на почетку и мртве редове на крају. И сам вакуум одсече овај реп, односно не захтева много додатног простора на диску. А у исто време и даље може да се стисне у смислу ресурса.

Све са алатима.

Ако сматрате да је тема надувености занимљива у смислу даљег удубљивања, ево неколико корисних веза:

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

Покушао сам више да прикажем хорор причу за програмере, јер су они наши директни клијенти база података и морају да разумеју до чега и до чега воде. Надам се да сам успео. Хвала на пажњи!

pitanja

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

У овом случају, ово је задатак за администраторе ваше компаније, а не нужно за ДБА.

Ја сам администратор.

ПостгреСКЛ има поглед назван пг_стат_ацтивити који приказује висеће упите. И можете видети колико дуго тамо виси.

Да ли морам да уђем и погледам сваких 5 минута?

Подесите црон и проверите. Ако имате дугорочни захтев, напишите писмо и то је то. То јест, не морате да гледате својим очима, то се може аутоматизовати. Добићете писмо, реагујете на њега. Или можете пуцати аутоматски.

Постоје ли очигледни разлози зашто се то дешава?

Навео сам неке. Други сложенији примери. И може се дуго разговарати.

Хвала на извештају! Желео сам да разјасним услужни програм пг_репацк. Ако она не уради ексклузивно закључавање, онда...

Она ради ексклузивну браву.

... онда бих потенцијално могао да изгубим податке. Да ли моја апликација не би требало да снима ништа за то време?

Не, ради глатко са табелом, тј. пг_репацк прво преноси све живе линије које постоје. Наравно, ту се дешава нека врста уласка у табелу. Он само избацује овај коњски реп.

Односно, он то на крају заиста и уради?

На крају, он узима ексклузивну браву да би заменио ове датотеке.

Да ли ће то бити брже од ВАЦУУМ ФУЛЛ?

ВАЦУУМ ФУЛЛ, чим је почео, одмах је узео ексклузивну браву. И док не уради све, неће је пустити. А пг_репацк преузима ексклузивно закључавање само у тренутку замене датотеке. У овом тренутку нећете писати тамо, али подаци неће бити изгубљени, све ће бити у реду.

Здраво! Говорили сте о раду усисивача аутомобила. Постојао је графикон са црвеним, жутим и зеленим ћелијама за снимање. Односно жуте – означио их је као обрисане. И као резултат, може се у њих уписати нешто ново?

Да. Постгрес не брише линије. Он има такву специфичност. Ако смо ажурирали линију, стари смо означили као избрисани. Тамо се појављује ИД трансакције која је променила овај ред, а ми пишемо нови ред. И имамо сесије које би потенцијално могле да их прочитају. У неком тренутку постају прилично стари. А суштина рада аутовакума је да он пролази кроз ове линије и означава их као непотребне. И тамо можете преписати податке.

Разумем. Али то није оно о чему се ради. Нисам завршио. Претпоставимо да имамо сто. Има поља променљиве величине. А ако покушам да убацим нешто ново, можда једноставно не стане у стару ћелију.

Не, у сваком случају цела линија је ажурирана тамо. Постгрес има два модела складиштења података. Он бира из типа података. Постоје подаци који се чувају директно у табели, а постоје и тос подаци. То су велике количине података: текст, јсон. Чувају се у одвојеним плочама. И по овим таблетама се дешава иста прича са надимањем, односно све је исто. Они су само наведени одвојено.

Хвала на извештају! Да ли је прихватљиво користити упите за временско ограничење израза за ограничавање трајања?

Веома прихватљиво. Користимо ово свуда. А пошто немамо сопствене услуге, пружамо подршку на даљину, имамо доста различитих клијената. И сви су овим потпуно задовољни. То јест, имамо црон послове који проверавају. Трајање сесија се једноставно договара са клијентом, пре чега се не договарамо. Може бити минут, може бити 10 минута. Зависи од оптерећења базе и њене намене. Али сви користимо пг_стат_ацтивити.

Хвала на извештају! Покушавам да применим ваш извештај на своје апликације. И чини се да свуда започињемо трансакцију и свуда је јасно завршавамо. Ако постоји неки изузетак, онда се враћање и даље дешава. А онда сам почео да размишљам. На крају крајева, трансакција можда неће почети експлицитно. Ово је вероватно наговештај девојци. Ако само ажурирам запис, да ли ће трансакција почети у ПостгреСКЛ-у и завршити се тек када се веза прекине?

Ако сада говорите о нивоу апликације, онда то зависи од драјвера који користите, од ОРМ-а који се користи. Тамо има много подешавања. Ако имате омогућено аутоматско урезивање, онда трансакција почиње тамо и одмах се затвара.

То јест, затвара се одмах након ажурирања?

Зависи од подешавања. Назвао сам једну поставку. Ово је укључено аутоматско урезивање. То је прилично уобичајено. Ако је омогућено, трансакција је отворена и затворена. Осим ако нисте експлицитно рекли „покрени трансакцију“ и „заврши трансакцију“, али једноставно сте покренули захтев у сесији.

Здраво! Хвала на извештају! Замислимо да имамо базу података која буја и буја и онда понестане простора на серверу. Постоје ли неки алати за поправљање ове ситуације?

Простор на серверу треба правилно надгледати.

На пример, ДБА је отишао на чај, био у одмаралишту итд.

Када се креира систем датотека, ствара се бар нека врста резервног простора где подаци нису уписани.

Шта ако је потпуно испод нуле?

Тамо се зове резервисани простор, односно може се ослободити и у зависности од тога колико је велики, добијате слободан простор. Подразумевано не знам колико их има. А у другом случају, испоручите дискове тако да имате простора да извршите реконструктивну операцију. Можете да избришете неку табелу за коју је гарантовано да вам није потребна.

Има ли других алата?

Увек је ручно рађено. И локално постаје јасно шта је тамо најбоље урадити, јер су неки подаци критични, а неки некритични. А за сваку базу података и апликацију која ради са њом зависи од посла. Увек се одлучује локално.

Хвала на извештају! Имам два питања. Прво сте показали слајдове који су показали да када се трансакције заглаве, расте и величина простора табеле и величина индекса. И даље у извештају постоји гомила услужних програма који пакују таблет. Шта је са индексом?

И њих пакују.

Али вакуум не утиче на индекс?

Неки раде са индексом. На пример, пг_рапацк, пгцомпацттабле. Вакум поново ствара индексе и утиче на њих. Са ВАЦУУМ ФУЛЛ идеја је да се све препише, тј. ради са свима.

И друго питање. Не разумем зашто извештаји о репликама толико зависе од саме репликације. Чинило ми се да се извештаји читају, а репликација пише.

Шта узрокује конфликт репликације? Имамо Учитеља на коме се одвијају процеси. У току је усисавање аутомобила. Шта заправо ради аутовакуум? Он исече неке старе линије. Ако у овом тренутку имамо захтев на реплици која чита ове старе редове, а на Мастеру се десила ситуација да је аутовакуум означио ове редове као могуће за преписивање, онда смо их преписали. И добили смо пакет података, када треба да препишемо оне линије које су потребне захтеву на реплици, процес репликације ће чекати временско ограничење које сте конфигурисали. А онда ће ПостгреСКЛ одлучити шта му је важније. А репликација му је важнија од захтева, а он ће да снима захтев да би извршио ове измене на реплици.

Андреј, имам питање. Да ли су ови дивни графикони које сте показали током презентације резултат рада неког вашег услужног програма? Како су направљени графови?

Ово је услуга Окметер.

Да ли је ово комерцијални производ?

Да. Ово је комерцијални производ.

Извор: ввв.хабр.цом