Мен Николай Самохваловтың «PostgreSQL-ті баптауға индустриалды көзқарас: мәліметтер базасындағы эксперименттер» баяндамасының транскрипциясын оқуды ұсынамын.
Shared_buffers = 25% – бұл көп пе, әлде аз ба? Әлде дұрыс па? Бұл өте ескірген ұсыныс сіздің нақты жағдайыңызға сәйкес келетінін қалай білуге болады?
«Ересектер сияқты» postgresql.conf параметрлерін таңдау мәселесіне жақындау уақыты келді. Соқыр «автотюнерлердің» немесе мақалалар мен блогтардың ескірген кеңестерінің көмегімен емес, бірақ мыналарға негізделген:
- автоматты түрде, үлкен көлемде және мүмкіндігінше «жауынгерлікке» жақын жағдайларда жүргізілетін дерекқорлардағы қатаң тексерілген эксперименттер,
- МҚБЖ және ОЖ мүмкіндіктерін терең түсіну.
Нэнси CLI пайдалану (), біз белгілі бір мысалды - әйгілі shared_buffers - әртүрлі жағдайларда, әртүрлі жобаларда қарастырамыз және инфрақұрылымымыз, дерекқорымыз және жүктемеміз үшін оңтайлы параметрді қалай таңдауға болатынын анықтауға тырысамыз.
Біз мәліметтер базасымен эксперименттер туралы айтатын боламыз. Бұл алты айдан сәл астам уақытқа созылатын әңгіме.
Мен туралы аздап. Postgres-пен 14 жылдан астам жұмыс тәжірибесі. Бірқатар әлеуметтік желілік компаниялар құрылды. Postgres барлық жерде қолданылған және қолданылады.
Сондай-ақ Meetup-тағы RuPostgres тобы, әлемде 2-ші орын. Біз біртіндеп 2 адамға жақындап келеміз. RuPostgres.org.
Әртүрлі конференциялардың компьютерлерінде, соның ішінде Highload, мен дерекқорларға, атап айтқанда Postgres-ке ең басынан бастап жауаптымын.
Соңғы бірнеше жылда мен Postgres кеңес беру тәжірибесін осы жерден 11 уақыт белдеуін қайта бастадым.
Мен мұны бірнеше жыл бұрын жасаған кезде, Postgres-пен белсенді қолмен жұмыс істеуде біраз үзіліс болды, мүмкін 2010 жылдан бері. Мен DBA жұмысының тәртібі қаншалықты аз өзгергеніне және әлі де қанша қол еңбегін пайдалану керек екеніне таң қалдым. Мен бірден бұл жерде бірдеңе дұрыс емес деп ойладым, маған бәрін автоматтандыру керек.
Барлығы шалғайда болғандықтан, клиенттердің көпшілігі бұлттарда болды. Және көп нәрсе автоматтандырылғаны анық. Бұл туралы кейінірек. Яғни, мұның бәрі көптеген құралдардың болуы керек деген идеяны тудырды, яғни көптеген дерекқорларды басқаруға болатындай барлық дерлік DBA әрекеттерін автоматтандыратын платформа түрі.
Бұл есеп мыналарды қамтымайды:
- "Күміс оқтар" және сияқты мәлімдемелер - 8 ГБ немесе 25% ортақ_буферлерді орнатыңыз, сонда бәрі жақсы болады. Shared_buffers туралы көп нәрсе болмайды.
- Хардкор «ішкі».
Не болады?
- Біз қолданатын және дамытатын оңтайландыру принциптері болады. Жол бойында пайда болатын идеялардың барлық түрлері және біз негізінен Open Source-те жасайтын әртүрлі құралдар болады, яғни біз Open Source-те негіз жасаймыз. Оның үстіне бізде билеттер бар, барлық байланыс іс жүзінде Open Source болып табылады. Сіз қазір не істеп жатқанымызды, келесі шығарылымда не болатынын және т.б. көре аласыз.
- Сондай-ақ осы принциптерді, осы құралдарды бірқатар компанияларда қолдану тәжірибесі болады: шағын стартаптардан ірі компанияларға дейін.
Мұның бәрі қалай дамып жатыр?
Біріншіден, DBA негізгі міндеті даналарды құруды, сақтық көшірмелерді орналастыруды және т.б. қамтамасыз етуден басқа, кедергілерді табу және өнімділікті оңтайландыру болып табылады.
Қазір ол осылай орнатылды. Мониторингке қараймыз, бірдеңе көріп жатырмыз, бірақ кейбір детальдар жетіспейді. Біз мұқият қазуды бастаймыз, әдетте қолдарымызбен және онымен не істеу керектігін түсінеміз.
Және екі тәсіл бар. Pg_stat_statements - баяу сұрауларды анықтауға арналған әдепкі шешім. pgBadger көмегімен Postgres журналдарын талдау.
Әрбір тәсілдің елеулі кемшіліктері бар. Бірінші тәсілде біз барлық параметрлерді алып тастадық. Ал егер біз SELECT * FROM кестесін көрсек, онда баған «?» мәніне тең. немесе Postgres 10-дан бері "$". Бұл индекстік сканерлеу немесе тізбекті сканерлеу екенін білмейміз. Бұл параметрге өте байланысты. Онда сирек кездесетін мәнді ауыстырсаңыз, ол индекстік сканерлеу болады. Егер сіз сол жерде кестенің 90% алатын мәнді ауыстырсаңыз, кезекті сканерлеу анық болады, өйткені Postgres статистиканы біледі. Бұл pg_stat_statements-тің үлкен кемшілігі, дегенмен кейбір жұмыстар жүргізілуде.
Журналды талдаудың ең үлкен кемшілігі - әдетте "log_min_duration_statement = 0" мәнін бере алмайсыз. Және бұл туралы да айтатын боламыз. Тиісінше, сіз бүкіл суретті көрмейсіз. Және өте жылдам кейбір сұраулар үлкен көлемде ресурстарды тұтынуы мүмкін, бірақ сіз оны көрмейсіз, себебі ол сіздің табалдырықыңыздан төмен.
DBA олар тапқан мәселелерді қалай шешеді?
Мысалы, біз бір мәселе таптық. Әдетте не жасалады? Егер сіз әзірлеуші болсаңыз, онда сіз өлшемі бірдей емес кейбір данада бірдеңе жасайсыз. Егер сіз DBA болсаңыз, онда сізде сахналау бар. Және біреу ғана болуы мүмкін. Ал ол алты айға артта қалды. Ал сіз өндіріске барамын деп ойлайсыз. Тіпті тәжірибелі DBA-лар репликада өндірісті тексереді. Және олар уақытша индексті жасайды, оның көмектесетініне көз жеткізіп, оны тастап, оны тасымалдау файлдарына қою үшін әзірлеушілерге береді. Бұл қазір болып жатқан сандырақ. Және бұл мәселе.
- Конфигурацияларды реттеу.
- Индекстер жиынын оңтайландыру.
- SQL сұрауының өзін өзгертіңіз (бұл ең қиын әдіс).
- Сыйымдылықты қосыңыз (көп жағдайда ең оңай әдіс).
Бұл нәрселермен көп нәрсе болып жатыр. Postgres-те көптеген тұтқалар бар. Білуге болатын нәрсе көп. Postgres-те көптеген индекстер бар, бұл конференцияны ұйымдастырушыларға да рахмет. Мұның барлығын білу керек және бұл DBA еместерді DBA-лар қара магиямен айналысатындай сезінеді. Яғни, мұның бәрін қалыпты түрде түсіне бастау үшін 10 жыл оқу керек.
Ал мен осы қара магияға қарсы күресушімін. Технология бар, ал мұның бәрінде түйсігі болмайтындай етіп бәрін істегім келеді.
Өмірден мысалдар
Мен мұны кем дегенде екі жобада, соның ішінде өз жобамда байқадым. Басқа блог жазбасы default_statistict_target үшін 1 мәні жақсы екенін айтады. Жарайды, өндірісте байқап көрейік.
Міне, біз екі жылдан кейін құралды пайдалана отырып, бүгін біз айтып отырған деректер қорындағы эксперименттердің көмегімен не болғанын және не болғанын салыстыра аламыз.
Ал ол үшін эксперимент жасау керек. Ол төрт бөліктен тұрады.
- Біріншісі – қоршаған орта. Бізге аппараттық құрал керек. Ал әлдебір компанияға келіп, келісім-шартқа отырсам, өндірістегідей техниканы маған беріңдер деп айтамын. Магистрлеріңіздің әрқайсысы үшін маған осындай кем дегенде бір жабдық керек. Немесе бұл Amazon немесе Google-дағы виртуалды машинаның мысалы, немесе маған дәл сол аппараттық құрал керек. Яғни, мен қоршаған ортаны қайта жасағым келеді. Ал қоршаған орта концепциясына біз Postgres негізгі нұсқасын қосамыз.
- Екінші бөлім – біздің зерттеу объектісі. Бұл дерекқор. Оны бірнеше жолмен жасауға болады. Мен сізге қалай екенін көрсетемін.
- Үшінші бөлік - жүктеме. Бұл ең қиын сәт.
- Ал төртінші бөлім - біз нені тексереміз, яғни нені немен салыстырамыз. Конфигурацияда бір немесе бірнеше параметрді өзгерте аламыз немесе индекс жасай аламыз және т.б.
Біз экспериментті бастаймыз. Міне, pg_stat_statements. Сол жақта болған оқиға. Оң жақта - не болды.
Сол жақта default_statistics_target = 100, оң жақта =1. Бұл бізге көмектескенін көреміз. Жалпы алғанда, барлығы 000%-ға жақсарды.
Бірақ егер біз төмен айналдырсақ, pgBadger немесе pg_stat_statements сұрауларының топтары болады. Екі нұсқа бар. Кейбір сұраулардың 88%-ға төмендегенін көреміз. Міне, инженерлік тәсіл. Оның неліктен батып кеткеніне таңғалатындықтан, ішін ары қарай қазып аламыз. Сіз статистикамен не болғанын түсінуіңіз керек. Неліктен статистикадағы көп шелек нашар нәтижелерге әкеледі.
Немесе біз қазып алмаймыз, бірақ «КСТЕНДІ ӨЗГЕРТУ ... БАҒАНДЫ ӨЗГЕРТУ» жасап, осы бағанның статистикасына 100 шелек қайтарамыз. Содан кейін басқа эксперимент арқылы біз бұл патч көмектескеніне көз жеткізе аламыз. Барлық. Бұл интуицияға емес, деректерге негізделген үлкен суретті көруге және шешім қабылдауға көмектесетін инженерлік тәсіл.
Басқа облыстардан бір-екі мысал. Көптеген жылдар бойы тестілеуде CI сынақтары бар. Ақыл-есі дұрыс жоба автоматтандырылған сынақтарсыз өмір сүрмейді.
Басқа салаларда: авиацияда, автомобиль өнеркәсібінде, аэродинамиканы сынаған кезде бізде де тәжірибе жасауға мүмкіндік бар. Біз сызбадан ғарышқа бірдеңе жібермейміз немесе көлікті бірден трассаға шығармаймыз. Мысалы, жел туннелі бар.
Басқа салалардағы бақылаулардан қорытынды жасауға болады.
Біріншіден, бізде ерекше орта бар. Ол өндіріске жақын, бірақ жақын емес. Оның басты ерекшелігі - ол арзан, қайталанатын және мүмкіндігінше автоматтандырылған болуы керек. Сондай-ақ егжей-тегжейлі талдау жүргізу үшін арнайы құралдар болуы керек.
Сірә, біз ұшақты ұшырып, ұшқанда, жел туннельіндегіге қарағанда, қанат бетінің әрбір миллиметрін зерттеуге мүмкіндігіміз аз болады. Бізде диагностикалық құралдар көбірек. Ұшаққа мінгізе алмайтын ауыр заттарды ауада тасымалдауға шамамыз жетеді. Postgres сияқты. Кейбір жағдайларда эксперименттер кезінде толық сұрауларды тіркеуді қоса аламыз. Біз мұны өндірісте жасағымыз келмейді. Біз мұны auto_explain арқылы қосуды да жоспарлауымыз мүмкін.
Жоғарыда айтқанымдай, автоматтандырудың жоғары деңгейі түймені басып, қайталауды білдіреді. Тәжірибе көп болуы үшін, ағынмен жүруі үшін осылай болуы керек.
Нэнси CLI - «деректер базасы зертханасының» негізі
Осылайша біз бұл әрекетті жасадық. Яғни, мен бұл идеяларды осыдан бір жылға жуық уақыт бұрын маусым айында айтқан болатынмын. Бізде Нэнси CLI деп аталатын Open Source бар. Бұл деректер базасы зертханасын құрудың негізі болып табылады.
— Бұл Gitlab сайтында ашық бастапқы кодта. Айтуға болады, байқап көруге болады. Мен слайдтарда сілтеме бердім. Сіз оны бассаңыз болады, ол сонда болады барлық жағынан.
Әрине, әлі де даму үстінде. Онда көптеген идеялар бар. Бірақ бұл біз күнделікті дерлік қолданатын нәрсе. Ал бізде идея болған кезде - неге біз 40 000 000 жолды жойған кезде бәрі IO-ға түседі, содан кейін біз эксперимент жүргізіп, не болып жатқанын түсіну үшін егжей-тегжейлі қарап, содан кейін оны жылдам түзетуге тырысамыз. Яғни, эксперимент жасап жатырмыз. Мысалы, біз бір нәрсені өзгертеміз және соңында не болатынын көреміз. Ал біз мұны өндірісте жасамаймыз. Бұл идеяның мәні.
Бұл қай жерде жұмыс істей алады? Бұл жергілікті түрде жұмыс істей алады, яғни оны кез келген жерде жасауға болады, тіпті оны MacBook компьютерінде де іске қосуға болады. Бізге докер керек, кеттік. Болды. Сіз оны кейбір жағдайда аппараттық құралда немесе виртуалды машинада кез келген жерде іске қоса аласыз.
Сондай-ақ EC2 Instance ішінде Amazon-да қашықтан жұмыс істеу мүмкіндігі бар. Және бұл өте керемет мүмкіндік. Мысалы, кеше біз i500 данасы бойынша ең жасынан бастап i3-3-xlarge-ге дейін 16-ден астам эксперимент жүргіздік. Ал 500 эксперимент бізге 64 долларды құрады. Әрқайсысы 15 минутқа созылды. Яғни, ол жерде дақтардың пайдаланылуына байланысты өте арзан – 70% жеңілдік, Amazon-ның секундтық төлемі. Сіз көп нәрсені жасай аласыз. Сіз нақты зерттеу жасай аласыз.
Postgres-тің үш негізгі нұсқасына қолдау көрсетіледі. Кейбір ескілерін және жаңа 12-нұсқасын аяқтау қиын емес.
Объектіні үш жолмен анықтауға болады. Бұл:
- Dump/sql файлы.
- Негізгі әдіс - PGDATA каталогын клондау. Әдетте, ол резервтік серверден алынады. Егер сізде қалыпты екілік сақтық көшірмелер болса, сол жерден клондарды жасауға болады. Егер сізде бұлттар болса, Amazon және Google сияқты бұлттық кеңсе мұны сіз үшін жасайды. Бұл нақты өндірісті клондаудың ең маңызды жолы. Біз осылай ашамыз.
- Соңғы әдіс Postgres-те бір нәрсенің қалай жұмыс істейтінін түсінгіңіз келсе, зерттеу үшін қолайлы. Бұл pgbench. pgbench көмегімен жасауға болады. Бұл бір ғана «db-pgbench» опциясы. Сіз оған қандай масштабты айтасыз. Және бәрі айтылғандай бұлтта жасалады.
Және жүктеңіз:
- Біз бір SQL ағынында жүктемені орындай аламыз. Бұл ең қарабайыр жол.
- Және біз жүктемені еліктей аламыз. Және біз оны ең алдымен келесі жолмен үлгі ете аламыз. Біз барлық журналдарды жинауымыз керек. Және бұл ауыртады. Неге екенін көрсетемін. Ал pgreplay көмегімен біз Нэнсиге енгізілген ойнаймыз.
- Немесе басқа нұсқа. Біз белгілі бір күшпен жасайтын қолөнер жүктемесі деп аталады. Жауынгерлік жүйеге ағымдағы жүктемемізді талдай отырып, біз сұраныстардың жоғарғы топтарын шығарамыз. Ал pgbench көмегімен біз бұл жүктемені зертханада эмуляциялай аламыз.
- Немесе SQL-дің қандай да бір түрін орындау керек, яғни қандай да бір тасымалдау түрін тексереміз, сол жерде индекс жасаймыз, сол жерде ANALAZE орындаймыз. Ал біз вакуумға дейін және вакуумнан кейін не болғанын қарастырамыз. Жалпы, кез келген SQL.
- Конфигурацияда бір немесе бірнеше параметрді өзгертеміз. Бізге, мысалы, Amazon-да терабайт дерекқорымыз үшін 100 мәнді тексеруді айта аламыз. Ал бірнеше сағаттан кейін сізде нәтиже болады. Әдетте, терабайт дерекқорды орналастыру үшін сізге бірнеше сағат қажет. Бірақ әзірлеуде патч бар, бізде мүмкін сериялар бар, яғни сіз бір серверде бірдей pgdata-ны үнемі пайдаланып, тексере аласыз. Postgres қайта іске қосылады және кэштер қалпына келтіріледі. Және сіз жүкті айдай аласыз.
- Каталог pg суретінен бастап әр түрлі файлдармен келедістат***. Ең қызығы pg_stat_statements, pg_stat_kcacke. Бұл сұрауларды талдайтын екі кеңейтім. Және pg_stat_bgwriter тек pgwriter статистикасын ғана емес, сонымен қатар бақылау нүктесін және серверлердің лас буферлерді қалай ауыстыратынын қамтиды. Және мұның бәрі қызық. Мысалы, біз shared_buffers орнатқанда, барлығының қаншалықты ауыстырғанын көру өте қызықты.
- Postgres журналдары да келіп жатыр. Екі журнал – дайындық журналы және жүктеуді ойнату журналы.
- Салыстырмалы түрде жаңа мүмкіндік - FlameGraphs.
- Сондай-ақ, жүктемені ойнату үшін pgreplay немесе pgbench опцияларын пайдалансаңыз, олардың шығысы жергілікті болады. Сіз кідіріс пен TPS көресіз. Олардың қалай көргенін түсінуге болады.
- Жүйе ақпараты.
- Негізгі CPU және IO тексерулері. Бұл Amazon-дағы EC2 данасы үшін көбірек, ағындағы 100 бірдей дананы іске қосып, сол жерде 100 түрлі іске қосуды орындағыңыз келсе, сізде 10 000 эксперимент болады. Сіз біреудің қысымына ұшыраған ақаулы дананы кездестірмейтініңізге көз жеткізуіңіз керек. Басқалары осы жабдық бөлігінде белсенді және сізде аз ресурс қалды. Мұндай нәтижелерден бас тартқан дұрыс. Алексей Копытовтың sysbench көмегімен біз басқалармен салыстыруға болатын бірнеше қысқа тексерулер жасаймыз, яғни сіз процессордың қалай әрекет ететінін және IO қалай әрекет ететінін түсінесіз.
Әртүрлі компаниялардың мысалында қандай техникалық қиындықтар бар?
Журналдар арқылы нақты жүктемені қайталағымыз келеді делік. Open Source pgreplay сайтында жазылған болса, бұл тамаша идея. Біз оны пайдаланамыз. Бірақ оның жақсы жұмыс істеуі үшін параметрлермен және уақытпен толық сұрауларды тіркеуді қосу керек.
Ұзақтығы мен уақыт белгісіне байланысты кейбір қиындықтар бар. Біз бұл асүйді толығымен босатамыз. Басты мәселе, сіз оған қол жеткізе аласыз ба, жоқ па?
Мәселе мынада, ол қол жетімді болмауы мүмкін. Ең алдымен, журналға қандай ағын жазылатынын түсіну керек. Егер сізде pg_stat_statements болса, секундына шамамен қанша байт жазылатынын түсіну үшін осы сұрауды (сілтеме слайдтарда қолжетімді болады) пайдалана аласыз.
Біз сұраныстың ұзақтығына қараймыз. Біз параметрлердің жоқтығын елемейміз, бірақ біз сұраудың ұзақтығын білеміз және оның секундына қанша рет орындалғанын білеміз. Осылайша біз секундына шамамен қанша байтты бағалай аламыз. Біз екі есе көп қателесуіміз мүмкін, бірақ біз тәртіпті осылай түсінетін боламыз.
Бұл сұраныс секундына 802 рет орындалатынын көреміз. Секундына_байт – 300 кБ/с плюс немесе минус жазылатынын көреміз. Және, әдетте, біз мұндай ағынды көтере аламыз.
Бірақ! Өйткені, әр түрлі каротаж жүйелері бар. Ал адамдардың әдепкі әдетте «syslog» болып табылады.
Егер сізде syslog болса, сізде осындай сурет болуы мүмкін. Біз pgbench аламыз, сұрауларды тіркеуді қосамыз және не болатынын көреміз.
Тіркеусіз - бұл сол жақтағы баған. Біз 161 000 TPS алдық. Syslog көмегімен - бұл Amazon-дағы Ubuntu 16.04 нұсқасында, біз 37 000 TPS аламыз. Ал егер каротаждың басқа екі әдісіне ауысатын болсақ, онда жағдай әлдеқайда жақсы. Яғни, төмендейді деп күткен едік, бірақ дәл осындай деңгейде емес.
Ал журналдар қатысатын CentOS 7 жүйесінде оңай іздеу үшін журналдарды екілік пішімге айналдырады және т.
Міне, адамдар осымен өмір сүреді. Көбінесе компанияларда, әсіресе ірі компанияларда мұны өзгерту өте қиын. Егер сіз syslog-тен құтыла алсаңыз, одан аулақ болыңыз.
- IOPS және жазу ағынын бағалаңыз.
- Тіркеу жүйесін тексеріңіз.
- Егер жобаланған жүктеме тым үлкен болса, сынама алуды қарастырыңыз.
Бізде pg_stat_statements бар. Мен айтқанымдай, ол сонда болуы керек. Ал біз сұраныстардың әрбір тобын арнайы түрде файлға алып, сипаттай аламыз. Содан кейін біз pgbench-те өте ыңғайлы мүмкіндікті пайдалана аламыз - бұл «-f» опциясын пайдаланып бірнеше файлдарды кірістіру мүмкіндігі.
Ол «-f» көп нәрсені түсінеді. Әр файлдың қандай үлеске ие болуы керектігін соңында «@» көмегімен анықтауға болады. Яғни, мұны 10% жағдайда, ал бұл 20% жасайды деп айта аламыз. Және бұл бізді өндірісте көретінімізге жақындатады.
Өндірісте не бар екенін қалай түсінеміз? Қандай үлес және қалай? Бұл біраз шетте қалды. Бізде тағы бір өнім бар . Сондай-ақ ашық бастапқы кодтағы база. Ал біз қазір оны белсенді түрде дамытып жатырмыз.
Ол сәл басқа себептермен дүниеге келген. Мониторинг жеткіліксіз деген себептермен. Яғни, сіз келіңіз, базаға қараңыз, бар проблемаларды қараңыз. Және, әдетте, сіз денсаулықты_тексеру жасайсыз. Егер сіз тәжірибелі DBA болсаңыз, онда сіз денсаулықты тексересіз. Біз индекстерді және т.б. пайдалануды қарастырдық. Егер сізде OKmeter болса, онда тамаша. Бұл Postgres үшін тамаша мониторинг. OKmeter.io – оны орнатыңыз, сонда бәрі өте жақсы жасалған. Ол ақылы.
Егер сізде жоқ болса, әдетте сізде көп нәрсе жоқ. Мониторингте әдетте процессор, IO, содан кейін ескертпелер бар, және бұл бәрі. Ал бізге көбірек керек. Біз автовакуумның қалай жұмыс істейтінін, бақылау нүктесінің қалай жұмыс істейтінін көруіміз керек, io біз бақылау нүктесін bgwriter және бэкендтерден бөлуіміз керек және т.б.
Мәселе мынада, егер сіз үлкен компанияға көмектессеңіз, олар бір нәрсені тез жүзеге асыра алмайды. Олар OKметрді тез сатып ала алмайды. Мүмкін олар оны алты айдан кейін сатып алар. Олар кейбір пакеттерді жылдам жеткізе алмайды.
Бізге ештеңе орнатуды қажет етпейтін арнайы құрал керек деген ой келді, яғни өндірісте ештеңе орнатудың қажеті жоқ. Оны ноутбукке немесе оны іске қосатын бақылау серверіне орнатыңыз. Ол көп нәрсені талдайды: операциялық жүйе, файлдық жүйе және Postgres өзі, өндіріске тікелей іске қосуға болатын жеңіл сұрауларды жасайды және ештеңе істемейді.
Біз оны Postgres-тексеру деп атадық. Медициналық тілмен айтқанда, бұл тұрақты денсаулықты тексеру. Егер ол автомобиль тақырыбы болса, бұл техникалық қызмет көрсету сияқты. Сіз маркаға байланысты көлігіңізге алты ай немесе жыл сайын техникалық қызмет көрсетесіз. Сіз базаға техникалық қызмет көрсетесіз бе? Яғни, үнемі терең зерттеу жүргізесіз бе? Ол жасалуы керек. Егер сіз сақтық көшірме жасасаңыз, тексеріп көріңіз, бұл маңызды емес.
Ал бізде мұндай құрал бар. Ол шамамен үш ай бұрын ғана белсенді түрде пайда бола бастады. Ол әлі жас, бірақ көп нәрсе бар.
Сұраулардың ең «ықпалды» топтарын жинау - Postgres-тексерудегі K003 есебі
Ал есептер тобы бар К. Осы уақытқа дейін үш есеп. Ал мұндай есеп K003 бар. Жалпы_уақыт бойынша сұрыпталған pg_stat_statements жоғарғы жағы бар.
Сұраныс топтарын жалпы_уақыт бойынша сұрыптағанда, жоғарғы жағында жүйемізді ең көп жүктейтін, яғни көбірек ресурстарды тұтынатын топты көреміз. Неліктен сұрау топтарын атаймын? Өйткені біз параметрлерді алып тастадық. Бұл енді сұраныстар емес, сұраулар топтары, яғни олар абстракцияланған.
Егер біз жоғарыдан төменге қарай оңтайландыратын болсақ, біз ресурстарымызды жеңілдетеміз және жаңарту қажет болған сәтті кейінге қалдырамыз. Бұл ақша үнемдеудің өте жақсы тәсілі.
Мүмкін, бұл пайдаланушыларға қамқорлық жасаудың өте жақсы тәсілі емес, өйткені біз сирек кездесетін, бірақ адам 15 секунд күткен өте тітіркендіргіш жағдайларды көрмеуіміз мүмкін. Жалпы алғанда, олар соншалықты сирек кездеседі, біз оларды көрмейміз, бірақ біз ресурстармен айналысамыз.
Бұл кестеде не болды? Біз екі суретке түсірдік. Postgres_checkup сізге әрбір көрсеткіш үшін дельтаны береді: жалпы уақыт, қоңыраулар, жолдар, ортақ_блкс_оқу, т.б.. Міне, дельта есептелді. pg_stat_statements-тің үлкен проблемасы оның қашан қалпына келтірілгенін есіне түсірмейді. pg_stat_database есте сақтаса, pg_stat_statements есте сақтамайды. 1 000 000 саны бар екенін көріп тұрсыз, бірақ біз қайдан санағанымызды білмейміз.
Міне, біз білеміз, мұнда бізде екі сурет бар. Бұл жағдайда дельтаның 56 секунд болғанын білеміз. Өте қысқа аралық. Жалпы_уақыт бойынша сұрыпталған. Содан кейін біз ажырата аламыз, яғни барлық көрсеткіштерді ұзақтығы бойынша бөлеміз. Әрбір көрсеткішті ұзақтығына бөлсек, секундына қоңыраулар саны болады.
Келесі, секундына жалпы_уақыт - менің сүйікті көрсеткішім. Ол секундпен, секундпен өлшенеді, яғни біздің жүйеге секундына осы сұраулар тобын орындау үшін қанша секунд қажет болды. Егер сіз секундына секундтан артық көрсеңіз, бұл сізге бірнеше ядроны беру керек дегенді білдіреді. Бұл өте жақсы көрсеткіш. Бұл досқа, мысалы, кем дегенде үш ядро қажет екенін түсінуге болады.
Бұл біздің ноу-хау, мен мұндайды еш жерден көрген емеспін. Назар аударыңыз - бұл өте қарапайым нәрсе - секундына секунд. Кейде сіздің процессорыңыз 100% болғанда, секундына жарты сағат, яғни сіз осы сұрауларды орындауға жарты сағат жұмсайсыз.
Әрі қарай секундына жолдарды көреміз. Оның секундына қанша жол оралғанын білеміз.
Сосын бір қызық жайт бар. Ортақ_буферлердің өзінен секундына қанша ортақ_буферді оқимыз. Хиттер қазірдің өзінде болды, біз жолдарды операциялық жүйе кэшінен немесе дискіден алдық. Бірінші нұсқа жылдам, ал екіншісі жағдайға байланысты жылдам болуы немесе болмауы мүмкін.
Ал дифференциацияның екінші жолы – осы топтағы сұраныстар санын бөлу. Екінші бағанда сізде әрқашан бір сұрауға бөлінген бір сұрау болады. Бір қызығы - бұл сұрауда қанша миллисекунд болды. Біз бұл сұраудың орташа есеппен қалай әрекет ететінін білеміз. Әрбір сұрау үшін 101 миллисекунд қажет болды. Бұл біз түсінуіміз керек дәстүрлі метрика.
Әрбір сұрау орта есеппен қанша жолды қайтарды? Біз бұл топтың 8 оралғанын көреміз. Орташа алғанда, кэштен қанша алынды және оқылды. Біз бәрі жақсы кэштелгенін көреміз. Бірінші топ үшін күшті хиттер.
Әр жолдағы төртінші ішкі жол жалпы санның қанша пайызын құрайды. Бізде қоңыраулар бар. 1 000 000 дейік.Ал бұл топтың қандай үлес қосып жатқанын түсінуге болады. Бұл жағдайда бірінші топ 0,01%-дан аз үлес қосатынын көреміз. Яғни, ол соншалықты баяу, біз оны жалпы суреттен көрмейміз. Ал екінші топ - қоңыраулар бойынша 5%. Яғни, барлық қоңыраулардың 5 пайызы екінші топ.
Total_time да қызықты. Біз жалпы жұмыс уақытымыздың 14%-ын сұраныстардың бірінші тобына жұмсадық. Ал екіншісіне – 11% және т.б.
Мен егжей-тегжейлі айтпаймын, бірақ мұнда нәзіктіктер бар. Біз қатені жоғарғы жағында көрсетеміз, өйткені салыстырған кезде суреттер қалқымалы болуы мүмкін, яғни кейбір сұраулар түсіп қалуы және екіншісінде енді болмауы мүмкін, ал кейбір жаңалары пайда болуы мүмкін. Міне, біз қатені есептейміз. Егер сіз 0 көрсеңіз, бұл жақсы. Қателер жоқ. Қате деңгейі 20%-ға дейін болса, бәрі жақсы.
Содан кейін тақырыбымызға ораламыз. Біз жұмыс көлемін жасауымыз керек. Біз оны жоғарыдан төмен қарай алып, 80% немесе 90% жеткенше жүреміз. Әдетте бұл 10-20 топ. Біз pgbench үшін файлдар жасаймыз. Біз онда кездейсоқ қолданамыз. Кейде бұл, өкінішке орай, нәтиже бермейді. Ал Postgres 12-де бұл тәсілді қолдану мүмкіндігі көбірек болады.
Содан кейін біз осылайша жалпы уақыт ішінде 80-90% аламыз. «@» белгісінен кейін не қою керек? Біз қоңырауларға қараймыз, қанша пайыздық бар екенін көреміз және біз мұнда өте көп пайыздық қарыздар екенімізді түсінеміз. Осы пайыздардан біз файлдардың әрқайсысын қалай теңестіру керектігін түсіне аламыз. Осыдан кейін біз pgbench пайдаланамыз және жұмысқа кірісеміз.
Бізде сондай-ақ K001 және K002 бар.
K001 - төрт ішкі жолы бар бір үлкен жол. Бұл біздің бүкіл жүктемемізге тән қасиет. Екінші баған мен екінші ішкі жолды қараңыз. Біз секундына шамамен бір жарым секунд екенін көреміз, яғни екі ядро болса, онда бұл жақсы болады. Сыйымдылығы шамамен 75% болады. Және ол осылай жұмыс істейтін болады. Егер бізде 10 ядро болса, онда біз әдетте тыныш боламыз. Осылайша біз ресурстарды бағалай аламыз.
K002 - бұл сұраныс кластары деп атайтыным, яғни ТАҢДАУ, INSERT, UPDATE, DELETE. Және бөлек ЖАҢАРТУ ҮШІН ТАҢДАУ, себебі бұл құлып.
Және бұл жерде біз SELECT қарапайым оқырмандар деп қорытынды жасауға болады - барлық қоңыраулардың 82%, бірақ сонымен бірге - жалпы_уақыттың 74%. Яғни, олар көп деп аталады, бірақ ресурстарды аз тұтынады.
Біз: «Дұрыс ортақ_буферлерді қалай таңдауға болады?» Деген сұраққа қайта ораламыз. Мен эталондардың көпшілігі идеяға негізделгенін байқаймын - өткізу қабілеті қандай болатынын көрейік, яғни өткізу қабілеті қандай болады. Ол әдетте TPS немесе QPS арқылы өлшенеді.
Біз баптау параметрлерін қолдана отырып, машинадан секундына мүмкіндігінше көп транзакцияларды сығып алуға тырысамыз. Мұнда таңдау үшін секундына дәл 311.
Бірақ ешкім жұмысына және үйіне бар жылдамдықпен оралмайды. Бұл ақымақ. Дерекқорлармен бірдей. Бізге толық жылдамдықпен жүрудің қажеті жоқ және ешкім де жасамайды. 100% процессоры бар өндірісте ешкім өмір сүрмейді. Дегенмен, мүмкін біреу өмір сүреді, бірақ бұл жақсы емес.
Идея мынада: біз әдетте сыйымдылықтың 20 пайызында, жақсырақ 50 пайыздан аспайды. Біз ең алдымен пайдаланушыларымыз үшін жауап беру уақытын оңтайландыруға тырысамыз. Яғни, біз тұтқаларды шартты түрде 20% жылдамдықта ең аз кідіріс болатындай етіп бұруымыз керек. Бұл біз өз тәжірибемізде қолдануға тырысатын идея.
Соңында, ұсыныстар:
- Дерекқор зертханасын міндетті түрде орындаңыз.
- Мүмкіндігінше, оны біраз уақытқа ашылатындай етіп сұраныс бойынша жасаңыз - ойнаңыз және оны тастаңыз. Егер сізде бұлттар болса, онда бұл сөзсіз, яғни көп тұру керек.
- Қызық болыңыз. Егер бірдеңе дұрыс емес болса, оның қалай әрекет ететінін эксперименттермен тексеріңіз. Нэнси базаның қалай жұмыс істейтінін тексеру үшін өзіңізді жаттықтыру үшін пайдаланылуы мүмкін.
- Және ең аз жауап уақытын мақсат етіңіз.
- Postgres көздерінен қорықпаңыз. Дереккөздермен жұмыс істегенде ағылшын тілін білу керек. Онда пікірлер көп, бәрі сонда түсіндіріледі.
- Дерекқордың денсаулығын үнемі, кем дегенде үш айда бір рет қолмен немесе Postgres-тексеру арқылы тексеріңіз.
Сіздің сұрақтарыңыз
Үлкен рахмет! Өте қызық нәрсе.
Екі дана.
Иә, екі бөлік. Тек мен толық түсінбедім. Нэнси екеуміз жұмыс істегенде, біз тек бір параметрді немесе бүкіл топты өзгерте аламыз ба?
Бізде delta конфигурация параметрі бар. Ол жерге бірден қалағаныңызша бұрыла аласыз. Бірақ сіз көп нәрсені өзгерткен кезде қате қорытынды жасауға болатынын түсінуіңіз керек.
Иә. Мен неге сұрадым? Өйткені сізде бір ғана параметр болған кезде эксперименттер жүргізу қиын. Сіз оны қатайтыңыз, оның қалай жұмыс істейтінін қараңыз. Мен оны шығардым. Сосын келесісін бастайсың.
Сіз оны бір уақытта қатайта аласыз, бірақ бұл жағдайға байланысты, әрине. Бірақ бір идеяны сынаған дұрыс. Бізде кеше бір идея болды. Бізде өте жақын жағдай болды. Екі конфигурация болды. Ал біз неге үлкен айырмашылық болғанын түсіне алмадық. Айырмашылықтың не екенін дәйекті түрде түсіну және табу үшін дихотомияны қолдану керек деген идея туындады. Сіз бірден параметрлердің жартысын бірдей етіп жасай аласыз, содан кейін төрттен және т.б. Барлығы икемді.
Және тағы бір сұрақ бар. Жоба жас және даму үстінде. Құжаттама дайын, толық сипаттамасы бар ма?
Мен мұнда параметрлердің сипаттамасына арнайы сілтеме жасадым. Бұл бар. Бірақ көп нәрсе әлі жоқ. Мен пікірлес адамдарды іздеймін. Ал мен оларды орындау кезінде табамын. Бұл өте керемет. Біреу менімен жұмыс істеп жатыр, біреу көмектесіп, бірдеңе жасады. Ал егер сізді осы тақырып қызықтырса, не жетіспейтіні туралы пікір қалдырыңыз.
Зертхананы салған соң, кері байланыс болатын шығар. Қарайық. Рақмет сізге!
Сәлеметсіз бе! Есеп үшін рахмет! Мен Amazon қолдауының бар екенін көрдім. GSP-ке қолдау көрсету жоспарлары бар ма?
Жақсы сұрақ. Біз жасай бастадық. Ақшаны үнемдегіміз келгендіктен, біз оны әзірге тоқтаттық. Яғни, localhost жүйесінде іске қосу арқылы қолдау бар. Сіз дананы өзіңіз жасай аласыз және жергілікті түрде жұмыс істей аласыз. Айтпақшы, біз солай істейміз. Мен мұны Getlab-те, GSP-де жасаймын. Бірақ біз мұндай оркестрді жасаудың мәнін әлі көрмейміз, өйткені Google-да арзан орындар жоқ. Сонда бар ??? жағдайлары бар, бірақ олардың шектеулері бар. Біріншіден, олар әрқашан тек 70% жеңілдікке ие және сіз ондағы бағамен ойнай алмайсыз. Сізді тепкілеу ықтималдығын азайту үшін нүктелерде бағаны 5-10% көтереміз. Яғни, сіз дақтарды сақтайсыз, бірақ оларды кез келген уақытта сізден алып тастауға болады. Егер сіз басқалардан сәл жоғары баға берсеңіз, кейінірек өлтіресіз. Google мүлдем басқа ерекшеліктерге ие. Және тағы бір өте нашар шектеу бар - олар тек 24 сағат өмір сүреді. Ал кейде экспериментті 5 күн жүргізгіміз келеді. Бірақ мұны дақтармен жасауға болады; дақтар кейде айларға созылады.
Сәлеметсіз бе! Есеп үшін рахмет! Сіз тексеру туралы айттыңыз. stat_statements қателерін қалай есептейсіз?
Өте жақсы сұрақ. Мен сізге егжей-тегжейлі көрсете аламын және айта аламын. Қысқасы, біз сұрау топтарының жиынтығы қалай өзгергенін қарастырамыз: қаншасы құлап, қанша жаңасы пайда болды. Содан кейін біз екі көрсеткішті қарастырамыз: total_time және қоңыраулар, сондықтан екі қате бар. Ал біз қалқымалы топтардың үлесін қарастырамыз. Екі топша бар: кеткендер және келгендер. Олардың жалпы суретке қосқан үлесі қандай екенін көрейік.
Суреттер арасындағы уақыт ішінде ол екі-үш рет айналады деп қорықпайсыз ба?
Яғни, олар қайтадан тіркелді ме, әлде не?
Мысалы, бұл сұрау бір рет алдын ала болды, содан кейін ол келді және қайтадан алдын ала алынды, содан кейін ол қайтадан келді және қайтадан алдын ала алынды. Ал сіз мұнда бірдеңені есептедіңіз және оның бәрі қайда?
Жақсы сұрақ, біз қарауымыз керек.
Мен ұқсас нәрсені жасадым. Бұл оңайырақ болды, әрине, мен мұны жалғыз жасадым. Бірақ мен stat_statements параметрлерін қалпына келтіруге, бастапқы күйге қайтаруға және суретті түсіру кезінде белгілі бір бөлшектен аз екенін анықтауға тура келді, бірақ ол жерде қанша stat_statements жиналуы мүмкін деген төбеге әлі жете алмады. Менің түсінігімше, ештеңе ығыстырылмаған.
Иә Иә.
Бірақ мен мұны қалай сенімді түрде жасау керектігін түсінбеймін.
Өкінішке орай, біз сол жерде сұрау мәтінін немесе pg_stat_statements бар сұрау идентификаторын қолданып, соған назар аударамыз ба, нақты есімде жоқ. Егер біз queryid-ге назар аударатын болсақ, онда теорияда біз салыстырмалы нәрселерді салыстырамыз.
Жоқ, оны суреттер арасында бірнеше рет мәжбүрлеп шығарып, қайтадан келуі мүмкін.
Бірдей идентификатормен бе?
Иә.
Біз мұны зерттейміз. Жақсы сұрақ. Біз оны зерттеуіміз керек. Бірақ әзірге біз көріп отырған нәрсе 0 деп жазылған...
Бұл, әрине, сирек кездесетін жағдай, бірақ мен stat_statemetns бұл жерде ығысып кететінін білгенде қатты таң қалдым.
Pg_stat_statements ішінде көп нәрсе болуы мүмкін. Егер сізде track_utility = қосулы болса, жинақтарыңыз да бақыланады деген фактіге тап болдық.
Иә, әрине.
Егер сізде кездейсоқ болатын java hibernate болса, онда хэш кестесі сонда орналаса бастайды. Ал сіз өте жүктелген қолданбаны өшіре салысымен, сіз 50-100 топты аласыз. Ал ол жақта бәрі азды-көпті тұрақты. Мұнымен күресудің бір жолы pg_stat_statements.max арттыру болып табылады.
Иә, бірақ қанша екенін білу керек. Ал әйтеуір біз оны бақылап отыруымыз керек. Мен солай істеймін. Яғни, менде pg_stat_statements.max бар. Мен суретке түсіру кезінде мен 70% жетпегенімді көрдім. Жарайды, біз ештеңе жоғалтқан жоқпыз. Қалпына келтірейік. Және біз қайтадан үнемдейміз. Егер келесі сурет 70-тен аз болса, сіз қайтадан ештеңе жоғалтпаған боларсыз.
Иә. Әдепкі қазір 5. Және бұл көптеген адамдар үшін жеткілікті.
Әдетте иә.
Бейне:
PS Өз атымнан, егер Postgres құпия деректерін қамтыса және оны сынақ ортасына қосу мүмкін болмаса, сіз пайдалана алатыныңызды айтамын. . Схема шамамен келесідей:
Ақпарат көзі: www.habr.com