🥇PostgreSQL ички статистикасына терең сүңгүңүз. Алексей Лесовский

Алексей Лесовскийдин 2015-жылдагы отчетунун транскрипциясы "PostgreSQL ички статистикасына терең секирүү"

Баяндаманын авторунан баш тартуу: Бул отчет 2015-жылдын ноябрында экенин белгилейм – 4 жылдан ашык убакыт өттү жана көп убакыт өттү. Отчетто талкууланган 9.4 версиясы колдоого алынбайт. Акыркы 4 жылдын ичинде 5 жаңы релиз чыкты, анда статистикага байланыштуу көптөгөн инновациялар, жакшыртуулар жана өзгөртүүлөр пайда болду, ал эми кээ бир материалдар эскирген жана актуалдуу эмес. Мен карап отуруп, окурманды адаштырбоо үчүн бул жерлерди белгилөөгө аракет кылдым. Мен бул жерлерди кайра жазган жокмун, алар абдан көп, натыйжада такыр башка отчет чыгат.

PostgreSQL DBMS чоң механизм болуп саналат жана бул механизм көптөгөн подсистемалардан турат, алардын макулдашылган иши СУБДдун иштешине түздөн-түз таасирин тийгизет. Иштөө учурунда статистикалык маалыматтар жана компоненттердин иштеши жөнүндө маалымат чогултулат, бул PostgreSQLдин эффективдүүлүгүн баалоого жана натыйжалуулукту жакшыртуу боюнча чараларды көрүүгө мүмкүндүк берет. Бирок, бул маалымат көп жана ал бир топ жөнөкөйлөтүлгөн түрдө берилген. Бул маалыматты иштеп чыгуу жана аны интерпретациялоо кээде таптакыр тривиалдуу эмес иш болуп саналат, ал эми инструменттер менен коммуналдык кызматтардын "зоопарктары" өнүккөн DBAны оңой эле чаташтырат.

Кутмандуу күнүң менен! Менин атым Алексей. Илья айткандай, мен PostgreSQL статистикасы жөнүндө сүйлөшөм.

PostgreSQL аракетинин статистикасы. PostgreSQLде эки статистика бар. Аракет статистикасы, алар талкууланат. Жана маалыматтарды бөлүштүрүү жөнүндө пландоочу статистика. Мен PostgreSQL ишинин статистикасы жөнүндө атайын сүйлөшөм, ал бизге иштин натыйжалуулугун баалоого жана аны кандайдыр бир жол менен жакшыртууга мүмкүндүк берет.

Мен сизге статистиканы сизде бар же болушу мүмкүн болгон ар кандай көйгөйлөрдү чечүү үчүн кантип натыйжалуу колдонуу керектигин айтып берем.

Отчетто эмне болбойт? Докладда мен пландоочу-нун статистикасына токтолбойм, анткени. бул маалымат базасында маалыматтар кантип сакталат жана суроону пландаштыруучу бул маалыматтардын сапаттык жана сандык мүнөздөмөлөрү жөнүндө кандай түшүнүк алаары жөнүндө өзүнчө баяндама үчүн өзүнчө тема.

Жана эч кандай курал боюнча сын-пикирлер болбойт, мен бир продуктуну экинчиси менен салыштырбайм. Эч кандай жарнама болбойт. Аны таштайлы.

Мен статистиканы колдонуу пайдалуу экенин көрсөткүм келет. Бул керек. Коркпостон колдонуңуз. Бизге жөнөкөй SQL жана SQL боюнча негизги билим керек.

Ал эми көйгөйлөрдү чечүү үчүн кайсы статистиканы тандоо керектиги жөнүндө сүйлөшөбүз.

Эгерде PostgreSQLди карап, процесстерди көрүү үчүн операциялык системада буйрукту иштетсек, анда биз "кара кутучаны" көрөбүз. Биз бир нерсе кылган кээ бир процесстерди көрөбүз жана аты менен алар ал жерде эмне кылып жатканын, эмне кылып жатканын болжол менен элестете алабыз. Бирок, чынында, бул кара куту, биз анын ичин карай албайбыз.

Биз CPU жүгүн карай алабыз top, биз кээ бир тутум утилиталары тарабынан эстутумдун колдонулушун көрө алабыз, бирок PostgreSQLдин ичин карай албайбыз. Бул үчүн бизге башка куралдар керек.

Андан ары улантып, мен сизге убакыттын кайда кеткенин айтып берем. Эгерде биз PostgreSQLди ушундай схема түрүндө көрсөтсөк, анда убакыт кайда кеткенине жооп берүүгө болот. Бул эки нерсе: бул тиркемелерден келген кардарлардын суроо-талаптарын иштеп чыгуу жана PostgreSQL анын иштеши үчүн аткарган фондо тапшырмалар.

Эгерде биз жогорку сол бурчка карай баштай турган болсок, кардарлардын суроо-талаптары кандайча иштетилип жатканын көрө алабыз. Сурам колдонмодон келет жана андан аркы иш үчүн кардар сессиясы ачылат. Сурам пландоочуга берилет. Пландоочу суроо планын түзөт. Андан ары аткарууга жөнөтөт. Таблицалар жана индекстер менен байланышкан I/O маалыматтарынын кандайдыр бир түрү бар. Керектүү маалыматтар дисктерден эстутумга "бөлүштүрүлгөн буферлер" деп аталган атайын аймакта окулат. Сурамдын натыйжалары, эгерде алар жаңыртылса, жок кылса, WALдагы транзакциялар журналына жазылат. Кээ бир статистикалык маалымат журналга же статистикалык жыйноочуга кирет. Ал эми суроо-талаптын жыйынтыгы кардарга кайра берилет. Андан кийин, кардар жаңы өтүнүч менен баарын кайталай алат.

