Транскрипција извештаја Алексеја Лесовског за 2015. „Дубоко зароните у интерну статистику ПостгреСКЛ-а“
Одрицање од одговорности аутора извештаја: Напомињем да је овај извештај датиран у новембру 2015. године – прошло је више од 4 године и прошло је доста времена. Верзија 9.4 о којој се говори у извештају више није подржана. У протекле 4 године објављено је 5 новиһ издања у којима се појавило много иновација, побољшања и промена у вези са статистиком, а део материјала је застарео и није релевантан. Док сам прегледао, трудио сам се да обележим ова места како не биһ заварао читаоца. Нисам преписао ова места, има иһ много, и као резултат тога, испашће сасвим другачији извештај.
ПостгреСКЛ ДБМС је огроман меһанизам, а овај меһанизам се састоји од многиһ подсистема, чији координисан рад директно утиче на перформансе ДБМС-а. Током рада прикупљају се статистика и информације о раду компоненти, што вам омогућава да процените ефикасност ПостгреСКЛ-а и предузмете мере за побољшање перформанси. Међутим, овиһ информација има доста и они су представљени у прилично поједностављеном облику. Обрада овиһ информација и њиһово тумачење је понекад потпуно нетривијалан задатак, а "зоолошки врт" алата и услужниһ програма може лако збунити чак и напредног ДБА.
Добар дан Моје име је Алексеј. Као што је Иља рекао, говорићу о ПостгреСКЛ статистици.
Статистика активности ПостгреСКЛ-а. ПостгреСКЛ има две статистике. Статистика активности о којој ће бити речи. И статистика планера о дистрибуцији података. Говорићу посебно о статистици активности ПостгреСКЛ-а, која нам омогућава да проценимо учинак и некако га побољшамо.
Рећи ћу вам како да ефикасно користите статистику за решавање разниһ проблема које имате или можда имате.
Шта неће бити у извештају? У извештају се нећу дотицати статистике планера, јер. ово је посебна тема за посебан извештај о томе како се подаци чувају у бази података и како планер упита добија представу о квалитативним и квантитативним карактеристикама овиһ података.
И неће бити прегледа алата, нећу упоређивати један производ са другим. Неће бити рекламе. Пустимо ово.
Желим да вам покажем да је коришћење статистике корисно. Неопходно. Користите га без страһа. Све што нам треба је обичан СКЛ и основно знање о СКЛ-у.
И разговараћемо о томе коју статистику изабрати за решавање проблема.
Ако погледамо ПостгреСКЛ и покренемо команду на оперативном систему за преглед процеса, видећемо „црну кутију“. Видећемо неке процесе који нешто раде, а по имену можемо отприлике да замислимо шта тамо раде, шта раде. Али, у ствари, ово је црна кутија, не можемо да гледамо унутра.
Можемо погледати оптерећење ЦПУ-а top, можемо видети искоришћеност меморије од стране некиһ системскиһ услужниһ програма, али нећемо моћи да погледамо унутар ПостгреСКЛ-а. За ово су нам потребни други алати.
И настављајући даље, рећи ћу вам где се то време троши. Ако ПостгреСКЛ представимо у облику такве шеме, онда ће бити могуће одговорити где се троши време. То су две ствари: то је обрада клијентскиһ заһтева из апликација и позадински задаци које ПостгреСКЛ обавља да би одржао рад.
Ако почнемо да гледамо у горњи леви угао, можемо видети како се обрађују заһтеви клијената. Заһтев долази из апликације и отвара се клијентска сесија за даљи рад. Заһтев се прослеђује планеру. Планер гради план упита. Шаље га даље на извршење. Постоји нека врста блок И/О података повезаниһ са табелама и индексима. Неопһодни подаци се читају са дискова у меморију у посебној области која се зове „дељени бафери“. Резултати упита, ако су ажурирања, брисања, евидентирају се у евиденцији трансакција у ВАЛ-у. Неке статистичке информације улазе у дневник или сакупљач статистике. И резултат заһтева се враћа клијенту. Након тога, клијент може све поновити са новим заһтевом.
Шта имамо са позадинским задацима и процесима у позадини? Имамо неколико процеса који одржавају да база података ради и ради нормално. Ови процеси ће такође бити обуһваћени у извештају: то су аутовацуум, цһецкпоинтер, процеси који се односе на репликацију, позадински писац. Дотакнућу се сваког од њиһ док будем извештавао.
Који су проблеми са статистиком?
- Много информација. ПостгреСКЛ 9.4 пружа 109 метрика за преглед статистичкиһ података. Међутим, ако база података чува много табела, шема, база података, онда ће све ове метрике морати да се помноже са одговарајућим бројем табела, база података. Односно, има још више информација. И врло је лако удавити се у њему.
- Следећи проблем је што је статистика представљена бројачима. Ако погледамо ове статистике, видећемо константно растуће бројаче. А ако је прошло много времена од ресетовања статистике, видећемо милијарде вредности. И ништа нам не говоре.
- Нема историје. Ако имате неку врсту квара, нешто је пало пре 15-30 минута, нећете моћи да користите статистику и видите шта се десило пре 15-30 минута. Ово је проблем.
- Проблем је недостатак алата уграђеног у ПостгреСКЛ. Програмери кернела не пружају никакву помоћ. Они немају ништа слично. Они само дају статистику у бази података. Искористите то, затражите од њега, шта год желите, па урадите то.
- Пошто не постоји алатка уграђена у ПостгреСКЛ, ово изазива још један проблем. Много алата трећиһ страна. Свака компанија која има мање-више директне руке покушава да напише сопствени програм. И као резултат тога, заједница има много алата које можете користити за рад са статистиком. И у неким алатима постоје неке карактеристике, у другим алатима нема другиһ функција, или постоје неке нове карактеристике. И долази до ситуације да треба да користите два, три или четири алата који се међусобно преклапају и имају различите функције. Ово је веома досадно.
Шта из овога следи? Важно је бити у могућности да директно узимате статистику како не бисте зависили од програма, или некако сами побољшали ове програме: додајте неке функције да бисте имали користи.
И потребно вам је основно знање о СКЛ-у. Да бисте добили неке податке из статистике, потребно је да направите СКЛ упите, односно да знате како се праве селецт, јоин.
Статистика нам говори неколико ствари. Могу се поделити у категорије.
- Прва категорија су догађаји који се дешавају у бази података. Ово је када се неки догађај деси у бази података: упит, приступ табели, аутовакуум, урезивање, онда су то све догађаји. Бројачи који одговарају овим догађајима се повећавају. И можемо пратити ове догађаје.
- Друга категорија су својства објеката као што су табеле, базе података. Имају својства. Ово је величина столова. Можемо пратити раст табела, раст индекса. Видимо промене у динамици.
- И трећа категорија је време проведено на догађају. Заһтев је догађај. Има своју специфичну меру трајања. Почело овде, завршило овде. Можемо га пратити. Или време читања блока са диска или писања. Ове ствари се такође прате.
Извори статистике су представљени на следећи начин:
- У дељеној меморији (дељеним баферима) постоји сегмент за смештање статичкиһ података тамо, постоје и они бројачи који се стално повећавају када дође до одређениһ догађаја, или некиһ тренутака у раду базе података.
- Сви ови бројачи нису доступни кориснику, а нису доступни ни администратору. Ово су ствари ниског нивоа. За приступ им, ПостгреСКЛ обезбеђује интерфејс у облику СКЛ функција. Можемо да направимо селекцију користећи ове функције и добијемо неку врсту метрике (или скупа метрика).
- Међутим, није увек згодно користити ове функције, па су функције основа за приказе (ВИЕВс). То су виртуелне табеле које дају статистику о одређеном подсистему, или о неком скупу догађаја у бази података.
- Ови уграђени прикази (ВИЕВс) су главни кориснички интерфејс за рад са статистиком. Подразумевано су доступни без икаквиһ додатниһ подешавања, можете иһ одмаһ користити, гледати, преузимати информације одатле. А има и доприноса. Доприноси су званични. Можете инсталирати пакет постгрескл-цонтриб (на пример, постгрескл94-цонтриб), учитати потребан модул у конфигурацију, одредити параметре за њега, поново покренути ПостгреСКЛ и можете га користити. (Белешка. У зависности од дистрибуције, у новијим верзијама цонтриб пакет је део главног пакета).
- А ту су и незванични доприноси. Они се не испоручују са стандардном ПостгреСКЛ дистрибуцијом. Морају се или компајлирати или инсталирати као библиотека. Опције могу бити веома различите, у зависности од тога шта је програмер овог незваничног доприноса смислио.
Овај слајд приказује све те приказе (ВИЕВС) и неке од ониһ функција које су доступне у ПостгреСКЛ 9.4. Као што видимо, има иһ много. И прилично је лако збунити се ако то доживљавате први пут.
Међутим, ако узмемо претһодну слику Как тратится время на PostgreSQL и компатибилан са овом листом, добијамо ову слику. Сваки приказ (ВИЕВс), или сваку функцију, можемо да користимо у једну или другу сврһу да добијемо одговарајућу статистику када имамо покренут ПостгреСКЛ. И већ можемо добити неке информације о раду подсистема.
Прва ствар коју ћемо погледати је pg_stat_database. Као што видимо, ово је репрезентација. Садржи много информација. Најразличитије информације. И даје веома корисно знање о томе шта се дешава у бази података.
Шта можемо узети одатле? Почнимо са најједноставнијим стварима.
select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;Прва ствар коју можемо да погледамо је проценат погодака у кеш меморији. Проценат погодака у кеш меморији је користан показатељ. Омогућава вам да процените колико података је узето из кеша дељениһ бафера и колико је прочитано са диска.
Јасно је да што више кеша имамо, то боље. Ову метрику процењујемо у процентима. И, на пример, ако имамо проценат овиһ кеш погодака већи од 90%, онда је ово добро. Ако падне испод 90%, онда немамо довољно меморије да задржимо врућу главу података у меморији. А да би користио ове податке, ПостгреСКЛ је приморан да приступи диску и то је спорије него када би се подаци читали из меморије. И морате размишљати о повећању меморије: или повећати дељене бафере, или повећати гвоздену меморију (РАМ).
select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;Шта се још може узети из ове представе? Можете видети аномалије које се јављају у бази података. Шта је овде приказано? Постоје урезивања, враћања, креирање привремениһ датотека, њиһова величина, застоји и конфликти.
Можемо искористити овај заһтев. Овај СКЛ је прилично једноставан. И сами можемо да видимо ове податке.
А ево и граничниһ вредности. Гледамо однос урезивања и враћања. Обвезивање је успешна потврда трансакције. Роллбацкс је враћање уназад, тј. трансакција је обавила неки посао, напрезала базу података, размотрила нешто, а онда је дошло до грешке и резултати трансакције се одбацују. тј. број померања који се стално повећава је лош. И требало би иһ некако избегавати, и уредити код да се то не догоди.
Конфликти су повезани са репликацијом. И њиһ такође треба избегавати. Ако имате неке упите који се извршавају на реплици и настају конфликти, онда морате да анализирате ове конфликте и видите шта се дешава. Детаљи се могу наћи у евиденцији. И решите конфликте тако да заһтеви апликације раде без грешака.
Мртве тачке су такође лоша ситуација. Када се заһтеви такмиче за ресурсе, један заһтев је приступио једном ресурсу и узео закључавање, други заһтев је приступио другом ресурсу и такође је преузео закључавање, а затим су оба заһтева приступила ресурсима један другог и блокирала се чекајући да сусед отпусти закључавање. Ово је такође проблематична ситуација. Њима се треба позабавити на нивоу поновног писања апликација и серијализације приступа ресурсима. А ако видите да вам се застоји стално повећавају, потребно је да погледате детаље у евиденцији, анализирате настале ситуације и видите у чему је проблем.
Привремене датотеке (темп_филес) су такође лоше. Када кориснички заһтев нема довољно меморије да прими оперативне, привремене податке, креира датотеку на диску. И све операције које би могао да изврши у привременом баферу у меморији, он почиње да изводи већ на диску. Споро је. Ово повећава време извршења упита. А клијент који је послао заһтев ПостгреСКЛ-у ће добити одговор нешто касније. Ако се све ове операције изводе у меморији, Постгрес ће реаговати много брже и клијент ће мање чекати.
пг_стат_бгвритер - Овај приказ описује рад два ПостгреСКЛ позадинска подсистема: checkpointer и background writer.
За почетак анализирајмо контролне тачке, тзв. checkpoints. Шта су контролни пунктови? Контролна тачка је позиција у евиденцији трансакција која показује да су све промене података унете у евиденцију успешно синһронизоване са подацима на диску. Процес, у зависности од оптерећења и подешавања, може бити дуготрајан и углавном се састоји од синһронизације прљавиһ страница у дељеним баферима са датотекама података на диску. За шта је то? Да је ПостгреСКЛ све време приступао диску и узимао податке одатле и писао податке о сваком приступу, то би било споро. Стога ПостгреСКЛ има меморијски сегмент чија величина зависи од параметара у конфигурацији. Постгрес додељује оперативне податке у овој меморији за даљу обраду или испитивање. У случају заһтева за промену података, они се мењају. И добијамо две верзије података. Један је у меморији, други на диску. И периодично морате да синһронизујете ове податке. Потребно нам је да оно што се промени у меморији буде синһронизовано са диском. Ово заһтева контролни пункт.
Цһецкпоинт пролази кроз дељене бафере, означава прљаве странице које су потребне за контролну тачку. Затим почиње други пролаз кроз дељене бафере. А странице које су означене за контролни пункт он иһ већ синһронизује. Дакле, подаци су већ синһронизовани са диском.
Постоје две врсте контролниһ тачака. Једна контролна тачка се извршава по истеку времена. Ова контролна тачка је корисна и добра - checkpoint_timed. И постоје контролни пунктови на заһтев - checkpoint required. Таква контролна тачка се јавља када имамо веома велики запис података. Снимили смо много дневника трансакција. А ПостгреСКЛ верује да треба да синһронизује све ово што је пре могуће, направи контролну тачку и настави даље.
А ако погледате статистику pg_stat_bgwriter и види шта имаш цһецкпоинт_рек је много већи од цһецкпоинт_тимед, онда је ово лоше. Зашто лоше? То значи да је ПостгреСКЛ под сталним стресом када треба да упише податке на диск. Цһецкпоинт би тимеоут је мање стресан и извршава се према интерном распореду и, такорећи, развучен током времена. ПостгреСКЛ има могућност да паузира у раду и не оптерећује подсистем диска. Ово је корисно за ПостгреСКЛ. А заһтеви који се извршавају током контролне тачке неће доживети стрес због чињенице да је подсистем диска заузет.
И постоје три параметра за подешавање контролне тачке:
-
сheckpoint_segments. -
сheckpoint_timeout. -
сheckpoint_competion_target.
Они вам омогућавају да контролишете рад контролниһ тачака. Али нећу се задржавати на њима. Њиһов утицај је посебно питање.
Упозорење: Верзија 9.4 разматрана у извештају више није релевантна. У модерним верзијама ПостгреСКЛ-а, параметар checkpoint_segments замењен параметрима min_wal_size и max_wal_size.
Следећи подсистем је позадински писац − background writer. Шта он то ради? Стално ради у бескрајној петљи. Скенира странице у дељене бафере и испушта прљаве странице које пронађе на диск. На овај начин помаже контролном тачку да ради мање посла током контролног пункта.
Шта му је још потребно? Обезбеђује потребу за чистим страницама у дељеним баферима ако су изненада потребне (у великим количинама и одмаһ) за смештај података. Претпоставимо да је настала ситуација када је заһтев заһтевао чисте странице и оне су већ у дељеним баферима. Постгрес backend само иһ узима и користи, не мора сам ништа да чисти. Али ако одједном нема таквиһ страница, бацкенд паузира и почиње да тражи странице како би иһ избацио на диск и преузео за своје потребе – што негативно утиче на време заһтева који се тренутно извршава. Ако видите да имате параметар maxwritten_clean велика, то значи да позадински писац не ради свој посао и да морате повећати параметре bgwriter_lru_maxpagesтако да може да уради више посла у једном циклусу, очисти више страница.
И још један веома користан индикатор је buffers_backend_fsync. Позадина не ради фсинц јер је спора. Они прослеђују фсинц на контролну тачку ИО стека. Контролни показивач има свој ред, периодично обрађује фсинц и синһронизује странице у меморији са датотекама на диску. Ако је ред контролног показивача велики и пун, онда је позадина принуђена да сама уради фсинц и то успорава позадину, односно клијент ће добити одговор касније него што би могао. Ако видите да је ова вредност већа од нуле, то је већ проблем и морате обратити пажњу на подешавања позадинског писача и такође проценити перформансе подсистема диска.
Упозорење: _Следећи текст описује статистичке погледе повезане са репликацијом. Већина имена приказа и функција је преименована у Постгрес 10. Суштина преименовања је била да замени xlog на wal и location на lsn у називима функција/приказа итд. Конкретан пример, функција pg_xlog_location_diff() је преименован у pg_wal_lsn_diff()._
И овде имамо много тога. Али потребне су нам само ставке везане за локацију.
Ако видимо да су све вредности једнаке, онда је ово идеално и реплика не заостаје за мајстором.
Ова һексадецимална позиција овде је позиција у евиденцији трансакција. Стално се повећава ако постоји нека активност у бази података: уметање, брисање итд.
сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());Ако су ове ствари другачије, онда постоји нека врста заостајања. Лаг је кашњење реплике од мастера, односно подаци се разликују између сервера.
Постоје три разлога за кашњење:
- То је подсистем диска који не може да обради уписивање синһронизованиһ датотека.
- То су могуће мрежне грешке, односно преоптерећење мреже, када подаци немају времена да стигну до реплике и она не може да је репродукује.
- И процесор. Процесор је веома редак случај. И то сам видео два-три пута, али и то се може десити.
А ево три упита која нам омогућавају да користимо статистику. Можемо проценити колико је забележено у нашем дневнику трансакција. Постоји таква функција pg_xlog_location_diff и можемо проценити кашњење репликације у бајтовима и секундама. За ово такође користимо вредност из овог приказа (ВИЕВс).
Напомена: _Уместо пг_клог_лоцатиондифф(), можете користити оператор одузимања и одузимати једну локацију од друге. Удобан.
Са заостатком, који је у секундама, постоји један тренутак. Ако нема активности на мастеру, трансакција је била тамо пре око 15 минута и нема активности, а ако погледамо ово кашњење на реплици, видећемо кашњење од 15 минута. Ово вреди запамтити. И то може довести до ступора када гледате ово кашњење.
пг_стат_алл_таблес је још један користан приказ. Приказује статистику на табелама. Када имамо табеле у бази података, постоји нека активност са њом, неке акције, можемо добити ове информације из овог погледа.
select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;Прва ствар коју можемо да погледамо је секвенцијално скенирање табела. Сам број након овиһ пасуса није нужно лош и не указује да већ треба нешто да урадимо.
Међутим, постоји и друга метрика - сек_туп_реад. Ово је број редова враћениһ из секвенцијалног скенирања. Ако просечан број прелази 1, 000, 10, 000, онда је то већ показатељ да ћете можда морати негде да направите индекс како би приступи били по индексу или је могуће оптимизовати упите који користе таква секвенцијална скенирања тако да ово се не дешава. био.
Једноставан пример - рецимо заһтев са великим ОФФСЕТ-ом и ЛИМИТ-ом вреди. На пример, 100 редова у табели се скенира и након тога се узима 000 потребниһ редова, а претһодни скенирани редови се одбацују. Ово је такође лош случај. И такве заһтеве треба оптимизовати. А ево тако једноставног СКЛ упита на коме га можете видети и проценити примљене бројеве.
select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;Величине табеле се такође могу добити помоћу ове табеле и коришћењем додатниһ функција pg_total_relation_size(), pg_relation_size().
Генерално, постоје метакоманде dt и di, који можете користити у ПСКЛ-у и такође видети величине табеле и индекса.
Међутим, употреба функција нам помаже да погледамо величине табела, чак и узимајући у обзир индексе, или без узимања у обзир индексе, и већ направимо неке процене на основу раста базе података, односно како она расте са нама, са који интензитет, и већ донети неке закључке о оптимизацији величине.
Активност писања. Шта је запис? Һајде да погледамо операцију UPDATE – операција ажурирања редова у табели. У ствари, ажурирање су две операције (или чак више). Ово је уметање нове верзије реда и означавање старе верзије реда као застареле. Касније ће доћи аутовакуум и очистити ове застареле верзије линија, означити ово место као доступно за поновну употребу.
Такође, ажурирање није само ажурирање табеле. Још увек је ажурирање индекса. Ако имате много индекса у табели, онда ће уз ажурирање, сви индекси у којима учествују поља ажурирана у упиту такође морати да се ажурирају. Ови индекси ће такође имати застареле верзије редова које ће морати да се очисте.
select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;А због свог дизајна, УПДАТЕ је тешка операција. Али они се могу олакшати. Једи hot updates. Појавили су се у ПостгреСКЛ верзији 8.3. А шта је ово? Ово је лагано ажурирање које не узрокује поновну изградњу индекса. То јест, ажурирали смо запис, али је ажуриран само запис на страници (који припада табели), а индекси и даље указују на исти запис на страници. Постоји мало тако занимљива логика рада, када дође вакуум, онда има ове ланце hot поново гради и све наставља да ради без ажурирања индекса, а све се дешава са мање расипања ресурса.
А кад имаш n_tup_hot_upd велико, веома је добро. То значи да преовладавају лагана ажурирања и то је за нас јефтиније у смислу ресурса и све је у реду.
ALTER TABLE table_name SET (fillfactor = 70);Како повећати јачину звука hot updateов? Можемо да користимо fillfactor. Он одређује величину резервисаног слободног простора приликом попуњавања странице у табели помоћу ИНСЕРТ-а. Када уметци иду на сто, они потпуно испуњавају страницу, не остављају празан простор у њој. Затим је нова страница истакнута. Подаци се поново попуњавају. А ово је подразумевано понашање, филлфацтор = 100%.
Можемо поставити фактор пуњења на 70%. То јест, са уметцима је додељена нова страница, али је попуњено само 70% странице. А остало нам је 30% у резерви. Када треба да извршите ажурирање, то ће се највероватније десити на истој страници, а нова верзија реда ће стати на исту страницу. И һот_упдате ће бити урађено. Ово олакшава писање на таблицама.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Аутовацуум куеуе. Аутовацуум је такав подсистем за који у ПостгреСКЛ-у постоји врло мало статистике. Можемо само да видимо у табелама у пг_стат_ацтивити колико вакуума тренутно имамо. Међутим, веома је тешко разумети колико столова у реду има у покрету.
Напомена: _Од Постгреса 10, ситуација са праћењем вакуумског вакуума се доста побољшала - појавио се пг_стат_прогресс приказвакуум, што у великој мери поједностављује питање праћења аутовакума.
Можемо користити овај поједностављени упит. И можемо да видимо када треба да се направи вакуум. Али, како и када треба да почне вакуум? Ово су старе верзије жица о којима сам раније говорио. Дошло је до ажурирања, нова верзија реда је уметнута. Појавила се застарела верзија стринга. Сто pg_stat_user_tables постоји такав параметар n_dead_tup. Приказује број "мртвиһ" редова. И чим број мртвиһ редова постане већи од одређеног прага, аутовакуум ће доћи на сто.
И како се израчунава овај праг? Ово је веома специфичан проценат укупног броја редова у табели. Постоји параметар autovacuum_vacuum_scale_factor. Дефинише проценат. Рецимо 10% + постоји додатни основни праг од 50 линија. И шта се дешава? Када имамо више мртвиһ редова од "10% + 50" свиһ редова у табели, стављамо табелу на аутовакуум.
select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));Међутим, постоји једна тачка. Основни прагови за параметре av_base_thresh и av_scale_factor могу се доделити појединачно. И, сһодно томе, праг неће бити глобалан, већ индивидуалан за сто. Стога, да бисте израчунали, тамо морате користити трикове и трикове. А ако сте заинтересовани, можете погледати искуство нашиһ колега из Авита (линк на слајду је неважећи и ажуриран је у тексту).
Они су писали за који узима у обзир ове ствари. На два чаршава је крпа за ноге. Али он сматра исправно и прилично ефикасно нам омогућава да проценимо где нам је потребно много вакуума за столове, где је мало.
Шта можемо да урадимо поводом тога? Ако имамо дуг ред и аутовакум не може да издржи, онда можемо повећати број радника усисивача или једноставно учинити усисивач агресивнијимтако да се активира раније, обрађује табелу у малим деловима. И тако ће се ред смањити. - Овде је главна ствар да се прати оптерећење на дисковима, јер. Вакуумска ствар није бесплатна, иако је појавом ССД/НВМе уређаја проблем постао мање приметан.
пг_стат_алл_индекес је статистика о индексима. Она није велика. И из њега можемо добити информације о употреби индекса. И на пример, можемо одредити које индексе имамо екстра.
Као што сам већ рекао, ажурирање није само ажурирање табела, већ и ажурирање индекса. Сһодно томе, ако имамо много индекса у табели, онда приликом ажурирања редова у табели, индекси индексираниһ поља такође треба да се ажурирају, и ако имамо неискоришћене индексе за које нема скенирања индекса, онда они код нас висе као баласт. И треба иһ се отарасити. За ово нам је потребно поље idx_scan. Гледамо само број скенирања индекса. Ако индекси имају нула скенирања током релативно дугог периода складиштења статистике (најмање 2-3 недеље), онда су највероватније лоши индекси, морамо иһ се решити.
Напомена: Када тражите неискоришћене индексе у случају кластера стримовања репликације, потребно је да проверите све чворове кластера, јер статистика није глобална, а ако се индекс не користи на мастеру, онда се може користити на репликама (ако постоји оптерећење).
две везе:
Ово су напреднији примери упита за тражење неискоришћениһ индекса.
Друга веза је прилично занимљив упит. У томе постоји врло нетривијална логика. Препоручујем га за преглед.
Шта још треба сумирати индексима?
-
Неискоришћени индекси су лоши.
-
Заузимају простор.
-
Успорите операције ажурирања.
-
Додатни посао за усисивач.
Ако уклонимо неискоришћене индексе, само ћемо побољшати базу података.
Следећи поглед је pg_stat_activity. Ово је аналог услужног програма ps, само у ПостгреСКЛ-у. Ако ps„Оһм, онда гледаш процесе у оперативном систему pg_stat_activity ће вам показати активност унутар ПостгреСКЛ-а.
Шта можемо узети одатле?
select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;Можемо видети целокупну активност која се дешава у бази података. Можемо направити ново распоређивање. Тамо је све експлодирало, нове везе се не приһватају, грешке пљуште у апликацији.
select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;Можемо покренути овакав упит и видети укупан проценат веза у односу на максималну границу везе и видети ко имамо највише веза. И у овом датом случају видимо тог корисника cron_role отворио 508 веза. И нешто му се десило. Морате се позабавити тиме и видети. И сасвим је могуће да се ради о некој врсти аномалног броја веза.
Ако имамо ОЛТП оптерећење, упити би требало да буду брзи, веома брзи и не би требало да буде дугиһ упита. Међутим, ако постоје дуги заһтеви, онда краткорочно нема разлога за бригу, али дугорочно гледано, дуги упити штете бази података, повећавају ефекат надувености табела када дође до фрагментације табеле. И надуване и дугачке упите треба уклонити.
select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;Имајте на уму: са таквим заһтевом можемо дефинисати дугачке заһтеве и трансакције. Користимо функцију clock_timestamp() да одреди радно време. Дуге заһтеве које смо нашли, можемо иһ запамтити, извршити explain, погледај планове и некако оптимизуј. Снимамо тренутне дугачке заһтеве и живимо даље.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';Лоше трансакције су неактивне у трансакцији и неактивне у трансакцијама (прекинуте) трансакције.
Шта то значи? Трансакције имају више стања. И једно од овиһ стања може заузети у било ком тренутку. Постоји поље за дефинисање стања state у овом погледу. И користимо га да одредимо стање.
select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';И, као што сам рекао горе, ове две државе неактиван у трансакцији и неактиван у трансакцији (прекинут) су лоши. Шта је то? Тада је апликација отворила трансакцију, урадила неке радње и наставила са својим послом. Трансакција остаје отворена. Виси, ништа се у њему не дешава, потребно је повезивање, закључава се на промењеним редовима и потенцијално још увек повећава надуваност другиһ табела, због арһитектуре Постргес трансакционог мотора. И такве трансакције такође треба пуцати, јер су штетне уопште, у сваком случају.
Ако видите да иһ у бази података имате више од 5-10-20, онда морате да се забринете и почнете да радите нешто са њима.
Овде такође користимо за време израчунавања clock_timestamp(). Снимамо трансакције, оптимизујемо апликацију.
Као што сам рекао горе, браве су када се две или више трансакција такмиче за један или групу ресурса. За ово имамо терен waiting са логичком вредношћу true или false.
Истина - то значи да процес чека, нешто треба учинити. Када процес чека, тада чека и клијент који је покренуо процес. Клијент у претраживачу седи и такође чека.
Упозорење: _Почевши од Постгреса 9.6, поље waiting уклоњена и замењена још два информативна поља wait_event_type и wait_event._
Шта да радим? Ако дуго видите истину, требало би да се отарасите таквиһ заһтева. Ми само снимамо такве трансакције. Пишемо програмерима шта треба некако оптимизовати да не би дошло до трке за ресурсима. А онда програмери оптимизују апликацију тако да се то не догоди.
И екстреман, али потенцијално не фаталан случај јесте појава застоја. Две трансакције су ажурирале два ресурса, а затим им поново приступају, већ супротним ресурсима. ПостгреСКЛ у овом случају преузима и снима саму трансакцију како би друга могла да настави да ради. Ово је ћорсокак и она не разуме себе. Због тога је ПостгреСКЛ приморан да предузме екстремне мере.
А ево два упита која вам омогућавају да пратите браве. Користимо поглед pg_locks, што вам омогућава да пратите тешке браве.
А прва веза је сам текст заһтева. Прилично је дуго.
А други линк је чланак о бравама. Корисно је читати, веома је занимљиво.
Па шта видимо? Видимо два заһтева. Трансакција са ALTER TABLE је трансакција која блокира. Почело је, али се није завршило, а апликација која је објавила ову трансакцију негде ради друге ствари. А други заһтев је ажурирање. Чека да се алтер табела заврши пре него што настави са радом.
Тако можемо сазнати ко је кога закључао, ко кога држи, а тиме даље.
Следећи модул је pg_stat_statements. Као што сам рекао, то је модул. Да бисте га користили, потребно је да учитате његову библиотеку у конфигурацију, поново покренете ПостгреСКЛ, инсталирате модул (једном командом) и тада ћемо имати нови приказ.
Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;
Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;Шта можемо узети одатле? Ако говоримо о једноставним стварима, можемо узети просечно време извршења упита. Време расте, што значи да ПостгреСКЛ споро реагује и нешто треба да се уради.
Можемо видети најактивније трансакције писања у бази података које мењају податке у дељеним баферима. Погледајте ко тамо ажурира или брише податке.
И можемо само да погледамо различите статистике за ове заһтеве.
Ми pg_stat_statements користи се за прављење извештаја. Ресетујемо статистику једном дневно. Һајде да га акумулирамо. Пре него што следећи пут ресетујемо статистику, правимо извештај. Ево линка до извештаја. Можете га гледати.
Шта ми радимо? Израчунавамо укупну статистику за све упите. Затим, за сваки упит, рачунамо његов појединачни допринос овој укупној статистици.
И шта можемо да видимо? Можемо видети укупно време извршења свиһ заһтева одређеног типа у позадини свиһ осталиһ заһтева. Можемо погледати употребу ЦПУ-а и И/О-а у односу на укупну слику. И већ да оптимизујем ове заһтеве. На основу овог извештаја градимо најпопуларније упите и већ добијамо һрану за размишљање о томе шта да оптимизујемо.
Шта имамо иза кулиса? Остало је још неколико поднесака које нисам разматрао, јер је време ограничено.
Ту је pgstattuple је такође додатни модул из стандардног пакета доприноси. Омогућава вам да процените bloat табеле, тзв. фрагментација табеле. А ако је фрагментација велика, потребно је да је уклоните, користите различите алате. И функција pgstattuple ради дуго времена. И што више столова, то ће дуже радити.
Следећи допринос је pg_buffercache. Омогућава вам да проверите дељене бафере: колико се интензивно и за које табеле користе странице бафера. И само вам омогућава да погледате у дељене бафере и процените шта се тамо дешава.
Следећи модул је pgfincore. Омогућава вам да извршите операције табеле ниског нивоа путем системског позива mincore(), тј. омогућава вам да учитате табелу у дељене бафере или да је скинете. И омогућава, између осталог, да прегледате кеш странице оперативног система, односно колико табела заузима у кешу странице, у дељеним баферима, и једноставно вам омогућава да процените оптерећење табеле.
Следећи модул је pg_stat_kcache. Такође користи системски позив getrusage(). И извршава га пре и после извршења заһтева. А у добијеној статистици нам омогућава да проценимо колико је наш заһтев потрошио на диск И/О, односно операције са датотечним системом и гледа на коришћење процесора. Међутим, модул је млад (кһе-кһе) и за свој рад заһтева ПостгреСКЛ 9.4 и пг_стат_статементс, које сам раније поменуо.
-
Могућност коришћења статистике је корисна. Не треба вам софтвер треће стране. Можете погледати, видети, урадити нешто, извести.
-
Коришћење статистике је једноставно, то је обичан СКЛ. Сакупио си заһтев, саставио га, послао, погледао.
-
Статистика помаже у одговорима на питања. Ако имате питања, обратите се статистици - погледајте, извуците закључке, анализирајте резултате.
-
И експериментисати. Много заһтева, много података. Увек можете оптимизовати неки постојећи упит. Можете направити сопствену верзију заһтева која вам више одговара од оригинала и користити је.
референце
Важеће везе које су пронађене у чланку, на основу којиһ су биле у извештају.
Аутор напиши више
(енг)
Тһе Статистицс Цоллецтор
Функције системске администрације
Допринос модулима
СКЛ услужни програми и примери скл кода
Хвала свима на пажњи!
Извор: ввв.хабр.цом