Мен сізге Андрей Сальниковтың 2016 жылдың басындағы «Postgresql-де кебулерге әкелетін қосымшалардағы әдеттегі қателер» баяндамасының стенограммасын оқуды ұсынамын.
Бұл есепте мен қосымшалар кодын жобалау және жазу кезеңінде пайда болатын қолданбалардағы негізгі қателерді талдаймын. Мен Postgresql-де кебулерге әкелетін қателерді ғана аламын. Әдетте, бұл сіздің жүйеңіздің жалпы өнімділігінің аяқталуының басы, бірақ бастапқыда бұл үшін ешқандай алғышарттар көрінбеді.
Барлығын қарсы алуға қуаныштымын! Бұл баяндама бұрынғы әріптесім сияқты техникалық емес. Бұл есеп негізінен серверлік жүйені әзірлеушілерге арналған, өйткені бізде клиенттердің саны өте көп. Және олардың барлығы бірдей қателіктер жасайды. Мен олар туралы айтып беремін. Мен бұл қателіктер қандай өлімге әкелетін және жаман нәрселерге әкелетінін түсіндіремін.
Неліктен қателіктер жіберіледі? Олар екі себеп бойынша жасалады: кездейсоқ, мүмкін ол жұмыс істейді және деректер базасы мен қолданба арасындағы деңгейде, сондай-ақ дерекқордың өзінде болатын кейбір механизмдерді білмеуден.
Мен сізге жаман нәрселердің қалай болғаны туралы қорқынышты суреттері бар үш мысал келтіремін. Мен сізге онда болатын механизм туралы қысқаша айтып беремін. Және олармен қалай күресуге болады, олар қашан болды және қателерді болдырмау үшін қандай профилактикалық әдістерді қолдану керек. Мен сізге көмекші құралдар туралы айтып, пайдалы сілтемелер беремін.
Мен екі кесте болған сынақ деректер базасын қолдандым. Бір тақтайшада клиент шоттары, екіншісінде осы шоттар бойынша транзакциялар бар. Және белгілі бір жиілікпен біз осы шоттардағы қалдықтарды жаңартып отырамыз.
Пластинаның бастапқы деректері: ол өте кішкентай, 2 МБ. Дерекқорға және әсіресе белгіге жауап беру уақыты өте жақсы. Және жеткілікті жақсы жүктеме - пластинаға сәйкес секундына 2 операция.
Осы есеп арқылы мен сізге не болып жатқанын анық түсіну үшін графиктерді көрсетемін. Әрқашан графиктері бар 2 слайд болады. Бірінші слайд - серверде жалпы не болып жатқаны.
Және бұл жағдайда біз шынымен кішкентай белгі бар екенін көреміз. Индекс шағын және 2 МБ. Бұл сол жақтағы бірінші график.
Сервердегі орташа жауап уақыты да тұрақты және қысқа. Бұл жоғарғы оң жақ диаграмма.
Төменгі сол жақ диаграмма ең ұзақ транзакцияларды көрсетеді. Біз транзакциялардың тез аяқталғанын көріп отырмыз. Бұл жерде автовакуум әлі жұмыс істемейді, өйткені бұл бастапқы сынақ болды. Ол жұмыс істей береді және бізге пайдалы болады.
Екінші слайд әрқашан сыналатын тақтаға арналады. Бұл жағдайда біз клиенттің шотындағы қалдықтарын үнемі жаңартып отырамыз. Жаңарту операциясының орташа жауап беру уақыты өте жақсы, миллисекундтан аз екенін көреміз. Біз процессор ресурстары (бұл жоғарғы оң жақ диаграмма) біркелкі және өте аз тұтынылатынын көреміз.
Төменгі оң жақ диаграмма оны жаңартудан бұрын қалаған жолды іздеу үшін қанша операциялық және дискілік жадтан өтетінімізді көрсетеді. Ал белгі бойынша амалдар саны мен басында айтқанымдай секундына 2.
Ал енді бізде қайғылы жағдай болды. Қандай да бір себептермен ұзақ уақыт ұмытылған транзакция бар. Себептер әдетте қарапайым:
- Ең кең таралғандардың бірі - біз қолданба кодындағы сыртқы қызметке қол жеткізе бастадық. Және бұл қызмет бізге жауап бермейді. Яғни, транзакцияны аштық, деректер базасына өзгеріс енгіздік және қосымшадан поштаны оқуға немесе инфрақұрылымымыздағы басқа қызметке өттік, қандай да бір себептермен ол бізге жауап бермейді. Ал сессиямыз қашан шешілетіні белгісіз күйде қалды.
- Екінші жағдай - біздің кодымызда қандай да бір себептермен ерекшелік орын алған кезде. Ал ерекше жағдайда біз транзакцияны жабуды өңдемедік. Және біз ашық мәмілемен ілулі сессиямен аяқталдық.
- Және соңғысы да жиі кездесетін жағдай. Бұл төмен сапалы код. Кейбір фреймворктар транзакцияны ашады. Ол ілулі тұрады және сіз қолданбада оның ілулі тұрғанын білмеуіңіз мүмкін.
Мұндай нәрселер қайда апарады?
Біздің кестелеріміз бен индекстеріміз күрт өсе бастайды. Бұл дәл сол кебу әсері. Мәліметтер қоры үшін бұл дерекқорға жауап беру уақыты өте күрт артады және дерекқор серверіне жүктеме артады дегенді білдіреді. Нәтижесінде біздің өтінішіміз зардап шегеді. Өйткені, дерекқорға сұрауға кодыңызда 10 миллисекунд жұмсаған болсаңыз, логикаға 10 миллисекунд жұмсаған болсаңыз, функцияны аяқтау үшін 20 миллисекунд қажет болды. Ал енді сіздің жағдайыңыз мүлде қайғылы болады.
Ал не болатынын көрейік. Төменгі сол жақ диаграмма бізде ұзақ ұзақ транзакция бар екенін көрсетеді. Ал жоғарғы сол жақ графикке қарасақ, кестеміздің өлшемі кенеттен екі мегабайттан 300 мегабайтқа дейін секіріп кеткенін көреміз. Сонымен қатар, кестедегі деректердің көлемі өзгерген жоқ, яғни қоқыстың айтарлықтай көп мөлшері бар.
Орташа сервердің жауап беру уақытына қатысты жалпы жағдай да бірнеше ретпен өзгерді. Яғни, сервердегі барлық сұраулар толығымен төмендей бастады. Сонымен қатар, бірдеңе жасауға тырысатын және ресурстарды тұтынатын автовакуум түрінде ішкі Postgres процестері іске қосылды.
Біздің белгіміз не болып жатыр? Бірдей. Белгіге сәйкес біздің орташа жауап беру уақытымыз бірнеше рет жоғарылады. Дәлірек айтқанда, тұтынылатын ресурстарға келетін болсақ, процессорға жүктеме айтарлықтай өскенін көреміз. Бұл жоғарғы оң жақ диаграмма. Және бұл өсті, өйткені процессор қажет жолдарды іздеу үшін қажетсіз сызықтарды сұрыптауы керек. Бұл төменгі оң жақ диаграмма. Нәтижесінде, біздің секундына қоңыраулар саны айтарлықтай төмендей бастады, өйткені деректер базасында сұраныстардың бірдей санын өңдеуге уақыты болмады.
Біз өмірге қайта оралуымыз керек. Біз Интернетке кіріп, ұзақ транзакциялар қиындықтарға әкелетінін білеміз. Біз бұл транзакцияны тауып, өлтіреміз. Ал біз үшін бәрі қалыпты жағдайға айналып барады. Барлығы керек сияқты жұмыс істейді.
Біз тыныштандырдық, бірақ біраз уақыттан кейін біз қосымшаның төтенше жағдайға дейінгі сияқты жұмыс істемейтінін байқай бастадық. Сұраулар әлі де баяу және айтарлықтай баяу өңделеді. Менің мысалда бір жарым-екі есе баяу. Сервердегі жүктеме апатқа дейінгіден де жоғары.
Және сұрақ: «Қазіргі уақытта базаға не болып жатыр?» Ал базамен келесі жағдай орын алады. Транзакция диаграммасында оның тоқтағанын және шынымен де ұзақ мерзімді транзакциялардың жоқтығын көруге болады. Бірақ апат кезінде белгінің өлшемі өлімге әкелді. Содан бері олар азайған жоқ. Базадағы орташа уақыт тұрақтанды. Жауаптар бізге қолайлы жылдамдықпен барабар болып жатқан сияқты. Автовакуум белсендірек болды және белгімен бірдеңе істей бастады, өйткені ол көбірек деректерді електен өткізуі керек.
Атап айтқанда, біз балансты өзгертетін шоттар бар сынақ тақтайшасына сәйкес: сұрауға жауап беру уақыты қалыпты жағдайға оралған сияқты. Бірақ іс жүзінде ол бір жарым есе жоғары.
Ал процессорға түсетін жүктемеден біз процессордағы жүктеме апатқа дейін қажетті мәнге оралмағанын көреміз. Оның себептері дәл төменгі оң жақ графикте жатыр. Онда жадтың белгілі бір көлемі ізделіп жатқанын көруге болады. Яғни, қажетті жолды табу үшін біз пайдасыз деректер арқылы сұрыптау кезінде деректер қоры серверінің ресурстарын ысырап етеміз. Секундына транзакциялар саны тұрақтанды.
Жалпы жақсы, бірақ жағдай бұрынғыдан да нашар. Осы дерекқормен жұмыс істейтін қолданбамыздың салдары ретінде дерекқордың нашарлауын жойыңыз.
Онда не болып жатқанын түсіну үшін, егер сіз алдыңғы баяндамада болмасаңыз, енді кішкене теорияны алайық. Ішкі процесс туралы теория. Неліктен автокөлік шаңсорғышы және ол не істейді?
Түсіну үшін сөзбе-сөз қысқаша. Бір уақытта бізде үстел бар. Бізде кестеде жолдар бар. Бұл сызықтар белсенді, тірі және қазір бізге қажет болуы мүмкін. Олар суретте жасыл түспен белгіленген. Ал қазірдің өзінде өңделген, жаңартылған және оларда жаңа жазбалар пайда болған өлі сызықтар бар. Және олар дерекқор үшін енді қызық емес деп белгіленеді. Бірақ олар Postgres мүмкіндігіне байланысты кестеде.
Сізге автокөлік шаңсорғышы не үшін қажет? Бір кезде автовакуум келіп, дерекқорға кіреді және одан: «Маған дерекқорда қазір ашылған ең ескі транзакцияның идентификаторын беріңізші» деп сұрайды. Дерекқор бұл идентификаторды қайтарады. Ал автовакуум соған сүйене отырып, кестедегі сызықтарды сұрыптайды. Ал егер ол кейбір жолдар әлдеқайда ескі транзакциялар арқылы өзгертілгенін көрсе, онда ол оларды жаңа деректерді жазу арқылы болашақта қайта пайдалануға болатын жолдар ретінде белгілеуге құқығы бар. Бұл фондық процесс.
Қазіргі уақытта біз деректер қорымен жұмысты жалғастырамыз және кестеге кейбір өзгерістер енгізуді жалғастырамыз. Ал біз қайта пайдалануға болатын осы жолдарға жаңа деректерді жазамыз. Осылайша біз цикл аламыз, яғни ол жерде үнемі өлі ескі сызықтар пайда болады, олардың орнына біз қажет жаңа жолдарды жазамыз. Бұл PostgreSQL жұмыс істеуі үшін қалыпты жағдай.
Апат кезінде не болды? Онда бұл процесс қалай болды?
Бізде белгілі бір жағдайда белгі болды, кейбіреулері тірі, кейбіреулері өлі сызықтар. Көлік шаңсорғышы келді. Ол дерекқордан біздің ең ескі транзакциямыз және оның идентификаторы қандай екенін сұрады. Мен бұл идентификаторды алдым, ол бірнеше сағат бұрын, мүмкін он минут бұрын болуы мүмкін. Бұл дерекқордағы жүктеменің қаншалықты ауыр екеніне байланысты. Және ол қайта пайдаланылған деп белгілей алатын сызықтарды іздеді. Ал мен кестемізден ондай сызықтарды таппадым.
Бірақ бұл уақытта біз үстелмен жұмысты жалғастырамыз. Біз онда бірдеңе жасаймыз, оны жаңартамыз, деректерді өзгертеміз. Деректер базасы осы уақытта не істеуі керек? Оның бар кестенің соңына жаңа жолдар қосудан басқа амалы жоқ. Осылайша біздің үстелдің көлемі ісінеді.
Іс жүзінде жұмыс істеу үшін бізге жасыл сызықтар қажет. Бірақ мұндай мәселе кезінде жасыл сызықтардың пайызы бүкіл кестеде өте төмен екендігі белгілі болды.
Ал сұранысты орындаған кезде мәліметтер базасы қажетті жолды табу үшін барлық жолдардан өтуі керек: қызыл да, жасыл да. Кестені пайдасыз деректермен толтыру әсері «блоат» деп аталады, ол да дискілік кеңістікті жейді. Есіңізде болсын, ол 2 МБ болды, ол 300 МБ болды? Енді мегабайттарды гигабайтқа ауыстырыңыз және сіз барлық диск ресурстарыңызды тез жоғалтасыз.
Біз үшін қандай салдары болуы мүмкін?
- Менің мысалда кесте мен индекс 150 есе өсті. Біздің кейбір клиенттерімізде дискілік кеңістік таусыла бастағанда өлімге әкелетін жағдайлар болды.
- Кестелердің өлшемі ешқашан төмендемейді. Автовакуум кейбір жағдайларда тек өлі сызықтар болса, үстелдің құйрығын кесіп тастауы мүмкін. Бірақ тұрақты айналу болғандықтан, бір жасыл сызық соңында қатып қалуы мүмкін және жаңартылмайды, ал қалғандарының бәрі пластинаның басында бір жерде жазылады. Бірақ бұл екіталай оқиға, сіздің үстеліңіздің өзі кішірейеді, сондықтан сіз оған үміт артпауыңыз керек.
- Деректер базасы пайдасыз жолдардың тұтас тобын сұрыптауы керек. Ал біз диск ресурстарын ысырап етеміз, процессор ресурстары мен электр энергиясын ысырап етеміз.
- Және бұл біздің қолданбамызға тікелей әсер етеді, өйткені егер біз бастапқыда сұрауға 10 миллисекунд, кодымызға 10 миллисекунд жұмсасақ, онда апат кезінде біз сұрауға бір секунд, ал кодқа 10 миллисекунд жұмсай бастадық, яғни. қолданба өнімділігінің шамасы төмендеді. Апат шешілгеннен кейін біз сұранысқа 20 миллисекунд, кодқа 10 миллисекунд жұмсай бастадық. Бұл біздің өнімділік бойынша әлі де бір жарым есе төмендегенімізді білдіреді. Мұның бәрі бір транзакцияның кесірінен, мүмкін біздің кінәмізден.
- Бізде бәрі жақсы және өтініштер апат алдындағыдай тез түсуі үшін: «Біз бәрін қалай қайтарамыз?» Деген сұрақ.
Осы мақсатта орындалатын жұмыстың белгілі бір циклі бар.
Алдымен біз ісінген проблемалық кестелерді табуымыз керек. Кейбір кестелерде жазба белсендірек, басқаларында азырақ екенін түсінеміз. Бұл үшін біз кеңейтімді қолданамыз . Бұл кеңейтімді орнату арқылы сіз әбден толтырылған кестелерді табуға көмектесетін сұрауларды жаза аласыз.
Осы кестелерді тапқаннан кейін оларды қысу керек. Бұл үшін қазірдің өзінде құралдар бар. Біздің компанияда біз үш құралды пайдаланамыз. Біріншісі - кіріктірілген VACUUM FULL. Ол қатыгез, қатал және мейірімсіз, бірақ кейде ол өте пайдалы. и - Бұл кестелерді қысуға арналған үшінші тарап утилиталары. Және олар дерекқорды мұқият қарастырады.
Олар сізге не ыңғайлы екеніне байланысты пайдаланылады. Бірақ мен бұл туралы ең соңында айтамын. Ең бастысы, үш құрал бар. Таңдау үшін көп нәрсе бар.
Барлығын түзетіп, бәрі жақсы екеніне көз жеткізгеннен кейін, біз болашақта бұл жағдайдың алдын алуды білуіміз керек:
- Оның алдын алуға өте оңай. Негізгі сервердегі сеанстардың ұзақтығын бақылау керек. Транзакция күйіндегі бос күйдегі әсіресе қауіпті сеанстар. Бұл жай ғана транзакцияны ашып, бірдеңе жасап, кетіп қалған немесе жай ғана ілулі тұрған, кодта адасып қалғандар.
- Ал сіз үшін әзірлеушілер ретінде осы жағдайлар туындаған кезде кодты сынау маңызды. Мұны істеу қиын емес. Бұл пайдалы тексеру болады. Ұзақ транзакцияларға байланысты көптеген «балалық» мәселелерден аулақ боласыз.
Бұл графиктерде мен бұл жағдайда VACUUM FULL белгісінен өткеннен кейін дерекқордың белгісі мен әрекетінің қалай өзгергенін көрсеткім келді. Бұл мен үшін өндіріс емес.
Кесте өлшемі бірден бірнеше мегабайттық қалыпты жұмыс күйіне оралды. Бұл сервердің орташа жауап беру уақытына қатты әсер еткен жоқ.
Бірақ біз тіркелгі қалдықтарын жаңартқан сынақ белгісі үшін, біз белгідегі деректерді жаңарту сұрауына орташа жауап беру уақыты төтенше жағдайға дейінгі деңгейге дейін қысқарғанын көреміз. Бұл сұрауды орындау үшін процессор тұтынатын ресурстар да бұзылу алдындағы деңгейге дейін төмендеді. Төменгі оң жақ графикте кесте қысылғанға дейін болған өлі сызықтардың үйінділерінен өтпей-ақ, дәл қазір бізге қажет сызықты табатынымызды көрсетеді. Ал орташа сұрау уақыты шамамен бірдей деңгейде қалды. Бірақ бұл жерде менің аппараттық құралымда қате бар.
Осы жерде бірінші оқиға аяқталады. Бұл ең көп таралған. Бұл клиенттің тәжірибесіне және бағдарламашылардың қаншалықты біліктілігіне қарамастан, барлығында болады. Ерте ме, кеш пе, бұл орын алады.
Екінші оқиға, онда біз жүктемені таратамыз және сервер ресурстарын оңтайландырамыз
- Есейіп, байсалды жігіт болдық. Бізде көшірме бар екенін түсінеміз және жүктемені теңестіру бізге жақсы болар еді: Мастерге жазыңыз және репликадан оқыңыз. Әдетте бұл жағдай кейбір есептерді немесе ETL дайындағымыз келгенде туындайды. Ал бизнес бұған өте қуанышты. Ол шынымен де күрделі аналитикасы бар әртүрлі есептерді қалайды.
- Есептер көп сағатты алады, себебі күрделі аналитиканы миллисекундтармен есептеу мүмкін емес. Біз батыл жігіттер сияқты код жазамыз. Кірістіру қолданбасында біз Мастердегі жазбаны жасаймыз және репликада есептерді орындаймыз.
- Жүктемені бөлу.
- Барлығы тамаша жұмыс істейді. Біз кереметпіз.
Және бұл жағдай қалай көрінеді? Атап айтқанда, осы графиктерде мен транзакция ұзақтығына көшірмедегі транзакциялардың ұзақтығын қостым. Барлық басқа графиктер тек негізгі серверге сілтеме жасайды.
Бұл кезде менің есеп беру тақтам өсті. Олардың саны көбірек. Біз сервердің орташа жауап беру уақыты тұрақты екенін көреміз. Біз репликада бізде 2 сағатқа созылатын ұзақ мерзімді транзакция бар екенін көреміз. Біз өлі сызықтарды өңдейтін автовакуумның тыныш жұмысын көреміз. Ал бізде бәрі жақсы.
Нақтырақ айтқанда, сынақтан өткен тақтайшаға сәйкес, біз шоттағы қалдықтарды жаңартуды жалғастырамыз. Сондай-ақ бізде сұраныстарға тұрақты жауап беру уақыты, тұрақты ресурстарды тұтыну бар. Бізде бәрі жақсы.
Бұл есептер репликациямен қайшылыққа байланысты қайта іске қосыла бастағанға дейін бәрі жақсы. Және олар белгілі бір уақыт аралығында оқ жаудырады.
Біз желіге кіріп, неге бұлай болып жатқанын оқи бастаймыз. Ал біз шешімін табамыз.
Бірінші шешім - репликацияның кешігуін арттыру. Біздің есеп 3 сағатқа созылатынын білеміз. Біз репликация кідірісін 3 сағатқа орнаттық. Біз барлығын іске қосып жатырмыз, бірақ бізде есептердің кейде жойылуына байланысты проблемалар әлі де бар.
Біз бәрі мінсіз болғанын қалаймыз. Біз одан әрі көтерілеміз. Біз Интернетте керемет параметрді таптық - hot_standby_feedback. Оны қосайық. Hot_standby_feedback бізге Мастердегі автовакуумды ұстап тұруға мүмкіндік береді. Осылайша, біз репликация қақтығыстарынан толығымен құтыламыз. Және есептермен бәрі біз үшін жақсы жұмыс істейді.
Қазіргі уақытта негізгі серверде не болып жатыр? Ал бізде Мастер сервермен мүлде қиындық туындады. Енді менде осы параметрлердің екеуі де қосылған кезде графиктерді көріп отырмыз. Біздің репликадағы сеанс қандай да бір түрде Мастер сервердегі жағдайға әсер ете бастағанын көреміз. Оның әсері бар, өйткені ол өлі сызықтарды кетіретін автовакуумды тоқтатты. Дастарханымыздың көлемі тағы да шарықтап кетті. Бүкіл дерекқордағы орташа сұранысты орындау уақыты да күрт өсті. Автовакуумдар аздап күшейтілді.
Нақтырақ айтқанда, біздің пластинадан біз ондағы деректердің жаңартылғанын да аспанға секіргенін көреміз. Процессорды тұтыну да осылайша айтарлықтай өсті. Біз тағы да көптеген өлі, пайдасыз желілерден өтіп жатырмыз. Және бұл белгіге жауап беру уақыты мен транзакциялар саны азайды.
Бұрын не туралы айтқанымды білмесек, бұл қалай болады?
- Біз проблемаларды іздей бастаймыз. Егер біз бірінші бөлімде қиындықтарға тап болсақ, бұл ұзақ транзакцияға байланысты болуы мүмкін екенін білеміз және Мастерге барамыз. Бізде Мастер мәселесі бар. Оған шұжық жасайды. Ол қызады, оның орташа жүктемесі жүзге жуық.
- Сұраныстар баяу, бірақ біз ұзаққа созылған транзакцияларды көрмейміз. Ал біз не болғанын түсінбейміз. Қайдан іздеу керектігін түсінбейміз.
- Біз серверлік жабдықты тексереміз. Мүмкін біздің рейдіміз апатқа ұшыраған шығар. Бәлкім, біздің жад картасы өртеніп кеткен шығар. Иә, бәрі болуы мүмкін. Бірақ жоқ, серверлер жаңа, бәрі жақсы жұмыс істейді.
- Барлығы жұмыс істейді: әкімшілер, әзірлеушілер және директор. Ештеңе көмектеспейді.
- Және бір сәтте бәрі кенеттен түзеле бастайды.
Осы уақытта біздің көшірмедегі сұраныс өңделіп, қалдырылды. Біз есеп алдық. Бизнес әлі де бақытты. Өздеріңіз көріп отырғандай, біздің белгі тағы да өсті, азаймақ емес. Жағдай тұрақтанғанша қанша уақыт кететінін бағалау үшін сеанстары бар графикте мен көшірмеден осы ұзақ транзакцияның бір бөлігін қалдырдым.
Сессия аяқталды. Тек біраз уақыттан кейін сервер азды-көпті ретке келеді. Ал негізгі сервердегі сұрауларға орташа жауап беру уақыты қалыпты жағдайға оралады. Өйткені, сайып келгенде, автовакуумда бұл өлі сызықтарды тазалау және белгілеу мүмкіндігі бар. Және ол өз жұмысын істей бастады. Және ол мұны қаншалықты тез орындаса, біз тез тәртіпке келеміз.
Тестіленген планшетке сәйкес, біз шоттардағы қалдықтарды жаңартамыз, біз дәл сол суретті көреміз. Есептік жазбаны жаңартудың орташа уақыты да бірте-бірте қалыпқа келеді. Процессор тұтынатын ресурстар да азаяды. Ал секундына транзакциялар саны қалыпты жағдайға оралады. Бірақ біз қайтадан қалыпты жағдайға оралдық, апатқа дейінгі жағдайдағыдай емес.
Қалай болғанда да, біз бірінші жағдайдағыдай, бір жарым-екі есе, ал кейде одан да көп өнімділікті аламыз.
Біз бәрін дұрыс жасаған сияқтымыз. Жүктемені таратыңыз. Жабдық бос тұрған жоқ. Өтініштерді санамызға қарай бөлдік, бірақ бәрібір бәрі жаман болып шықты.
- hot_standby_feedback қосылмай ма? Иә, оны ерекше себептерсіз қосу ұсынылмайды. Өйткені бұл бұралу басты серверге тікелей әсер етіп, ондағы автовакуумның жұмысын тоқтатады. Оны кейбір репликада қосу және бұл туралы ұмыту арқылы сіз Мастерді өлтіріп, қолданбада үлкен мәселелерге тап бола аласыз.
- Максималды_күту режиміндегі_ағынды_кідіртуді көбейту керек пе? Иә, есептер үшін бұл шындық. Егер сізде үш сағаттық есеп болса және оның репликация қайшылықтарына байланысты бұзылғанын қаламасаңыз, кешіктіруді көбейтіңіз. Ұзақ мерзімді есеп ешқашан дерекқорға дәл қазір келген деректерді талап етпейді. Егер сізде үш сағат болса, оны ескі деректер кезеңі үшін іске қосып жатырсыз. Ал сіз үшін үш сағаттық кешіктіру немесе алты сағаттық кешіктіру маңызды емес, бірақ сіз есептерді дәйекті түрде аласыз және олардың құлауымен ешқандай проблемалар болмайды.
- Әрине, көшірмелердегі ұзақ сеанстарды басқару қажет, әсіресе репликада hot_standby_feedback қосуды шешсеңіз. Өйткені бәрі болуы мүмкін. Біз бұл көшірмені әзірлеушіге сұраныстарды тексере алуы үшін бердік. Ол ақылсыз өтініш жазды. Ол оны іске қосып, шай ішуге кетті, ал біз қалыптасқан Мастерді алдық. Немесе біз дұрыс қолданбаған шығармыз. Жағдайлар әртүрлі. Көшірмелердегі сеанстарды Мастердегідей мұқият бақылау керек.
- Егер сізде репликаларға жылдам және ұзақ сұраулар болса, онда бұл жағдайда жүктемені тарату үшін оларды бөлген дұрыс. Бұл streaming_delay сілтемесі. Жылдамдар үшін шағылыстырудың аз кідірісі бар бір көшірме болуы керек. Ұзақ жұмыс істейтін есеп беру сұраулары үшін 6 сағатқа немесе бір күнге кешігуі мүмкін көшірмеге ие болыңыз. Бұл мүлдем қалыпты жағдай.
Біз зардаптарды дәл осылай жоямыз:
- Біз ісінген үстелдерді табамыз.
- Ал біз оны өзімізге қолайлы ең қолайлы құралмен қысамыз.
Екінші әңгіме осында аяқталады. Үшінші әңгімеге көшейік.
Көші-қонды жүзеге асыратын біз үшін де әдеттегідей.
- Кез келген бағдарламалық өнім өсіп келеді. Оған қойылатын талаптар өзгеруде. Қалай болғанда да біз дамытқымыз келеді. Бізге кестедегі деректерді жаңарту, атап айтқанда әзірлеуіміздің бір бөлігі ретінде енгізіп жатқан жаңа функционалдылыққа тасымалдау тұрғысынан жаңартуды іске қосу қажет болады.
- Ескі деректер пішімі қанағаттанарлық емес. Енді осы шоттар бойынша операцияларым бар екінші кестеге көшеміз делік. Айталық, олар рубльде болды, біз дәлдікті арттырып, оны копейкпен жасауды шештік. Бұл үшін біз жаңартуды жасауымыз керек: транзакция сомасы бар өрісті жүзге көбейтіңіз.
- Қазіргі әлемде біз деректер базасының нұсқасын басқарудың автоматтандырылған құралдарын пайдаланамыз. Айтайық . Біз көші-қонымызды сонда тіркейміз. Біз оны сынақ базасында сынаймыз. Барлығы керемет. Жаңарту жүріп жатыр. Ол жұмысты біраз уақытқа блоктайды, бірақ біз жаңартылған деректерді аламыз. Біз бұл үшін жаңа функцияны іске қоса аламыз. Барлығы тексеріліп, тексерілді. Барлығы расталды.
- Жоспарлы жұмыстарды атқарып, көші-қонды жүзеге асырдық.
Міне, сіздің алдыңызда ұсынылған жаңарту бар көшіру. Бұл менің шотым транзакциялары болғандықтан, пластина 15 ГБ болды. Әр жолды жаңартқандықтан, біз жаңартумен кестенің өлшемін екі есе арттырдық, өйткені біз әрбір жолды қайта жаздық.
Тасымалдау кезінде біз бұл тақтамен ештеңе істей алмадық, өйткені оған барлық сұраулар кезекке қойылып, жаңарту аяқталғанша күттік. Бірақ бұл жерде мен сіздің назарыңызды тік осьте орналасқан сандарға аударғым келеді. Яғни, бізде шамамен 5 миллисекундтық көшіру және процессорды жүктеуге дейінгі орташа сұрау уақыты бар, диск жадын оқуға арналған блок операцияларының саны 7,5-тен аз.
Көші-қонды жүзеге асырдық, тағы да қиындықтар туындады.
Көшіру сәтті болды, бірақ:
- Ескі функцияны аяқтау үшін енді ұзағырақ уақыт қажет.
- Үстел тағы да үлкейді.
- Сервердегі жүктеме бұрынғыға қарағанда қайта артты.
- Және, әрине, біз әлі де жақсы жұмыс істеген функционалдықпен айналысамыз, біз оны аздап жақсарттық.
Бұл тағы да біздің өмірімізді бұзатын ісік.
Мұнда мен кестенің алдыңғы екі жағдай сияқты бұрынғы өлшемдеріне оралмайтынын көрсетемін. Орташа сервер жүктемесі жеткілікті сияқты.
Ал егер шоттары бар кестеге жүгінсек, бұл кесте үшін сұраныстың орташа уақыты екі есеге артқанын көреміз. Процессорға жүктеме және жадта сұрыпталған жолдар саны 7,5-тен жоғары секірді, бірақ төмен болды. Бұл процессорлар жағдайында 2 есе, блоктық операциялар жағдайында 1,5 есе секірді, яғни сервер өнімділігінің нашарлауына ұшырадық. Нәтижесінде - біздің қолданбаның өнімділігінің нашарлауы. Сонымен бірге, қоңыраулар саны шамамен бір деңгейде қалды.
Мұнда ең бастысы - мұндай көші-қонды қалай дұрыс жасау керектігін түсіну. Және оларды орындау керек. Біз бұл көші-қонды дәйекті түрде жасаймыз.
- Мұндай үлкен көші-қон автоматты түрде болмайды. Олар әрқашан бақылауда болуы керек.
- Білімді адамның бақылауы қажет. Егер сіздің командаңызда DBA болса, оны DBA-ға беріңіз. Оның жұмысы. Егер олай болмаса, онда мәліметтер базасымен жұмыс істеуді білетін ең тәжірибелі адам жасасын.
- Жаңа дерекқор схемасы, тіпті бір бағанды жаңартқанның өзінде, біз әрқашан кезең-кезеңімен, яғни қосымшаның жаңа нұсқасы шығарылғанға дейін алдын ала дайындаламыз:
- Жаңа өрістер қосылды, онда біз жаңартылған деректерді жазамыз.
- Біз деректерді ескі өрістен жаңа өріске шағын бөліктермен тасымалдаймыз. Неліктен біз мұны істеп жатырмыз? Біріншіден, біз әрқашан осы процестің процесін бақылап отырамыз. Біз қазірдің өзінде көптеген партияларды ауыстырғанымызды білеміз және бізде көп қалды.
- Ал екінші оң нәтиже - әрбір осындай партияның арасында транзакцияны жабамыз, жаңасын ашамыз және бұл автовакуумның пластинаға сәйкес жұмыс істеуіне, қайта пайдалану үшін өлі сызықтарды белгілеуге мүмкіндік береді.
- Қолданба жұмыс істеп тұрған кезде пайда болатын жолдар үшін (бізде әлі де ескі қолданба жұмыс істейді), біз жаңа өрістерге жаңа мәндерді жазатын триггерді қосамыз. Біздің жағдайда бұл ескі мәннің жүзге көбейту.
- Егер біз толықтай қыңыр болсақ және бірдей өрісті қаласақ, онда барлық тасымалдаулар аяқталғаннан кейін және қолданбаның жаңа нұсқасын шығарар алдында өрістердің атын жай ғана өзгертеміз. Ескілерге кейбір ойлап шығарылған атаулар беріледі, ал жаңа өрістер ескілеріне қайта аталды.
- Осыдан кейін ғана біз қосымшаның жаңа нұсқасын іске қосамыз.
Сонымен қатар, біз ісінбейміз және өнімділік жағынан зардап шекпейміз.
Осы жерде үшінші оқиға аяқталады.
Енді мен бірінші әңгімеде айтқан құралдар туралы аздап толығырақ.
Bloat іздеуден бұрын кеңейтімді орнату керек .
Сұрауларды ойлап таппау үшін біз бұл сұрауларды өз жұмысымызда жазғанбыз. Сіз оларды пайдалана аласыз. Мұнда екі өтініш бар.
- Біріншісі жұмыс істеу үшін өте көп уақытты алады, бірақ ол сізге кестедегі нақты шамадан тыс мәндерді көрсетеді.
- Екіншісі тезірек жұмыс істейді және кесте бойынша ісіну бар-жоғын жылдам бағалау қажет болғанда өте тиімді. Сондай-ақ, ісіну Postgres кестесінде әрқашан болатынын түсінуіңіз керек. Бұл оның MVCC үлгісінің ерекшелігі.
- Ал 20% кебулер көп жағдайда кестелер үшін қалыпты жағдай. Яғни, сіз бұл кестені алаңдатып, қыспауыңыз керек.
Біз пайдасыз деректермен ісінген кестелерді қалай анықтау керектігін анықтадық.
Енді ісінуді қалай түзетуге болатыны туралы:
- Егер бізде кішкентай планшет пен жақсы дискілер болса, яғни гигабайтқа дейінгі планшетте VACUUM FULL қолдануға әбден болады. Ол бірнеше секундқа үстелде сізден эксклюзивті құлыпты алады және жарайды, бірақ ол бәрін тез және қатал жасайды. VACUUM FULL не істейді? Ол үстелде эксклюзивті құлыпты алады және ескі кестелерден жаңа кестеге тірі жолдарды қайта жазады. Ал соңында ол оларды ауыстырады. Ол ескі файлдарды жояды және ескілерін жаңасымен ауыстырады. Бірақ жұмыс уақытында ол үстелге эксклюзивті құлыпты алады. Бұл осы кестемен ештеңе істей алмайтыныңызды білдіреді: оған жазуға да, оқуға да, өзгертуге де болмайды. Ал VACUUM FULL деректерді жазу үшін қосымша дискілік кеңістікті қажет етеді.
- Келесі құрал . Өзінің принципі бойынша ол VACUUM FULL-ге өте ұқсас, өйткені ол сонымен қатар ескі файлдардағы деректерді жаңасына қайта жазады және оларды кестеде ауыстырады. Бірақ сонымен бірге ол жұмысының басында үстелде эксклюзивті құлыпты қабылдамайды, оны файлдарды ауыстыру үшін дайын деректер болған кезде ғана қабылдайды. Оның диск ресурсына қойылатын талаптар VACUUM FULL талаптарына ұқсас. Сізге қосымша дискілік кеңістік қажет және терабайт кестелеріңіз болса, бұл кейде өте маңызды. Және ол процессорды қажет етеді, өйткені ол енгізу/шығарумен белсенді жұмыс істейді.
- Үшінші утилита . Ол ресурстарға аса сақтықпен қарайды, себебі ол басқаша принциптерге сәйкес жұмыс істейді. pgcompacttable бағдарламасының негізгі идеясы - ол кестедегі жаңартуларды пайдалана отырып, барлық тірі жолдарды кестенің басына жылжытады. Содан кейін ол осы үстелде вакуумды іске қосады, өйткені біз басында тірі жолдар және соңында өлі жолдар бар екенін білеміз. Ал вакуумның өзі бұл құйрықты кесіп тастайды, яғни ол қосымша дискілік кеңістікті қажет етпейді. Сонымен қатар, ол әлі де ресурстар тұрғысынан қысылуы мүмкін.
Барлығы құралдармен.
Егер сіз ішке қарай тереңдетілген тақырыпты қызықты деп тапсаңыз, мұнда бірнеше пайдалы сілтемелер берілген:
- – Бұл менің әріптесімнің баяндамасы. Бұл Postgres кеңістігі оның жұмысы мен өмірінде қайда жүретіні туралы жалпы. Дерекқор әкімшілері үшін bloat туралы өте үлкен және егжей-тегжейлі техникалық бөлік бар.
- – бұл дерекқордың күйін тексеруге арналған көптеген пайдалы сценарийлерді сақтайтын репозиторийімізге сілтеме. Онда сіз bloat іздеуге арналған сценарийлерді таба аласыз.
- и белгілерді азайтуға көмектесетін құралдарға сілтемелер.
- – бұл менің әріптесімнің жазбасы. Онда ол айтарлықтай байыпты және техникалық жағынан әкімшілерге жақын деңгейде кебулерді егжей-тегжейлі талдайды.
Мен әзірлеушілерге қорқынышты оқиғаны көрсетуге көбірек тырыстым, өйткені олар біздің деректер базасының тікелей клиенттері және не және қандай әрекеттерге әкелетінін түсінуі керек. Мен табысқа жеттім деп үміттенемін. Назарларыңызға рахмет!
Сіздің сұрақтарыңыз
Есеп үшін рахмет! Сіз проблемаларды қалай анықтауға болатынын айттыңыз. Оларға қалай ескерту жасауға болады? Яғни, менде сұраулар кейбір сыртқы қызметтерге қол жеткізгендіктен ғана ілініп тұратын жағдай болды. Бұл жай ғана кейбір жабайы қосылыстар болды. Кішкентай, зиянсыз өтініштер бір күн бойы ілулі тұрды, содан кейін кейбір мағынасыз істерді бастады. Яғни, сіз сипаттағанға өте ұқсас. Мұны қалай қадағалауға болады? Қай сұраныстың тұрып қалғанын үнемі бақылап отырыңыз ба? Мұны қалай болдырмауға болады?
Бұл жағдайда бұл DBA үшін міндетті емес, сіздің компанияңыздың әкімшілеріне арналған тапсырма.
Мен әкімшімін.
PostgreSQL-де ілулі сұрауларды көрсететін pg_stat_activity деп аталатын көрініс бар. Ол жерде қанша уақыт ілулі тұрғанын көруге болады.
Мен әр 5 минут сайын кіріп, қарауым керек пе?
Cron орнатып, тексеріңіз. Ұзақ мерзімді сұрауыңыз болса, хат жазыңыз, сонда болды. Яғни, көзбен қараудың қажеті жоқ, оны автоматтандыруға болады. Сізге хат келеді, сіз оған жауап бересіз. Немесе автоматты түрде түсіруге болады.
Мұның орын алуының айқын себептері бар ма?
Мен кейбірін тізіп қойдым. Басқа күрделі мысалдар. Және ұзақ уақыт әңгіме болуы мүмкін.
Есеп үшін рахмет! Мен pg_repack утилитасы туралы түсіндіргім келді. Егер ол эксклюзивті құлыптамаса, онда...
Ол эксклюзивті құлып жасайды.
... онда мен деректерді жоғалтуым мүмкін. Осы уақыт ішінде менің өтінішім ештеңе жазбауы керек пе?
Жоқ, ол кестемен бірқалыпты жұмыс істейді, яғни pg_repack алдымен бар барлық тірі жолдарды тасымалдайды. Әрине, кестеге кірудің қандай да бір түрі сонда болады. Ол бұл ат құйрығын лақтырып жатыр.
Яғни, ол мұны ақыр соңында жасайды ма?
Соңында, ол осы файлдарды ауыстыру үшін эксклюзивті құлыпты алады.
Ол VACUUM FULL қарағанда жылдамырақ бола ма?
VACUUM FULL, ол басталған бойда бірден эксклюзивті құлыпты алды. Және ол бәрін жасамайынша, ол оны жібермейді. Ал pg_repack эксклюзивті құлыпты тек файлды ауыстыру кезінде алады. Осы сәтте сіз онда жазбайсыз, бірақ деректер жоғалмайды, бәрі жақсы болады.
Сәлеметсіз бе! Сіз автокөлік шаңсорғышының жұмысы туралы айттыңыз. Қызыл, сары және жасыл жазу ұяшықтары бар график болды. Яғни, сары түсті – ол жойылған деп белгіледі. Нәтижесінде оларға жаңа нәрсе жазуға болады ма?
Иә. Postgres жолдарды жоймайды. Оның осындай ерекшелігі бар. Егер біз жолды жаңартқан болсақ, ескісін жойылған деп белгіледік. Осы жолды өзгерткен транзакцияның идентификаторы сонда пайда болады және біз жаңа жолды жазамыз. Бізде оларды оқи алатын сеанстар бар. Бір кездері олар әбден қартаяды. Ал автовакуумның жұмысының мәні мынада, ол осы сызықтар арқылы өтіп, оларды қажетсіз деп белгілейді. Және сол жерде деректерді қайта жазуға болады.
Мен түсіндім. Бірақ бұл сұраққа қатысты емес. Мен аяқтамадым. Бізде үстел бар делік. Оның айнымалы өлшемді өрістері бар. Ал егер мен жаңа нәрсе енгізейін десем, ол жай ғана ескі ұяшыққа сәйкес келмеуі мүмкін.
Жоқ, кез келген жағдайда бүкіл сызық сонда жаңартылады. Postgres-те деректерді сақтаудың екі үлгісі бар. Ол деректер түрінен таңдайды. Тікелей кестеде сақталатын деректер бар, сонымен қатар tos деректері бар. Бұл деректердің үлкен көлемі: мәтін, json. Олар бөлек табақтарда сақталады. Және бұл таблеткаларға сәйкес, ісінумен бірдей оқиға орын алады, яғни бәрі бірдей. Олар жай ғана бөлек тізімделген.
Есеп үшін рахмет! Ұзақтығын шектеу үшін мәлімдеме күту уақыты сұрауларын пайдалану қолайлы ма?
Өте қолайлы. Біз мұны барлық жерде қолданамыз. Біздің жеке қызметтеріміз болмағандықтан, қашықтан қолдау көрсетеміз, бізде көптеген клиенттер бар. Және бәрі бұған толығымен қанағаттанады. Яғни, бізде тексеретін cron тапсырмалары бар. Сеанстардың ұзақтығы клиентпен жай ғана келісіледі, оған дейін біз келіспейміз. Бұл бір минут болуы мүмкін, 10 минут болуы мүмкін. Бұл негізге түсетін жүктемеге және оның мақсатына байланысты. Бірақ бәріміз pg_stat_activity пайдаланамыз.
Есеп үшін рахмет! Мен сіздің есебіңізді қолданбаларыма қолдануға тырысамын. Біз транзакцияны барлық жерде бастайтын сияқтымыз және оны барлық жерде анық аяқтаймыз. Қандай да бір ерекшелік болса, кері қайтару әлі де орын алады. Сосын мен ойлана бастадым. Өйткені, транзакция анық басталмауы мүмкін. Бұл қызға нұсқау болса керек. Жазбаны жай ғана жаңартсам, транзакция PostgreSQL жүйесінде басталып, қосылым ажыратылғанда ғана аяқталады ма?
Егер сіз қазір қолданба деңгейі туралы айтып жатсаңыз, ол сіз пайдаланып жатқан драйверге, пайдаланылатын ORM жүйесіне байланысты. Онда көптеген параметрлер бар. Автоматты міндеттеме қосулы болса, транзакция сол жерден басталып, дереу жабылады.
Яғни, жаңартудан кейін бірден жабылады?
Бұл параметрлерге байланысты. Мен бір параметрді атадым. Бұл автоматты түрде қосу. Бұл өте жиі кездеседі. Егер ол қосылса, транзакция ашылды және жабылды. Егер сіз «транзакцияны бастау» және «транзакцияны аяқтау» деп нақты айтпасаңыз, бірақ жай ғана сеансқа сұрау жіберсеңіз.
Сәлеметсіз бе! Есеп үшін рахмет! Бізде ісініп, ісіп жатқан дерекқор бар деп елестетіп көрейік, содан кейін сервердегі бос орын таусылады. Бұл жағдайды түзетуге арналған құралдар бар ма?
Сервердегі бос орынды дұрыс бақылау керек.
Мысалы, DBA шайға барды, курортта болды және т.б.
Файлдық жүйе жасалғанда, деректер жазылмаған жерде кем дегенде қандай да бір резервтік кеңістік жасалады.
Егер ол толығымен нөлден төмен болса ше?
Онда ол резервтік кеңістік деп аталады, яғни оны босатуға болады және оның қаншалықты үлкен болғанына байланысты сіз бос орын аласыз. Әдепкі бойынша мен олардың қанша екенін білмеймін. Ал басқа жағдайда реконструкциялық операцияны орындауға орын болатындай дискілерді жеткізіңіз. Қажет болмайтынына кепілдік берілген кестені жоюға болады.
Басқа құралдар бар ма?
Ол әрқашан қолдан жасалған. Жергілікті жерде ол жерде не істеу жақсы екені белгілі болады, өйткені кейбір деректер маңызды, ал кейбіреулері маңызды емес. Және әрбір дерекқор және онымен жұмыс істейтін қолданба үшін бұл бизнеске байланысты. Ол әрқашан жергілікті жерде шешіледі.
Есеп үшін рахмет! Менің екі сұрағым бар. Біріншіден, транзакциялар тоқтап қалғанда кесте кеңістігі өлшемі де, индекс өлшемі де өсетінін көрсететін слайдтарды көрсеттіңіз. Әрі қарай есепте планшетті орайтын көптеген утилиталар болды. Ал индекс туралы не деуге болады?
Оларды да жинайды.
Бірақ вакуум индекске әсер етпейді ме?
Кейбіреулер индекспен жұмыс істейді. Мысалы, pg_rapack, pgcompacttable. Вакуум индекстерді қайта жасайды және оларға әсер етеді. VACUUM FULL көмегімен барлығын қайта жазу идеясы бар, яғни ол барлығымен жұмыс істейді.
Ал екінші сұрақ. Мен репликалар туралы есептердің неге репликацияның өзіне тәуелді екенін түсінбеймін. Маған есептер оқылады, ал репликация жазылады деп көрінді.
Көшіру қайшылығы неден туындайды? Бізде процестер жүріп жатқан Мастер бар. Бізде көлікті сору жүріп жатыр. Автовакуум шынымен не істейді? Ол ескі жолдарды кесіп тастайды. Егер осы уақытта бізде осы ескі жолдарды оқитын репликаға сұраныс болса және Мастерде автовакуум бұл жолдарды қайта жазу үшін мүмкіндігінше белгілеген жағдай орын алса, біз оларды қайта жаздық. Біз деректер пакетін алдық, репликада сұрауға қажет жолдарды қайта жазу қажет болғанда, репликация процесі сіз конфигурациялаған күту уақытын күтеді. Содан кейін PostgreSQL оған не маңыздырақ екенін шешеді. Ол үшін сұраудан гөрі репликация маңыздырақ және ол репликада осы өзгерістерді енгізу үшін сұрауды түсіреді.
Андрей, менің сұрағым бар. Тұсаукесер кезінде сіз көрсеткен керемет графиктер, бұл сіздің қандай да бір утилитаңыздың жұмысының нәтижесі ме? Графиктер қалай жасалды?
Бұл қызмет .
Бұл коммерциялық өнім ме?
Иә. Бұл коммерциялық өнім.
Ақпарат көзі: www.habr.com