Фондук тапшырмалар жана фон процесстери менен бизде эмне бар? Бизде маалымат базасынын иштешин жана нормалдуу иштешин камсыз кылган бир нече процесстер бар. Бул процесстер отчетто да каралат: бул автовакуум, текшерүүчү, репликацияга байланыштуу процесстер, фондо жазгыч. Мен алардын ар бирине отчёт берип жатып токтолом.

Статистикада кандай көйгөйлөр бар?

Маалымат көп. PostgreSQL 9.4 статистикалык маалыматтарды көрүү үчүн 109 метрика менен камсыз кылат. Бирок, эгерде маалымат базасында көптөгөн таблицалар, схемалар, маалымат базалары сакталса, анда бул көрсөткүчтөрдүн бардыгын тиешелүү таблицалардын, маалымат базаларынын санына көбөйтүү керек болот. Башкача айтканда, андан да көп маалымат бар. Анан ага чөгүп кетүү абдан оңой.
Кийинки көйгөй - статистика эсептегичтер менен көрсөтүлөт. Бул статистиканы карасак, эсептегичтердин тынымсыз өсүп жатканын көрөбүз. Ал эми статистика кайра коюлгандан бери көп убакыт өтсө, биз миллиарддаган баалуулуктарды көрөбүз. Анан алар бизге эч нерсе айтышпайт.
Тарых жок. Эгер кандайдыр бир ийгиликсиздик болсо, 15-30 мүнөт мурун бир нерсе түшүп кетсе, статистиканы колдоно албайсыз жана 15-30 мүнөт мурун эмне болгонун көрө албайсыз. Бул көйгөй.
PostgreSQLге орнотулган куралдын жоктугу көйгөй болуп саналат. Ядро иштеп чыгуучулар эч кандай утилитаны камсыз кылбайт. Аларда андай нерсе жок. Болгону маалымат базасында статистиканы беришет. Аны колдонуңуз, ага суранычыңызды жазыңыз, каалаган нерсеңизди аткарыңыз.
PostgreSQLде эч кандай курал жок болгондуктан, бул дагы бир көйгөйдү жаратат. Көптөгөн үчүнчү тараптын куралдары. Аздыр-көптүр түз колу бар ар бир компания өзүнүн программасын жазууга аракет кылып жатат. Натыйжада, коомчулукта статистика менен иштөө үчүн колдоно турган көптөгөн куралдар бар. Ал эми кээ бир инструменттерде кээ бир өзгөчөлүктөр бар, башка куралдарда башка мүмкүнчүлүктөр жок же жаңы мүмкүнчүлүктөр бар. Ал эми бири-бирин кайталаган жана ар кандай функцияларга ээ болгон эки, үч же төрт куралды колдонуу керек деген жагдай келип чыгат. Бул абдан тажатма.

Мындан эмне чыгат? Программалардан көз каранды болбоо үчүн же кандайдыр бир жол менен бул программаларды өзүңүз өркүндөтпөө үчүн статистиканы түз ала билүү маанилүү: пайдаңызды алуу үчүн кээ бир функцияларды кошуңуз.

Жана сизге SQL боюнча негизги билим керек. Статистикадан кээ бир маалыматтарды алуу үчүн, сиз SQL сурамдарын жасашыңыз керек, б.а. тандоо, кошулуу кантип жасалганын билишиңиз керек.

Статистика бизге бир нече нерсени айтып берет. Аларды категорияларга бөлүүгө болот.

Биринчи категория маалымат базасында болуп жаткан окуялар. Бул маалымат базасында кандайдыр бир окуя болгондо болот: суроо-талап, таблицага кирүү, автовакуум, милдеттенмелер, анда булардын бардыгы окуялар. Бул окуяларга тиешелүү эсептегичтер көбөйөт. Жана биз бул окуяларды байкай алабыз.
Экинчи категория - таблицалар жана маалымат базалары сыяктуу объекттердин касиеттери. Алардын касиеттери бар. Бул үстөлдөрдүн өлчөмү. Биз таблицалардын өсүшүн жана индекстердин өсүшүн байкай алабыз. Динамикадагы өзгөрүүлөрдү көрө алабыз.
Ал эми үчүнчү категория - бул иш-чарага кеткен убакыт. Сурам - бул окуя. Анын узактыгынын өзүнүн өзгөчө ченеми бар. Ушул жерден башталды, ушул жерден бүттү. Биз аны көзөмөлдөй алабыз. Же дисктен блокту окуу же жазуу убактысы. Бул нерселер да көзөмөлдөнөт.

Статистиканын булактары төмөндөгүдөй көрсөтүлөт:

