Ви предлагам да го прочитате транскриптот од извештајот од почетокот на 2016 година од Андреј Салников „Типични грешки во апликациите што доведуваат до надуеност во postgresql“
Во овој извештај, ќе ги анализирам главните грешки во апликациите што се јавуваат во фазата на дизајнирање и пишување код на апликацијата. И ќе ги земам само оние грешки кои водат до надуеност во Postgresql. Како по правило, ова е почеток на крајот на перформансите на вашиот систем како целина, иако првично не беа видливи предуслови за ова.
Мило ми е да им посакам добредојде на сите! Овој извештај не е толку технички како претходниот од мојот колега. Овој извештај главно е наменет за развивачите на задни системи бидејќи имаме прилично голем број клиенти. И сите ги прават истите грешки. Ќе ти кажам за нив. Ќе објаснам до какви фатални и лоши работи водат овие грешки.
Зошто се прават грешки? Тие се прават од две причини: по случаен избор, можеби ќе успее и поради непознавање на некои механизми кои се јавуваат на ниво помеѓу базата на податоци и апликацијата, како и во самата база на податоци.
Ќе ви дадам три примери со страшни слики за тоа колку лоши работите станаа. Накратко ќе ви кажам за механизмот што се случува таму. И како да се справите со нив, кога се случиле и кои превентивни методи да ги користите за да спречите грешки. Ќе ви кажам за помошните алатки и ќе дадам корисни врски.
Користев тест база на податоци каде имав две табели. Едната плоча со сметки на клиенти, другата со трансакции на овие сметки. И со одредена фреквенција ги ажурираме салдата на овие сметки.
Почетни податоци на плочата: таа е прилично мала, 2 MB. Времето на одговор за базата на податоци и конкретно за знакот е исто така многу добро. И прилично добро оптоварување - 2 операции во секунда според плочата.
И преку овој извештај ќе ви покажам графикони за да можете јасно да разберете што се случува. Секогаш ќе има 2 слајдови со графикони. Првиот слајд е она што се случува генерално на серверот.
И во оваа ситуација, гледаме дека навистина имаме мал знак. Индексот е мал и изнесува 2 MB. Ова е првиот графикон лево.
Просечното време на одговор на серверот е исто така стабилно и кратко. Ова е горната десна графика.
Долниот лев графикон ги прикажува најдолгите трансакции. Гледаме дека трансакциите се завршуваат брзо. А автовакуумот сè уште не работи овде, бидејќи тоа беше тест за почеток. Ќе продолжи да работи и ќе ни биде од корист.
Вториот слајд секогаш ќе биде посветен на плочата што се тестира. Во оваа ситуација, ние постојано ги ажурираме билансите на сметките на клиентот. И гледаме дека просечното време на одговор за операцијата за ажурирање е доста добро, помалку од една милисекунда. Гледаме дека ресурсите на процесорот (ова е горниот десен график) исто така се трошат рамномерно и прилично мали.
Долниот десен графикон покажува колку оперативна и меморија на дискот поминуваме во потрага по нашата посакувана линија пред да ја ажурираме. А бројот на операции според знакот е 2 во секунда како што кажав на почетокот.
И сега имаме трагедија. Поради некоја причина постои долго заборавена трансакција. Причините обично се банални:
- Еден од најчестите е тоа што почнавме да пристапуваме до надворешна услуга во кодот на апликацијата. И оваа услуга не ни одговара. Односно, отворивме трансакција, направивме промена во базата на податоци и отидовме од апликацијата да чита пошта или до друга услуга во рамките на нашата инфраструктура, и поради некоја причина таа не ни одговара. И нашата седница е заглавена во состојба кога не се знае кога ќе се реши.
- Втората ситуација е кога поради некоја причина се случи исклучок во нашиот код. И во исклучок не го обработивме затворањето на трансакцијата. И завршивме со висечка сесија со отворена трансакција.
- И последниот е исто така прилично чест случај. Ова е код со низок квалитет. Некои рамки отвораат трансакција. Виси, а можеби не знаете во апликацијата дека го имате виси.
Каде водат такви работи?
До тој степен што нашите табели и индекси почнуваат драматично да отекуваат. Ова е токму истиот ефект на надуеност. За базата на податоци, тоа ќе значи дека времето на одговор на базата на податоци ќе се зголеми многу нагло и ќе се зголеми оптоварувањето на серверот на базата на податоци. И како резултат на тоа, нашата апликација ќе страда. Затоа што ако потрошивте 10 милисекунди во вашиот код на барање до базата на податоци, 10 милисекунди на вашата логика, тогаш на вашата функција беа потребни 20 милисекунди за да се заврши. И сега вашата ситуација ќе биде целосно тажна.
И да видиме што ќе се случи. Долниот лев графикон покажува дека имаме долга долга трансакција. И ако го погледнеме горниот лев графикон, ќе видиме дека големината на нашата табела одеднаш скокна од два мегабајти на 300 мегабајти. Во исто време, количината на податоци во табелата не е променета, односно има прилично голема количина ѓубре таму.
Општата ситуација во однос на просечното време на одговор на серверот исто така се промени за неколку реда на големина. Тоа е, сите барања на серверот почнаа целосно да паѓаат. И во исто време, беа лансирани внатрешни процеси на Postgres во форма на автовакуум, кои се обидуваат да направат нешто и трошат ресурси.
Што се случува со нашиот знак? Исто. Нашето просечно време на одговор според знакот скокна неколку реда на големина. Поточно во однос на потрошените ресурси, гледаме дека оптоварувањето на процесорот е значително зголемено. Ова е горната десна графика. И се зголеми затоа што процесорот треба да подреди низ куп бескорисни линии во потрага по потребната. Ова е долниот десен график. И како резултат на тоа, нашиот број на повици во секунда почна многу значително да опаѓа, бидејќи базата на податоци немаше време да обработи ист број барања.
Треба да се вратиме во живот. Одиме онлајн и дознаваме дека долгите трансакции доведуваат до проблеми. Ја наоѓаме и ја убиваме оваа трансакција. И сè ни станува нормално. Сè функционира како што треба.
Се смиривме, но по некое време почнуваме да забележуваме дека апликацијата не работи исто како пред итната помош. Барањата сè уште се обработуваат побавно и значително побавно. Еден и пол до два пати побавно конкретно во мојот пример. Оптоварувањето на серверот е исто така поголемо отколку што беше пред несреќата.
И прашањето: „Што се случува со базата во овој момент? И со основата се јавува следнава ситуација. На графиконот на трансакции можете да видите дека е запрен и навистина нема долгорочни трансакции. Но, големината на знакот фатално се зголеми за време на несреќата. И од тогаш тие не се намалени. Просечното време на основата се стабилизира. А одговорите се чини дека доаѓаат соодветно со брзина прифатлива за нас. Автовакуумот стана поактивен и почна да прави нешто со знакот, бидејќи треба да просејува повеќе податоци.
Поточно, според тест-плочката со сметки, каде што ги менуваме салдата: времето на одговор за барање се чини дека се вратило во нормала. Но, во реалноста тоа е еден и пол пати поголем.
И од оптоварувањето на процесорот, гледаме дека оптоварувањето на процесорот не се вратило на потребната вредност пред падот. А причините таму лежат токму во долниот десен графикон. Се гледа дека таму се бара одредена количина на меморија. Односно, за да ја пронајдеме потребната линија, ги трошиме ресурсите на серверот на базата на податоци додека сортираме бескорисни податоци. Се стабилизираше бројот на трансакции во секунда.
Севкупно добро, но ситуацијата е полоша отколку што беше. Исчистете ја деградацијата на базата на податоци како последица на нашата апликација која работи со оваа база на податоци.
И за да разбереме што се случува таму, ако не сте биле на претходниот извештај, сега да земеме малку теорија. Теорија за внатрешниот процес. Зошто автомобилот правосмукалка и што прави тоа?
Буквално накратко за разбирање. Во одреден момент во времето имаме маса. Имаме редови во табелата. Овие линии можат да бидат активни, живи и она што ни треба сега. Тие се означени со зелено на сликата. И има рокови кои се веќе разработени, ажурирани и на нив се појавија нови записи. И тие се означени дека повеќе не се интересни за базата на податоци. Но, тие се во табелата поради функцијата Postgres.
Зошто ви треба правосмукалка за автомобил? Во одреден момент доаѓа Autovacuum, пристапува до базата на податоци и ја прашува: „Ве молам, дајте ми го ID на најстарата трансакција што е моментално отворена во базата на податоци“. Базата на податоци го враќа овој id. И автовакуумот, потпирајќи се на него, ги сортира линиите во табелата. И ако види дека некои линии се сменети од многу постари трансакции, тогаш има право да ги означи како линии што можеме повторно да ги користиме во иднина со пишување нови податоци таму. Ова е процес во позадина.
Во овој момент, ние продолжуваме да работиме со базата на податоци и продолжуваме да правиме некои промени во табелата. И на овие линии, кои можеме повторно да ги користиме, пишуваме нови податоци. И така добиваме циклус, односно цело време таму се појавуваат некои мртви стари линии, наместо нив запишуваме нови линии што ни се потребни. И ова е нормална состојба за работа на PostgreSQL.
Што се случи за време на несреќата? Како се случи овој процес таму?
Имавме знак во некоја состојба, некои живи, некои рокови. Пристигна вакуумот за автомобилот. Тој ја праша базата на податоци која е нашата најстара трансакција и кој е нејзиниот id. Го добив овој ид, кој може да е пред многу часа, можеби пред десет минути. Тоа зависи од тоа колку тежок товар имате на вашата база на податоци. И отиде да бара линии што може да ги означи како повторно употребени. И не најдов такви линии во нашата табела.
Но, во овој момент продолжуваме да работиме со табелата. Ние правиме нешто во него, го ажурираме, ги менуваме податоците. Што треба да направи базата на податоци во овој момент? Таа нема друг избор освен да додаде нови линии на крајот од постоечката табела. И така, големината на нашата маса почнува да отекува.
Во реалноста, ни требаат зелени линии за да функционираме. Но, при таков проблем, излегува дека процентот на зелени линии е исклучително низок низ целата табела.
И кога ќе извршиме барање, базата на податоци треба да ги помине сите линии: и црвена и зелена, за да ја најде саканата линија. И ефектот на надуеност на маса со бескорисни податоци се нарекува „надуеност“, што исто така ни го јаде просторот на дискот. Запомнете, беше 2 MB, стана 300 MB? Сега сменете ги мегабајтите во гигабајти и брзо ќе ги изгубите сите ваши ресурси на дискот.
Какви последици може да има за нас?
- Во мојот пример, табелата и индексот пораснаа 150 пати. Некои од нашите клиенти имале повеќе фатални случаи кога едноставно почнале да им снемува простор на дискот.
- Самата големина на маси никогаш нема да се намали. Автовакуумот во некои случаи може да ја отсече опашката на масата ако има само мртви линии. Но, бидејќи има постојана ротација, една зелена линија може да замрзне на крајот и да не се ажурира, додека сите други ќе бидат запишани некаде на почетокот на плочата. Но, ова е толку неверојатен настан што вашата маса ќе се намали во големина, па затоа не треба да се надевате на тоа.
- Базата на податоци треба да подреди низ цел куп бескорисни линии. И ние ги трошиме ресурсите на дискот, ги трошиме ресурсите на процесорот и електричната енергија.
- И ова директно влијае на нашата апликација, бидејќи ако на почетокот потрошивме 10 милисекунди на барањето, 10 милисекунди на нашиот код, тогаш за време на падот почнавме да трошиме секунда на барањето и 10 милисекунди на кодот, т.е. големината на перформансите на апликацијата се намали. И кога несреќата беше решена, почнавме да трошиме 20 милисекунди на барање, 10 милисекунди на код. Тоа значи дека продуктивноста сепак паднавме за еден и пол пати. И сето ова е поради една трансакција која замрзна, можеби по наша вина.
- И прашањето: „Како можеме да вратиме сè?
За таа цел постои одреден циклус на работа што се спроведува.
Прво треба да ги најдеме проблематичните табели кои се надуени. Разбираме дека во некои табели снимањето е поактивно, во други помалку активно. И за ова ја користиме екстензијата . Со инсталирање на оваа екстензија, можете да пишувате прашања кои ќе ви помогнат да најдете табели кои се прилично надуени.
Откако ќе ги пронајдете овие табели, треба да ги компресирате. Веќе има алатки за ова. Во нашата компанија користиме три алатки. Првиот е вградениот VACUUM FULL. Тој е суров, суров и безмилосен, но понекогаш е многу корисен. и - Ова се комунални услуги од трети лица за компресирање на табели. И повнимателно ја третираат базата на податоци.
Тие се користат во зависност од тоа што е позгодно за вас. Но, ќе ви кажам за ова на самиот крај. Главната работа е дека има три алатки. Има многу за избор.
Откако ќе исправиме сè и ќе се увериме дека се е во ред, мора да знаеме како да ја спречиме оваа ситуација во иднина:
- Тоа може да се спречи прилично лесно. Треба да го следите времетраењето на сесиите на Master серверот. Особено опасни сесии во мирување во состојба на трансакција. Тоа се оние кои штотуку отвориле трансакција, направиле нешто и си заминале, или едноставно виселе, се изгубиле во шифрата.
- И за вас, како програмери, важно е да го тестирате вашиот код кога ќе се појават овие ситуации. Не е тешко да се направи. Ова ќе биде корисна проверка. Ќе избегнете голем број „детски“ проблеми поврзани со долгите трансакции.
Во овие графикони, сакав да ви покажам како се промени знакот и однесувањето на базата откако го поминав знакот со VACUUM FULL во овој случај. Ова за мене не е продукција.
Големината на табелата веднаш се врати во нејзината нормална работна состојба од неколку мегабајти. Ова не влијаеше многу на просечното време на одговор за серверот.
Но, конкретно за нашиот знак за тестирање, каде што ги ажуриравме салдата на сметките, гледаме дека просечното време на одговор на барањето за ажурирање на податоците во знакот е намалено на нивоа пред итни случаи. Ресурсите што ги трошеше процесорот за да го заврши ова барање, исто така, паднаа на нивоата пред падот. И долниот десен графикон покажува дека сега ја наоѓаме токму линијата што ни треба веднаш, без да поминеме низ купиштата мртви линии што беа таму пред да се компресира табелата. И просечното време на барање остана на приближно исто ниво. Но, тука имам, поточно, грешка во мојот хардвер.
Тука завршува првата приказна. Тоа е најчеста. И тоа им се случува на сите, без оглед на искуството на клиентот и колку се квалификувани програмерите. Порано или подоцна тоа се случува.
Втората приказна, во која го дистрибуираме оптоварувањето и ги оптимизираме ресурсите на серверот
- Веќе пораснавме и станавме сериозни момци. И ние разбираме дека имаме реплика и би било добро да го избалансираме товарот: пишете му на мајсторот и читајте од репликата. И обично оваа ситуација се јавува кога сакаме да подготвиме некои извештаи или ETL. И бизнисот е многу среќен поради ова. Тој навистина сака различни извештаи со многу сложена аналитика.
- Извештаите траат многу часови, бидејќи сложената аналитика не може да се пресмета во милисекунди. Ние, како храбри момци, пишуваме код. Во апликацијата за вметнување го правиме снимањето на Master, и ги извршуваме извештаите на репликата.
- Распределба на товарот.
- Сè работи совршено. Ние сме супер.
И како изгледа оваа ситуација? Конкретно на овие графикони, го додадов и времетраењето на трансакциите од репликата за времетраењето на трансакцијата. Сите други графикони се однесуваат само на Master серверот.
Во тоа време, мојата табла за извештаи порасна. Ги има повеќе. Гледаме дека просечното време на одговор на серверот е стабилно. Гледаме дека на репликата имаме долготрајна трансакција која работи 2 часа. Ја гледаме тивката работа на автовакуумот, кој ги обработува мртвите линии. И кај нас се е во ред.
Поточно, според тестираната табличка, продолжуваме да ги ажурираме салдата на сметките таму. И ние исто така имаме стабилно време на одговор на барањата, стабилна потрошувачка на ресурси. Се е во ред со нас.
Сè е во ред до моментот кога овие извештаи ќе почнат да се враќаат поради конфликт со репликацијата. И тие пукаат во редовни интервали.
Одиме на интернет и почнуваме да читаме зошто се случува ова. И наоѓаме решение.
Првото решение е да се зголеми латентноста на репликацијата. Знаеме дека нашиот извештај трае 3 часа. Го поставивме доцнењето на репликацијата на 3 часа. Почнуваме сè, но сè уште имаме проблеми со понекогаш откажување на извештаите.
Сакаме се да биде совршено. Се искачуваме понатаму. И најдовме кул поставка на Интернет - hot_standby_feedback. Ајде да го вклучиме. Hot_standby_feedback ни овозможува да го задржиме автовакуумот на Master. Така, целосно се ослободуваме од конфликтите за репликација. И се работи добро кај нас со извештаи.
И што се случува со Master серверот во овој момент? И ние сме во целосна неволја со Master серверот. Сега ги гледаме графиконите кога ги имам овозможено и двете поставки. И гледаме дека сесијата на нашата реплика некако почна да влијае на ситуацијата на Master серверот. Таа навистина има ефект затоа што го паузираше автовакуумот, што ги отстранува крајните линии. Големината на нашата маса повторно вртоглаво порасна. Просечното време на извршување на барањето низ целата база на податоци исто така вртоглаво порасна. Автовакуумите малку се затегнаа.
Поточно, од нашата плоча, гледаме дека ажурирањето на податоците на неа исто така скокна на небо. Потрошувачката на процесорот на сличен начин значително се зголеми. Повторно поминуваме низ голем број мртви, бескорисни редови. И времето на одговор за овој знак и бројот на трансакции се намалени.
Како ќе изгледа ако не знаеме за што зборував порано?
- Почнуваме да бараме проблеми. Ако наидовме на проблеми во првиот дел, знаеме дека ова може да се должи на долга трансакција и отиде кај Мајсторот. Имаме проблем со мајсторот. Колбаси него. Се загрева, просечното оптоварување е околу сто.
- Барањата таму се бавни, но таму не гледаме никакви долгорочни трансакции. И не разбираме што е работата. Не разбираме каде да бараме.
- Ја проверуваме опремата на серверот. Можеби нашата рација падна. Можеби нашиот мемориски стик е изгорен. Да, се може да се случи. Но не, серверите се нови, се работи добро.
- Сите трчаат: администраторите, програмерите и директорот. Ништо не помага.
- И во одреден момент сè одеднаш почнува да се коригира.
Во тоа време, барањето на нашата реплика беше обработено и оставено. Го добивме извештајот. Бизнисот е сè уште среќен. Како што можете да видите, нашиот знак повторно порасна и нема да се намалува. На графиконот со сесии, оставив дел од оваа долга трансакција од реплика за да можете да процените колку време е потребно додека не се стабилизира ситуацијата.
Седницата заврши. И само по некое време серверот доаѓа повеќе или помалку во ред. И просечното време на одговор на барањата на Master серверот се враќа во нормала. Затоа што, конечно, автовакуумот има можност да ги исчисти и означи овие рокови. И тој почна да си ја врши работата. И колку брзо го прави тоа, толку брзо ќе се доведеме во ред.
Според тестираниот таблет, каде што ги ажурираме салдата на сметките, ја гледаме потполно истата слика. Просечното време за ажурирање на сметката исто така постепено се нормализира. Ресурсите што ги троши процесорот исто така се намалени. И бројот на трансакции во секунда се враќа во нормала. Но, повторно се вративме во нормала, не исто како што бевме пред несреќата.
Во секој случај, добиваме намалување на перформансите, како во првиот случај, за еден и пол до два пати, а понекогаш и повеќе.
Се чини дека направивме се како што треба. Дистрибуирајте го товарот. Опремата не е во мирување. Барањата ги поделивме според нашите умови, но сепак сè излезе лошо.
- Не овозможувате hot_standby_feedback? Да, не се препорачува да го вклучите без особено силни причини. Бидејќи овој пресврт директно влијае на Master серверот и ја суспендира работата на автовакуумот таму. Овозможувајќи го на некоја реплика и заборавајќи на тоа, можете да го убиете Мајсторот и да добиете големи проблеми со апликацијата.
- Да се зголеми max_standby_streaming_delay? Да, за извештаите ова е точно. Ако имате тричасовен извештај и не сакате да се сруши поради конфликти за репликација, тогаш едноставно зголемете го доцнењето. За долгорочен извештај никогаш не се потребни податоци што пристигнале во базата на податоци токму сега. Ако го имате три часа, тогаш го користите за некој стар период на податоци. И за вас, дали има три часа доцнење или доцнење од шест часа, нема да направи никаква разлика, но ќе добивате извештаи доследно и нема да имате никакви проблеми со нивното паѓање.
- Секако, треба да контролирате долги сесии на реплики, особено ако одлучите да овозможите hot_standby_feedback на реплика. Затоа што се може да се случи. Ја дадовме оваа реплика на развивачот за да може да ги тестира барањата. Тој напиша лудо барање. Тој го лансираше и отиде да пие чај, а ние го добивме воспоставениот мајстор. Или можеби сме ставиле погрешна апликација таму. Ситуациите се различни. Сесиите на репликите мора да се следат внимателно како и на Master.
- И ако имате брзи и долги прашања за реплики, тогаш во овој случај подобро е да ги поделите за да го дистрибуирате товарот. Ова е врска до streaming_delay. За брзите, имајте една реплика со мало доцнење на репликацијата. За долгорочни барања за известување, имајте реплика што може да заостанува за 6 часа или еден ден. Ова е сосема нормална ситуација.
Ние ги елиминираме последиците на ист начин:
- Наоѓаме надуени маси.
- И го компресираме со најзгодната алатка што ни одговара.
Втората приказна завршува тука. Да преминеме на третата приказна.
Исто така доста вообичаено за нас во кои правиме миграција.
- Секој софтверски производ расте. Барањата за тоа се менуваат. Во секој случај сакаме да се развиваме. И се случува да треба да ги ажурираме податоците во табелата, имено да извршиме ажурирање во однос на нашата миграција за новата функционалност што ја воведуваме како дел од нашиот развој.
- Стариот формат на податоци не е задоволителен. Да речеме, сега се свртиме кон втората табела, каде што имам трансакции на овие сметки. И да речеме дека тие беа во рубли, и решивме да ја зголемиме точноста и да го направиме тоа во копејки. И за ова треба да направиме ажурирање: помножете го полето со износот на трансакцијата за сто.
- Во денешниот свет користиме алатки за автоматизирана контрола на верзијата на базата на податоци. Да речеме . Таму ја регистрираме нашата миграција. Ние го тестираме на нашата тест база. Се е во ред. Ажурирањето е во тек. Ја блокира работата некое време, но добиваме ажурирани податоци. И можеме да лансираме нова функционалност на ова. Сè беше тестирано и проверено. Се беше потврдено.
- Извршивме планирана работа и извршивме миграција.
Еве ја миграцијата со ажурирањето претставено пред вас. Бидејќи ова се трансакции на мојата сметка, табличката беше 15 GB. И бидејќи ја ажурираме секоја линија, ја удвоивме големината на табелата со ажурирањето, бидејќи ја препишувавме секоја линија.
За време на миграцијата, не можевме да направиме ништо со оваа табличка, бидејќи сите барања до неа беа во редица и чекаа додека не заврши ова ажурирање. Но, овде сакам да ви го привлечам вниманието на бројките што се на вертикалната оска. Односно, имаме просечно време на барање пред миграција од околу 5 милисекунди и оптоварување на процесорот, бројот на блок операции за читање меморија на дискот е помал од 7,5.
Ја извршивме миграцијата и повторно добивме проблеми.
Миграцијата беше успешна, но:
- На старата функционалност сега е потребно подолго време за да се заврши.
- Табелата повторно порасна во големина.
- Оптоварувањето на серверот повторно стана поголемо од претходно.
- И, се разбира, сè уште ја чепкаме функционалноста која добро функционираше, малку ја подобривме.
И ова е повторно надуеност, што повторно ни ги уништува животите.
Овде покажувам дека табелата, како и претходните два случаи, нема да се врати во претходните големини. Се чини дека просечното оптоварување на серверот е соодветно.
И ако се свртиме кон табелата со сметки, ќе видиме дека просечното време на барање е двојно зголемено за оваа табела. Оптоварувањето на процесорот и бројот на линии подредени во меморијата скокна над 7,5, но беше помал. И скокна 2 пати во случај на процесори, 1,5 пати во случај на блок операции, односно добивме деградација на перформансите на серверот. И како резултат - деградација на перформансите на нашата апликација. Во исто време, бројот на повици остана приближно на исто ниво.
И главната работа овде е да се разбере како правилно да се прават такви миграции. И тие треба да се направат. Овие миграции ги правиме прилично конзистентно.
- Ваквите големи миграции не се случуваат автоматски. Тие секогаш мора да бидат под контрола.
- Потребен е надзор од упатено лице. Ако имате DBA во вашиот тим, тогаш оставете го DBA да го направи тоа. Тоа е негова работа. Ако не, тогаш тоа нека го направи најискусниот, кој знае да работи со бази на податоци.
- Нова шема на база на податоци, дури и ако ажурираме една колона, секогаш се подготвуваме во фази, односно однапред пред да се појави новата верзија на апликацијата:
- Се додаваат нови полиња во кои ќе ги евидентираме ажурираните податоци.
- Податоците од старото поле во новото поле ги пренесуваме во мали делови. Зошто го правиме ова? Прво, ние секогаш го контролираме процесот на овој процес. Знаеме дека веќе префрливме толку многу серии и ни останаа уште толку.
- И вториот позитивен ефект е тоа што помеѓу секоја таква серија ја затвораме трансакцијата, отвораме нова, а тоа му овозможува на автовакуумот да работи според плочата, да означува мртви линии за повторна употреба.
- За линиите што ќе се појават додека апликацијата работи (сè уште ја имаме старата апликација која работи), додаваме активирач што запишува нови вредности во нови полиња. Во нашиот случај, ова е множење со сто од старата вредност.
- Ако сме целосно тврдоглави и го сакаме истото поле, тогаш по завршувањето на сите миграции и пред да објавиме нова верзија на апликацијата, едноставно ги преименуваме полињата. На старите им се дава некое измислено име, а новите полиња се преименувани во стари.
- И само после тоа стартуваме нова верзија на апликацијата.
И во исто време нема да добиеме надуеност и нема да страдаме во однос на перформансите.
Тука завршува третата приказна.
И сега малку повеќе детали за алатките што ги спомнав во првата приказна.
Пред да пребарувате за bloat, мора да ја инсталирате екстензијата .
За да не морате да поставувате прашања, ние веќе ги напишавме овие прашања во нашата работа. Можете да ги користите. Тука има две барања.
- На првиот му треба доста време за да работи, но ќе ви ги покаже точните вредности на надуеност од табелата.
- Вториот делува побрзо и е многу ефикасен кога треба брзо да процените дали има надуеност или не според табелата. И, исто така, треба да разберете дека надуеноста е секогаш присутна во табелата на Postgres. Ова е карактеристика на неговиот модел MVCC.
- И 20% надуеност е нормално за маси во повеќето случаи. Тоа е, не треба да се грижите и да ја компресирате оваа табела.
Сфативме како да ги идентификуваме табелите што се отечени со бескорисни податоци.
Сега за тоа како да ја поправите надуеноста:
- Ако имаме мал таблет и добри дискови, односно на таблет до гигабајт, сосема е можно да користиме VACUUM FULL. Ќе ви земе ексклузивна брава на масата неколку секунди и во ред, но сè ќе направи брзо и грубо. Што прави VACUUM FULL? Потребно е ексклузивна брава на масата и препишува живи редови од старите табели во новата табела. И на крајот ги заменува. Ги брише старите датотеки и ги заменува старите со нови. Но, за времетраењето на неговата работа, потребно е ексклузивна брава на масата. Ова значи дека не можете да направите ништо со оваа табела: ниту пишувајте на неа, ниту читајте во неа, ниту менувајте ја. И VACUUM FULL бара дополнителен простор на дискот за запишување податоци.
- Следна алатка . Во својот принцип, тој е многу сличен на VACUUM FULL, бидејќи исто така ги препишува податоците од старите датотеки во нови и ги заменува во табелата. Но, во исто време, не зема ексклузивна брава на масата на самиот почеток на својата работа, туку ја зема само во моментот кога веќе има готови податоци за да ги замени датотеките. Неговите барања за ресурси на дискот се слични на оние на VACUUM FULL. Ви треба дополнителен простор на дискот, а тоа понекогаш е критично ако имате табели од терабајти. И доста е гладен за процесор бидејќи активно работи со I/O.
- Третата алатка е . Повнимателно е со ресурсите бидејќи работи според малку поинакви принципи. Главната идеја на pgcompacttable е тоа што ги преместува сите живи редови на почетокот на табелата користејќи ажурирања во табелата. И тогаш работи вакум на оваа табела, бидејќи знаеме дека имаме живи редови на почетокот и мртви редови на крајот. И самиот вакуум ја отсекува оваа опашка, односно не бара многу дополнителен простор на дискот. И во исто време, сè уште може да се притисне во однос на ресурсите.
Сè со алатки.
Ако ви е интересна темата за надуеност во смисла на навлегување понатаму внатре, еве неколку корисни врски:
- - Ова е извештај од мојот колега. Општо е за тоа каде оди просторот на Постгрес за време на неговата работа и живот. И има многу голем и детален технички дел за администраторите на базата на податоци за bloat.
- – ова е врска до нашето складиште, каде што складираме куп корисни скрипти за проверка на состојбата на базата на податоци. Таму можете да најдете скрипти за пребарување на bloat.
- и линкови до алатки кои ќе ви помогнат да ги намалите знаците.
- – ова е пост од мојот колега. Таму тој доста сериозно и технички детално го анализира bloat на ниво блиско до администраторите.
Се обидов повеќе да прикажам хорор приказна за програмерите, бидејќи тие се наши директни клиенти на бази на податоци и мора да разберат до што и до кои дејства водат. Се надевам дека успеав. Ви благодариме за вниманието!
прашања
Ви благодариме за извештајот! Зборувавте за тоа како можете да ги идентификувате проблемите. Како може да се предупредат? Односно, имав ситуација кога барањата висеа не само затоа што пристапуваа до некои надворешни услуги. Ова беа само некои диви спојувања. Имаше некои ситни, безопасни барања кои се вртеа наоколу еден ден, а потоа почнаа да прават глупости. Тоа е, многу слично на она што го опишуваш. Како да се следи ова? Седете и постојано гледајте кое барање е заглавено? Како може да се спречи ова?
Во овој случај, ова е задача за администраторите на вашата компанија, а не нужно за DBA.
Јас сум администратор.
PostgreSQL има приказ наречен pg_stat_activity кој покажува висат прашања. И можете да видите колку долго виси таму.
Дали треба да влегувам и да гледам на секои 5 минути?
Поставете cron и проверете. Ако имате долгорочно барање, напишете писмо и тоа е тоа. Односно, не треба да гледате со очи, може да се автоматизира. Ќе добиете писмо, вие реагирате на тоа. Или можете да снимате автоматски.
Дали има очигледни причини зошто тоа се случува?
Наведов некои. Други посложени примери. И може да има разговор долго време.
Ви благодариме за извештајот! Сакав да објаснам за алатката pg_repack. Доколку таа не направи ексклузивна брава, тогаш ...
Таа прави ексклузивна брава.
... тогаш потенцијално би можел да изгубам податоци. Дали мојата апликација не треба да снима ништо во ова време?
Не, непречено работи со табелата, т.е. pg_repack прво ги пренесува сите живи линии што постојат. Нормално, таму се случува некаков влез во табелата. Само ја исфрла оваа опашка.
Тоа е, тој всушност го прави тоа на крајот?
На крајот, тој зема ексклузивна брава за да ги замени овие датотеки.
Дали ќе биде побрзо од VACUUM FULL?
VACUUM FULL, штом почна, веднаш зеде ексклузивна брава. И додека не направи се, нема да ја пушти. И pg_repack зема ексклузивно заклучување само во моментот на замена на датотеката. Во овој момент нема да пишувате таму, но податоците нема да се изгубат, сè ќе биде во ред.
Здраво! Зборувавте за работата на вакуум за автомобил. Имаше графикон со црвени, жолти и зелени ќелии за снимање. Односно жолти - ги означи како избришани. И како резултат на тоа, може да се напише нешто ново во нив?
Да. Postgres не брише линии. Тој има таква специфичност. Ако ажуриравме линија, старата ја означивме како избришана. Таму се појавува ID на трансакцијата што ја смени оваа линија, а ние пишуваме нова линија. И имаме сесии кои потенцијално би можеле да ги прочитаат. Во одреден момент тие стануваат прилично стари. А суштината на тоа како функционира автовакуумот е тоа што поминува низ овие линии и ги означува како непотребни. И таму можете да ги презапишете податоците.
Разбирам. Но, прашањето не е за тоа. Не завршив. Да претпоставиме дека имаме маса. Има полиња со променлива големина. И ако се обидам да вметнам нешто ново, тоа може едноставно да не се вклопи во старата ќелија.
Не, во секој случај целата линија се ажурира таму. Postgres има два модели за складирање податоци. Се избира од типот на податоци. Има податоци кои се чуваат директно во табелата, а има и податоци за тос. Ова се големи количини на податоци: текст, json. Тие се чуваат во посебни чинии. И според овие таблети, се случува истата приказна со надуеност, т.е се е исто. Тие се само наведени одделно.
Ви благодариме за извештајот! Дали е прифатливо да се користат прашања за истекот на исказот за да се ограничи времетраењето?
Многу прифатливо. Ова го користиме насекаде. И бидејќи немаме свои услуги, обезбедуваме далечинска поддршка, имаме доста различни клиенти. И сите се целосно задоволни од ова. Односно, имаме cron jobs кои проверуваат. Времетраењето на сесиите едноставно се договара со клиентот, пред што не се согласуваме. Може да биде една минута, може да биде 10 минути. Тоа зависи од оптоварувањето на основата и неговата намена. Но, сите ние користиме pg_stat_activity.
Ви благодариме за извештајот! Се обидувам да го применам вашиот извештај на моите апликации. И се чини дека започнуваме трансакција насекаде, и јасно ја завршуваме насекаде. Ако има некој исклучок, тогаш сè уште се случува враќање назад. И тогаш почнав да размислувам. На крајот на краиштата, трансакцијата може да не започне експлицитно. Ова е веројатно навестување за девојката. Ако само ажурирам запис, дали трансакцијата ќе започне во PostgreSQL и ќе заврши само кога ќе се исклучи врската?
Ако сега зборувате за нивото на апликацијата, тогаш тоа зависи од двигателот што го користите, од ORM што се користи. Има многу поставки таму. Ако имате вклучено автоматско извршување, тогаш трансакцијата започнува таму и веднаш се затвора.
Односно се затвора веднаш по ажурирањето?
Тоа зависи од поставките. Именував една поставка. Ова е вклучено автоматско извршување. Тоа е доста вообичаено. Ако е овозможено, тогаш трансакцијата е отворена и затворена. Освен ако не сте кажале експлицитно „започни трансакција“ и „заврши трансакција“, туку едноставно подигнавте барање во сесијата.
Здраво! Ви благодариме за извештајот! Ајде да замислиме дека имаме база на податоци што отекува и отекува и тогаш просторот на серверот истекува. Дали има алатки за да се поправи оваа ситуација?
Просторот на серверот треба да се следи правилно.
На пример, DBA отиде на чај, беше во одморалиште итн.
Кога се креира датотечен систем, се создава барем некаков резервен простор каде што податоците не се напишани.
Што ако е целосно под нулата?
Таму се нарекува резервиран простор, односно може да се ослободи и во зависност од тоа колку е голем, добивате слободен простор. Стандардно не знам колку ги има. И во друг случај, испорачувајте дискови за да имате простор да извршите реконструктивна операција. Можете да избришете некоја табела за која се гарантира дека нема да ви треба.
Дали има други алатки?
Секогаш е рачно изработен. И локално станува јасно што е најдобро да се прави таму, бидејќи некои податоци се критични, а некои некритични. И за секоја база на податоци и апликацијата што работи со неа, зависи од бизнисот. Секогаш се одлучува локално.
Ви благодариме за извештајот! Имам две прашања. Прво, покажавте слајдови кои покажаа дека кога трансакциите се заглавени, и големината на просторот за маса и големината на индексот растат. И понатаму во извештајот имаше еден куп комунални услуги што го пакуваат таблетот. Што е со индексот?
И нив ги пакуваат.
Но, вакуумот не влијае на индексот?
Некои работат со индекс. На пример, pg_rapack, pgcompacttable. Вакуумот ги рекреира индексите и влијае на нив. Со VACUUM FULL идејата е да се презапише сè, т.е. работи со секого.
И второто прашање. Не разбирам зошто извештаите за реплики зависат толку од самата репликација. Ми се чинеше дека извештаите се читаат, а репликацијата е пишување.
Што предизвикува конфликт на репликација? Имаме мајстор на кој се одвиваат процесите. Имаме правосмукалка за автомобил. Што всушност прави автовакуумот? Тој отсекува некои стари линии. Ако во овој момент имаме барање на репликата што ги чита овие стари редови, а на мајсторот се појави ситуација дека автовакуумот ги означил овие редови како можни за препишување, тогаш ги препишувавме. И добивме пакет со податоци, кога треба повторно да ги запишеме оние линии што му се потребни на барањето на репликата, процесот на репликација ќе го чека истекот на времето што го конфигуриравте. И тогаш PostgreSQL ќе одлучи што му е поважно. И репликацијата му е поважна од барањето, и тој ќе го пука барањето за да ги направи овие промени на репликата.
Андреј, имам едно прашање. Овие прекрасни графикони што ги прикажавте за време на презентацијата, дали се ова резултат на работата на некоја ваша корист? Како се направени графиконите?
Ова е услуга .
Дали е ова комерцијален производ?
Да. Ова е комерцијален производ.
Извор: www.habr.com