Бөлүштүрүлгөн эс тутумда (бөлүштүрүлгөн буферлерде) ал жерде статикалык маалыматтарды жайгаштыруу үчүн сегмент бар, ошондой эле белгилүү бир окуялар болгондо же маалымат базасынын иштешинде кээ бир учурлар пайда болгондо дайыма көбөйүп турган эсептегичтер бар.
Бул эсептегичтердин баары колдонуучуга жеткиликтүү эмес жана администратор үчүн да жеткиликтүү эмес. Булар төмөн деңгээлдеги нерселер. Аларга жетүү үчүн PostgreSQL SQL функциялары түрүндөгү интерфейсти камсыз кылат. Бул функциялардын жардамы менен биз тандалган тандоолорду жасап, кандайдыр бир метрика (же метрика топтомун) ала алабыз.
Бирок, бул функцияларды колдонуу дайыма эле ыңгайлуу боло бербейт, ошондуктан функциялар көрүнүштөр үчүн негиз болуп саналат (КӨРҮНҮҮ). Бул белгилүү бир подсистема боюнча же маалымат базасындагы окуялардын белгилүү бир топтому боюнча статистиканы камсыз кылган виртуалдык таблицалар.
Бул орнотулган көрүнүштөр (КӨРҮНҮҮ) статистика менен иштөө үчүн негизги колдонуучу интерфейси болуп саналат. Алар демейки боюнча эч кандай кошумча жөндөөлөрсүз жеткиликтүү, аларды дароо колдонуп, көрүп, ошол жерден маалымат ала аласыз. Жана дагы салымдары бар. Салымдар расмий болуп саналат. Сиз postgresql-contrib пакетин орното аласыз (мисалы, postgresql94-contrib), конфигурацияга керектүү модулду жүктөй аласыз, ал үчүн параметрлерди көрсөтүп, PostgreSQLди кайра иштетип, аны колдоно аласыз. (Эскертүү. Бөлүштүрүүгө жараша, пакеттин акыркы версияларында пакет негизги пакеттин бир бөлүгү болуп саналат).
Ал эми расмий эмес салымдар бар. Алар стандарттуу PostgreSQL бөлүштүрүү менен камсыз кылынбайт. Аларды компиляциялоо же китепкана катары орнотуу керек. Параметрлер бул бейрасмий салымды иштеп чыгуучу ойлоп тапкан нерсеге жараша абдан ар түрдүү болушу мүмкүн.

Бул слайдда PostgreSQL 9.4'те жеткиликтүү болгон бардык көрүнүштөр (КӨРҮНҮҮЛӨР) жана айрым функциялар көрсөтүлгөн. Биз көрүп тургандай, алардын саны көп. Жана эгер сиз муну биринчи жолу көрүп жатсаңыз, чаташтыруу оңой.

Бирок, мурунку сүрөттү алсак Как тратится время на PostgreSQL жана бул тизме менен шайкеш, биз бул сүрөттү алабыз. Бизде PostgreSQL иштеп турганда, ар бир көрүнүш (көз караштар) же ар бир функция, тиешелүү статистиканы алуу үчүн тигил же бул максатта колдоно алабыз. Ал эми биз подсистеманын иштеши жөнүндө бир аз маалымат ала алабыз.

Биз карап чыга турган биринчи нерсе pg_stat_database. Көрүнүп тургандай, бул өкүлчүлүк. Анда көп маалымат камтылган. Эң түрдүү маалымат. Жана бул маалымат базасында эмне болуп жаткандыгы жөнүндө абдан пайдалуу билим берет.

Ал жерден эмнени алсак болот? Эң жөнөкөй нерселерден баштайлы.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Биз карап турган биринчи нерсе - кэштин хит пайызы. Кэшти утуу пайызы пайдалуу көрсөткүч болуп саналат. Бул жалпы буферлердин кэшинен канча маалымат алынганын жана дисктен канчасы окула тургандыгын баалоого мүмкүндүк берет.

Бул түшүнүктүү бизде кэш канчалык көп болсо, ошончолук жакшы. Биз бул көрсөткүчтү пайыз катары баалайбыз. Ал эми, мисалы, бизде бул кэш хиттеринин пайызы 90% дан жогору болсо, анда бул жакшы. Эгерде ал 90% дан төмөн түшүп кетсе, анда бизде маалыматтардын ысык башын эс тутумда сактоо үчүн жетиштүү эстутум жок. Жана бул маалыматтарды колдонуу үчүн, PostgreSQL дискке кирүүгө аргасыз болот жана бул маалыматтар эстутумдан окулганга караганда жайыраак. Жана сиз эстутумду көбөйтүү жөнүндө ойлонушуңуз керек: же жалпы буферлерди көбөйтүңүз, же темир эс тутумун (RAM) көбөйтүңүз.

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;

Бул спектаклден дагы эмнелерди алууга болот? Сиз маалымат базасында болуп жаткан аномалияларды көрө аласыз. Бул жерде эмне көрсөтүлгөн? Милдеттенмелер, артка кайтуулар, убактылуу файлдарды түзүү, алардын өлчөмү, туюктар жана чыр-чатактар бар.

Биз бул өтүнүчтү колдоно алабыз. Бул SQL абдан жөнөкөй. Жана биз бул маалыматтарды өзүбүз көрө алабыз.

Жана бул жерде босого баалуулуктар. Биз милдеттенмелердин жана артка кайтаруунун катышын карайбыз. Commits - транзакциянын ийгиликтүү тастыктоосу. Артка кайтаруу - бул артка кайтаруу, б.а. транзакция кандайдыр бир иштерди аткарып, маалымат базасын чыңдап, бир нерсе каралып, андан кийин ката болуп, транзакциянын натыйжалары жокко чыгарылат. б.а. тынымсыз көбөйүп жаткан артка кайтаруулардын саны жаман. Жана сиз кандайдыр бир жол менен алардан качышыңыз керек жана мындай болбошу үчүн кодду түзөтүңүз.

Конфликттер репликацияга байланыштуу. Жана алардан да оолак болуу керек. Эгерде сизде репликада аткарылган кээ бир суроолор болсо жана чыр-чатактар пайда болсо, анда бул конфликттерди талдап, эмне болорун көрүшүңүз керек. Толук маалыматты журналдардан тапса болот. Колдонмонун суроо-талаптары катасыз иштеши үчүн чыр-чатактарды чечиңиз.

Туюктуктар да жаман абал. Сурамдар ресурстар үчүн атаандашканда, бир суроо-талап бир ресурска кирип, кулпуну алып, экинчи суроо экинчи ресурска кирип, кулпуну да алып, андан кийин эки суроо тең бири-биринин ресурстарына кирип, кошунасынын кулпуну бошотушун күтүү үчүн бөгөттөлгөн. Бул да көйгөйлүү жагдай. Аларды тиркемелерди кайра жазуу жана ресурстарга жеткиликтүүлүктү сериялаштыруу деңгээлинде чечүү керек. Ал эми сиздин туюктарыңыз тынымсыз көбөйүп жатканын көрсөңүз, анда журналдардагы майда-чүйдөлөрдү карап, пайда болгон жагдайларды талдап, көйгөй эмнеде экенин көрүшүңүз керек.

Убактылуу файлдар (temp_files) да начар. Колдонуучунун сурамында оперативдүү, убактылуу маалыматтарды жайгаштыруу үчүн жетиштүү эстутум жок болгондо, ал дискте файлды түзөт. Ал эми эс тутумдун убактылуу буферинде жасай алган бардык операцияларды ал дискте жасай баштайт. Бул жай. Бул суроону аткаруу убактысын көбөйтөт. Ал эми PostgreSQLге суроо-талап жөнөткөн кардар бир аздан кийин жооп алат. Бул операциялардын баары эс тутумда аткарылса, Postgres тезирээк жооп берет жана кардар аз күтөт.

pg_stat_bgwriter - Бул көрүнүш эки PostgreSQL фондук субсистемасынын иштешин сүрөттөйт: checkpointer и background writer.

Баштоо үчүн, контролдоо пункттары деп аталгандарды талдап көрөлү. checkpoints. Көзөмөл пункттары деген эмне? Текшерүү пункту – бул журналда жасалган бардык маалыматтарды өзгөртүүлөр дисктеги маалыматтар менен ийгиликтүү синхрондоштурууну көрсөткөн транзакциялар журналындагы позиция. Иш жүктөмүнө жана орнотууларга жараша процесс узакка созулушу мүмкүн жана негизинен жалпы буферлердеги кир барактар менен дисктеги маалымат файлдарын синхрондоштуруудан турат. Бул эмне үчүн? Эгерде PostgreSQL ар дайым дискке кирип, ал жерден маалыматтарды алып, ар бир кирүү боюнча маалыматтарды жазып турса, ал жай болмок. Ошондуктан, PostgreSQLде эс тутум сегменти бар, анын өлчөмү конфигурациядагы параметрлерге жараша болот. Postgres бул эстутумда операциялык маалыматтарды андан ары иштетүү же суроо үчүн бөлүштүрөт. Маалыматтарды өзгөртүү өтүнүчү болгон учурда, алар өзгөртүлөт. Ал эми биз маалыматтардын эки версиясын алабыз. Бири эстутумда, экинчиси дискте. Жана мезгил-мезгили менен бул маалыматтарды синхрондоштуруу керек. Бизге эстутумда өзгөргөн нерсени дискке синхрондоштуруу керек. Бул текшерүү пунктун талап кылат.

Текшерүү пункту жалпы буферлерден өтөт, текшерүү пункту үчүн зарыл болгон кир барактарын белгилейт. Андан кийин жалпы буферлер аркылуу экинчи өтүүнү баштайт. Ал эми текшерүү пункту үчүн белгиленген барактар, ал буга чейин аларды синхрондоштуруу. Ошентип, маалыматтар диск менен синхрондоштурулган.

Башкаруу пункттарынын эки түрү бар. Бир текшерүү пункту тайм-аут боюнча аткарылат. Бул өткөрүү пункту пайдалуу жана жакшы - checkpoint_timed. Ал эми талап боюнча текшерүү пункттары бар - checkpoint required. Мындай текшерүү пункту бизде өтө чоң маалымат жазуусу болгондо пайда болот. Биз көптөгөн транзакция журналдарын жаздык. Ал эми PostgreSQL мунун бардыгын мүмкүн болушунча тезирээк синхрондоштуруу, текшерүү пунктун жасап, улантуу керек деп эсептейт.

Ал эми статистиканы карасаңыз pg_stat_bgwriter жана сенде эмне бар экенин көр checkpoint_req checkpoint_timedден алда канча чоң, анда бул жаман. Эмнеге жаман? Бул PostgreSQL дискке маалыматтарды жазуу керек болгондо дайыма стресске кабыларын билдирет. Тайм-аут боюнча текшерүү пункту азыраак стресске ээ жана ички графикке ылайык аткарылат жана убакыттын өтүшү менен узартылат. PostgreSQL жумушта тыныгуу жана дисктин подсистемасын бузбоо мүмкүнчүлүгүнө ээ. Бул PostgreSQL үчүн пайдалуу. Ал эми текшерүү учурунда аткарылган суроо-талаптар дисктин подсистемасы бош эместигинен стресске дуушар болбойт.

Ал эми текшерүү пунктун жөнгө салуу үчүн үч параметр бар:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Алар башкаруу пункттарынын ишин контролдоого мумкундук берет. Бирок мен аларга токтолбойм. Алардын таасири өзүнчө маселе.

Эскертүү: Отчетто каралган 9.4 версиясы актуалдуу болбой калды. PostgreSQLдин заманбап версияларында параметр checkpoint_segments параметрлер менен алмаштырылган min_wal_size и max_wal_size.

Кийинки подсистема фон жазуучу - background writer. Ал эмне кылып жатат? Ал чексиз циклде тынымсыз иштейт. Ал жалпы буферлерге барактарды сканерлейт жана дискке тапкан кир барактарын тазалайт. Ошентип, ал текшерүүчүгө текшерүү учурунда азыраак иш кылууга жардам берет.

Ал дагы эмнеге керек? Ал күтүлбөгөн жерден маалыматтарды жайгаштыруу үчүн (чоң көлөмдө жана дароо) талап кылынса, жалпы буферлерде таза барактардын зарылдыгын камсыз кылат. Сурам таза беттерди талап кылган жана алар буга чейин жалпы буферлерде турган кырдаал пайда болду дейли. Postgres backend аларды жөн гана алып, колдонот, өзү эч нерсе тазалаш керек эмес. Бирок күтүлбөгөн жерден андай барактар жок болсо, бэкэнд тыным жасап, аларды дискке жууп, өз муктаждыктары үчүн алуу үчүн баракчаларды издей баштайт - бул учурда аткарылып жаткан суроо-талаптын убактысына терс таасирин тийгизет. Эгер сизде параметр бар экенин көрсөңүз maxwritten_clean чоң, бул фон жазуучу өз ишин аткарбай жатат жана параметрлерин жогорулатуу керек дегенди билдирет bgwriter_lru_maxpagesОшентип, ал бир циклде көбүрөөк иш жасай алат, көбүрөөк барактарды тазалайт.

Жана дагы бир абдан пайдалуу көрсөткүч болуп саналат buffers_backend_fsync. Backends fsync аткарбайт, анткени ал жай. Алар fsyncти IO стек текшерүү пунктунан өткөрүшөт. Текшерүү пунктунун өзүнүн кезеги бар, ал мезгил-мезгили менен fsync иштетет жана эстутумдагы баракчаларды дисктеги файлдар менен синхрондошот. Эгерде текшерүүчү кезеги чоң жана толук болсо, анда бэкенд fsyncти өзү аткарууга аргасыз болот жана бул бэкэндди жайлатат, б.а. кардар мүмкүн болушунча кечирээк жооп алат. Эгер сизде бул маани нөлдөн жогору экенин көрсөңүз, анда бул көйгөй жана Фондук жазуучунун жөндөөлөрүнө көңүл бурушуңуз керек, ошондой эле дисктин подсистемасынын иштешине баа беришиңиз керек.

Эскертүү: _Төмөнкү текст репликацияга байланыштуу статистикалык көрүнүштөрдү сүрөттөйт. Көпчүлүк көрүнүштөрдүн жана функциялардын аталыштары Postgres 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 жана биз байт жана секунда менен репликациянын артта калышын баалай алабыз. Бул үчүн биз бул көрүнүштүн маанисин да колдонобуз (КӨРҮНҮҮ).

Эскертүү: _pg_xlog_location ордунаdiff() функциясын колдонсоңуз болот, сиз кемитүү операторун колдонуп, бир жерди башкасынан кемите аласыз. Ыңгайлуу.

секунданын ичинде болгон артта калуу менен, бир көз ирмем бар. Эгерде мастерде активдүүлүк жок болсо, транзакция болжол менен 15 мүнөт мурун болгон жана эч кандай активдүүлүк жок, ал эми репликада бул артта калууну карасак, анда биз 15 мүнөттүк артта калууну көрөбүз. Муну эстен чыгарбоо керек. Жана бул артта калганды көргөндө дүмүрлүккө алып келиши мүмкүн.

pg_stat_all_tables дагы бир пайдалуу көрүнүш. Бул таблицаларда статистиканы көрсөтөт. Бизде маалымат базасында таблицалар болгондо, аны менен кандайдыр бир активдүүлүк, кандайдыр бир иш-аракеттер бар, биз бул маалыматты ушул көрүнүштөн ала алабыз.

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;

Биз карап турган биринчи нерсе - ырааттуу стол сканерлери. Бул үзүндүлөрдөн кийинки сандын өзү сөзсүз эле жаман эмес жана биз буга чейин бир нерсе кылышыбыз керек экенин билдирбейт.

Бирок, экинчи метрика бар - seq_tup_read. Бул ырааттуу сканерлөөдөн кайтарылган саптардын саны. Эгерде орточо сан 1, 000, 10, 000ден ашса, анда бул индикатор болуп саналат, бул сиз индикаторлор индекс боюнча болушу үчүн индексти түзүшүңүз керек же ушундай ырааттуу сканерлөөлөрдү колдонгон сурамдарды оптималдаштырууга болот. мындай болбойт.болду.

Жөнөкөй мисал - келгиле, чоң OFFSET жана LIMIT менен өтүнүч арзырлык деп коёлу. Мисалы, таблицадагы 100 000 сап сканерленет жана андан кийин 50 000 талап кылынган саптар алынып, мурунку сканерленген саптар жокко чыгарылат. Бул да жаман көрүнүш. Жана мындай суроо-талаптарды оптималдаштыруу керек. Ал эми бул жерде сиз аны көрүп жана алынган сандарды баалоого мүмкүн болгон жөнөкөй SQL суроо болуп саналат.

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, аны сиз PSQLде колдоно аласыз, ошондой эле таблица менен индекстин өлчөмдөрүн көрө аласыз.

Бирок, функцияларды колдонуу, жада калса, индекстерди эске алуу менен, же индекстерди эсепке албастан, таблицалардын өлчөмдөрүн карап чыгууга жардам берет жана маалымат базасынын өсүшүнө, б.а. биз менен кантип өсүп жаткандыгына негизделген кээ бир эсептөөлөрдү жасоого жардам берет. кандай интенсивдүүлүк жана өлчөмдү оптималдаштыруу жөнүндө кээ бир тыянактарды чыгарыңыз.

Иш жазуу. рекорд деген эмне? Операцияны карап көрөлү 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;

Жана анын дизайнына байланыштуу, UPDATE оор операция болуп саналат. Бирок аларды жеңилдетсе болот. же hot updates. Алар PostgreSQL 8.3 версиясында пайда болгон. Жана бул эмне? Бул индекстердин кайра түзүлүшүнө алып келбеген жеңил жаңыртуу. Башкача айтканда, биз рекордду жаңырттык, бирок барактагы жазуу гана (таблицага тиешелүү) жаңыртылды жана индекстер дагы эле баракта ошол эле жазууну көрсөтүп турат. Жумуштун мындай кызыктуу логикасы бар, вакуум келгенде, анда бул чынжырлар бар hot кайра куруп, бардыгы индекстерди жаңыртпастан ишин улантат жана бардыгы ресурстарды аз ысырап кылуу менен болот.

Жана сизде болгондо n_tup_hot_upd чоң, бул абдан жакшы. Бул жеңил жаңыртуулар басымдуулук кылат дегенди билдирет жана бул биз үчүн ресурстар боюнча арзан жана баары жакшы.

ALTER TABLE table_name SET (fillfactor = 70);

Көлөмүн кантип көбөйтүү керек hot updateov? Биз колдоно алабыз fillfactor. Ал INSERTтерди колдонуу менен таблицадагы баракты толтурууда сакталган бош орундун өлчөмүн аныктайт. Кыстармалар үстөлгө барганда баракты толугу менен толтурат, анда бош орун калтырбайт. Андан кийин жаңы барак баса белгиленет. Маалыматтар кайрадан толтурулат. Жана бул демейки жүрүм-турум, fillfactor = 100%.

Биз толтуруучу факторду 70%га орното алабыз. Башкача айтканда, кыстармалар менен жаңы барак бөлүнгөн, бирок барактын 70% гана толтурулган. Ал эми бизде резервде 30% калды. Жаңыртуу керек болгондо, ал ошол эле баракта болот жана катардын жаңы версиясы ошол эле баракка туура келет. Жана hot_update жасалат. Бул таблицаларга жазууну жеңилдетет.

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));

Автовакуум кезеги. Autovacuum - PostgreSQLде статистика өтө аз болгон мындай подсистема. Учурда бизде канча вакуум бар экенин pg_stat_activity таблицаларында гана көрө алабыз. Бирок, ал кыймылда турган кезекте канча үстөл түшүнүү абдан кыйын.

Эскертүү: _Postgres 10-жылдан бери вакуумдук вакуумду көзөмөлдөө абалы бир топ жакшырды - pg_stat_progress көрүнүшү пайда болдувакуум, бул автовакуумдук мониторинг маселесин бир топ жеңилдетет.

Биз бул жөнөкөйлөштүрүлгөн суроону колдоно алабыз. Ал эми вакуум качан жасалышы керек экенин көрө алабыз. Бирок, вакуум кантип жана качан башталышы керек? Булар мен мурда айткан саптардын эски версиялары. Жаңыртуу болду, катардын жаңы версиясы киргизилди. Саптын эскирген версиясы пайда болду. Таблица 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 жекече дайындалышы мүмкүн. Жана, ошого жараша, босого глобалдык эмес, үстөл үчүн жекече болот. Ошондуктан, эсептөө үчүн, ал жерде трюктарды жана амалдарды колдонуу керек. Эгер сизди кызыктырса, Avitoдогу кесиптештерибиздин тажрыйбасын карап көрсөңүз болот (слайддагы шилтеме жараксыз жана текстте жаңыртылган).

Алар үчүн жазышкан munin плагинибул нерселерди эске алат. Эки шейшепте бут кийим бар. Бирок ал туура жана натыйжалуу эсептейт, бизге столдор үчүн көп вакуум керек болгон жерде, кайсы жерде аз болсо, баалоого мүмкүндүк берет.

Бул тууралуу эмне кылсак болот? Эгерде бизде узун кезек болсо жана автовакуум көтөрө албаса, анда биз вакуумда иштегендердин санын көбөйтүп, же жөн эле вакуумду агрессивдүү кыла алабыз.ал эртерээк пайда болушу үчүн, үстөлдү майда бөлүктөргө бөлүп иштетет. Ошентип кезек азаят. - Бул жерде негизги нерсе - дисктердеги жүктөмдү көзөмөлдөө, анткени. Вакуумдук нерсе бекер эмес, бирок SSD / NVMe түзмөктөрүнүн пайда болушу менен көйгөй анча байкалбай калды.

pg_stat_all_indexes - индекстер боюнча статистика. Ал чоң эмес. Ал эми андан индекстерди колдонуу боюнча маалымат ала алабыз. Ал эми, мисалы, бизде кошумча кайсы индекстер бар экенин аныктай алабыз.

Мен буга чейин айткандай, жаңыртуу таблицаларды жаңыртуу гана эмес, индекстерди да жаңылоо. Демек, эгерде бизде столдо индекстер көп болсо, анда таблицадагы саптарды жаңыртууда индекстелген талаалардын индекстери да жаңыланышы керек жана эгерде бизде эч кандай индекс сканерлери жок пайдаланылбаган индекстер болсо, анда алар балласт катары биз менен илинет. Жана алардан арылуу керек. Бул үчүн бизге талаа керек idx_scan. Биз жөн гана индексти сканерлөөнүн санын карайбыз. Эгерде индекстерде статистикалык маалыматтарды сактоонун салыштырмалуу узак мезгили (жок дегенде 2-3 жума) ичинде нөл сканерлери бар болсо, анда бул жаман индекстер болушу мүмкүн, биз алардан арылуубуз керек.

Эскертүү: Агымдык репликация кластерлеринде пайдаланылбаган индекстерди издөөдө кластердин бардык түйүндөрүн текшерүү керек, анткени статистика глобалдуу эмес, жана индекс мастерде колдонулбаса, анда аны репликаларда колдонсо болот (эгерде жүк бар болсо).

Эки шилтеме:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Бул колдонулбаган индекстерди кантип издөө керектиги боюнча өркүндөтүлгөн суроо мисалдары.

Экинчи шилтеме абдан кызыктуу суроо. Анда өтө майда-чүйдө эмес логика бар. Мен аны карап чыгууга сунуштайм.

Индекс менен дагы эмнени жыйынтыктоо керек?

Колдонулбаган индекстер начар.
Алар орун ээлейт.
Жаңыртуу операцияларын жайлатыңыз.
Вакуум үчүн кошумча жумуш.

Эгер биз пайдаланылбаган индекстерди алып салсак, анда биз маалымат базасын жакшыртабыз.

Кийинки көрүнүш pg_stat_activity. Бул программанын аналогу ps, PostgreSQLде гана. Эгерде ps'Ом, анда сиз операциялык системадагы процесстерге көз салып турасыз pg_stat_activity сизге PostgreSQL ичиндеги аракеттерди көрсөтөт.

Ал жерден кандай пайдалуу нерселерди ала алабыз?

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 байланыш ачты. Ошондо ага бир нерсе болду. Аны менен күрөшүп, көрүш керек. Жана бул кандайдыр бир аномалдуу байланыштар болушу толук мүмкүн.

Эгерде бизде OLTP жүктөмү бар болсо, анда сурамдар тез, абдан тез болушу керек жана узак сурамдар болбошу керек. Бирок, узак суроо-талаптар бар болсо, анда кыска мөөнөттө тынчсыздана турган эч нерсе жок, бирок узак мөөнөттүү келечекте, узак сурамдар маалымат базасына зыян келтирет, алар таблицанын фрагменттелиши пайда болгондо таблицалардын толтуруучу таасирин күчөтөт. Шишиген жана узун суроолорду жок кылуу керек.

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)';

Анан мен жогоруда айткандай, бул эки мамлекет транзакцияда иштебей калуу жана транзакцияда бош туруу (аборт) жаман. Бул эмне? Бул тиркеме транзакцияны ачып, кандайдыр бир аракеттерди жасап, өз ишин баштаганда. Транзакция ачык бойдон калууда. Ал илинип турат, анда эч нерсе болбойт, ал байланышты талап кылат, өзгөрүлгөн саптарда кулпуланат жана Postrges транзакциялык кыймылдаткычынын архитектурасына байланыштуу башка таблицалардын көбөйүшү мүмкүн. Жана мындай бүтүмдөрдү да атыш керек, анткени алар жалпысынан зыяндуу, кандай болгон күндө да.

Эгер базаңызда алардын 5-10-20дан ашыгы бар экенин көрсөңүз, тынчсызданып, алар менен бир нерсе кыла башташыңыз керек.

Бул жерде биз эсептөө убактысын да колдонобуз clock_timestamp(). Биз транзакцияларды жасайбыз, тиркемени оптималдаштырабыз.

Мен жогоруда айткандай, эки же андан көп транзакциялар бир же бир топ ресурстар үчүн атаандашканда кулпулар. Бул үчүн бизде талаа бар waiting логикалык мааниге ээ true же false.

Туура - бул процесс күтүп жатканын билдирет, бир нерсе кылуу керек. Процесс күтүп турганда, процессти баштаган кардар да күтүп жатат. Браузердеги кардар отурат жана күтөт.

Эскертүү: _Postgres 9.6дан баштап, талаа waiting алынып салынды жана дагы эки маалыматтык талаа менен алмаштырылды wait_event_type и wait_event._

Эмне кылуу керек? Эгер сиз көптөн бери чындыкты көрсөңүз, анда мындай өтүнүчтөрдөн арылуу керек. Биз жөн гана ушундай транзакцияларды атабыз. Биз иштеп чыгуучуларга ресурстар үчүн жарыш болбошу үчүн кандайдыр бир жол менен оптималдаштыруу керек деп жазабыз. Андан кийин иштеп чыгуучулар тиркемени мындай болбошу үчүн оптималдаштырышат.

Ал эми экстремалдык, бирок өлүмгө алып келбеген окуя туюктардын пайда болушу. Эки транзакция эки ресурсту жаңыртты, андан кийин алар кайра карама-каршы ресурстарга кире алышат. Бул учурда PostgreSQL транзакциянын өзүн алып, экинчиси иштей бериши үчүн өчүрөт. Бул туюк абал жана ал өзүн түшүнбөйт. Ошондуктан, PostgreSQL өтө чараларды көрүүгө аргасыз.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Бул жерде кулпуларды көзөмөлдөөгө мүмкүндүк берген эки суроо бар. Биз көрүнүштү колдонобуз pg_locks, бул оор кулпуларды көзөмөлдөөгө мүмкүндүк берет.

Ал эми биринчи шилтеме суроо-талаптын тексти. Бул абдан узун.

Ал эми экинчи шилтеме - кулпулар боюнча макала. Окуу пайдалуу, абдан кызыктуу.

Анда биз эмнени көрүп жатабыз? Биз эки өтүнүчтү көрүп жатабыз. менен транзакция ALTER TABLE бөгөттөөчү транзакция болуп саналат. Ал башталды, бирок бүтпөй калды жана бул транзакцияны жарыялаган тиркеме бир жерде башка иштерди жасап жатат. Ал эми экинчи өтүнүч жаңыртуу. Ал өз ишин улантуудан мурун өзгөртүү үстөлүнүн бүтүшүн күтөт.

Ким кимди камап, ким кимди кармап жатканын мына ушинтип билип, мындан ары да чечсек болот.

Кийинки модул pg_stat_statements. Мен айткандай, бул модуль. Аны колдонуу үчүн анын китепканасын конфигурацияга жүктөп, PostgreSQLди кайра иштетип, модулду орнотуу керек (бир буйрук менен), андан кийин бизде жаңы көрүнүш пайда болот.

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;

Ал жерден эмнени алсак болот? Эгерде биз жөнөкөй нерселер жөнүндө сөз кыла турган болсок, анда биз сурамдарды аткаруунун орточо убактысын алабыз. Убакыт өсүп жатат, демек, PostgreSQL жай жооп берип жатат жана бир нерсе кылыш керек.

Биз жалпы буфердеги маалыматтарды өзгөрткөн маалымат базасында эң активдүү жазуу транзакцияларын көрө алабыз. Ал жерде маалыматтарды ким жаңыртып же жок кыларын көрүңүз.

Жана биз жөн гана бул суроолор боюнча ар кандай статистиканы карай алабыз.

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

биз pg_stat_statements Биз аны отчетторду түзүү үчүн колдонобуз. Биз күнүнө бир жолу статистиканы калыбына келтиребиз. Аны топтоп алалы. Кийинки жолу статистиканы баштапкы абалга келтирүүдөн мурун, келгиле, отчет түзөлү. Бул жерде отчеттун шилтемеси. Сиз аны көрө аласыз.

Биз эмне кылып жатабыз? Биз бардык суроо-талаптар боюнча жалпы статистиканы эсептейбиз. Андан кийин, ар бир суроо үчүн, биз анын жалпы статистикага кошкон жеке салымын эсептейбиз.

Анан эмнени көрө алабыз? Биз бардык башка суроо-талаптардын фонунда белгилүү бир түрдөгү бардык сурамдардын жалпы аткарылуу убактысын көрө алабыз. Биз жалпы сүрөткө карата CPU жана I/O колдонулушун карай алабыз. Бул суроо-талаптарды оптималдаштыруу үчүн. Биз бул отчеттун негизинде жогорку суроо-талаптарды түзүп жатабыз жана эмнени оптималдаштыруу керектиги жөнүндө ойлонууга тамактанып жатабыз.

Бизде көшөгө артында эмне бар? Убакыт чектелүү болгондуктан, мен эске албаган бир нече сунуштар бар.

бар pgstattuple ошондой эле стандарттык салым пакетинин кошумча модулу болуп саналат. Баалоого мүмкүндүк берет bloat столдор, деп аталган. столдун фрагментациясы. Ал эми фрагментация чоң болсо, аны алып салуу керек, ар кандай куралдарды колдонушат. Жана функция pgstattuple узак убакыт бою иштейт. Ал эми үстөлдөрдүн саны канчалык көп болсо, ал ошончолук көп иштейт.

Кийинки салым болуп саналат pg_buffercache. Бул жалпы буферлерди текшерүүгө мүмкүндүк берет: буфер барактары канчалык интенсивдүү жана кайсы таблицалар үчүн колдонулат. Ал жөн гана жалпы буферлерди карап, ал жерде эмне болуп жатканын баалоого мүмкүндүк берет.

Кийинки модул pgfincore. Ал системалык чалуу аркылуу төмөнкү деңгээлдеги стол операцияларын аткарууга мүмкүндүк берет mincore(), б.а. бул сизге таблицаны жалпы буферлерге жүктөөгө же аны түшүрүүгө мүмкүндүк берет. Жана башка нерселер менен катар, операциялык тутумдун бет кэшин текшерүүгө мүмкүндүк берет, башкача айтканда, таблица бет кэшинде, жалпы буферлерде канча ээлейт жана жөн гана столдун жүгүн баалоого мүмкүндүк берет.

Кийинки модул pg_stat_kcache. Ал ошондой эле система чалуу колдонот getrusage(). Ал аны өтүнүч аткарылганга чейин жана кийин аткарат. Алынган статистикада бул биздин суроо-талапыбызды дискке киргизүү/чыгаруу, б.а. файлдык система менен операцияларга канча сарпталганын жана процессордун колдонулушун карап чыгууга мүмкүндүк берет. Бирок, модул жаш (khe-khe) жана анын иштеши үчүн мен жогоруда айткан PostgreSQL 9.4 жана pg_stat_statements талап кылынат.

Статистиканы колдонуу мүмкүнчүлүгү пайдалуу. Сиз үчүнчү тараптын программалык камсыздоонун кереги жок. Сиз карап, көрө аласыз, бир нерсе кыла аласыз, аткара аласыз.
Статистиканы колдонуу оңой, бул жөнөкөй SQL. Сураныч чогултуп, түздүңүз, жөнөттүңүз, карап чыктыңыз.
Статистика суроолорго жооп берүүгө жардам берет. Суроолоруңуз болсо, статистикага кайрылыңыз - карап көрүңүз, жыйынтык чыгарыңыз, натыйжаларды талдаңыз.
Жана эксперимент. Көптөгөн суроо-талаптар, көп маалыматтар. Сиз ар дайым кээ бир учурдагы суроо оптималдаштыруу болот. Сиз оригиналга караганда өзүңүзгө ылайыктуу суроо-талаптын версиясын жасап, аны колдоно аласыз.