PostgreSQL մոնիտորինգի հիմունքները. Ալեքսեյ Լեսովսկի

Առաջարկում եմ կարդալ Ալեքսեյ Լեսովսկու զեկույցի սղագրությունը Data Egret-ից «PostgreSQL մոնիտորինգի հիմունքները»

Այս զեկույցում Ալեքսեյ Լեսովսկին կխոսի հետգրեսական վիճակագրության առանցքային կետերի մասին, թե դրանք ինչ են նշանակում և ինչու պետք է ներկա գտնվեն մոնիտորինգին. այն մասին, թե ինչ գրաֆիկներ պետք է լինեն մոնիտորինգում, ինչպես ավելացնել դրանք և ինչպես մեկնաբանել դրանք: Զեկույցը օգտակար կլինի տվյալների բազայի ադմինիստրատորների, համակարգի ադմինիստրատորների և մշակողների համար, ովքեր հետաքրքրված են Postgres-ի անսարքությունների վերացմամբ:

Ես Ալեքսեյ Լեսովսկին եմ, ներկայացնում եմ Data Egret ընկերությունը։

Մի քանի խոսք իմ մասին. Ես սկսել եմ աշխատել շատ վաղուց՝ որպես համակարգի ադմինիստրատոր:

Ես կառավարում էի Linux-ի բոլոր տեսակի համակարգերը, աշխատում էի Linux-ի հետ կապված տարբեր բաների վրա, օրինակ՝ վիրտուալացում, մոնիտորինգ, աշխատում էի պրոքսիների հետ և այլն: Բայց ինչ-որ պահի ես սկսեցի ավելի շատ աշխատել տվյալների բազաների, PostgreSQL-ի հետ: Ինձ շատ դուր եկավ նա։ Եվ ինչ-որ պահի ես սկսեցի աշխատել PostgreSQL-ով իմ աշխատանքային ժամանակի մեծ մասը: Եվ այսպես աստիճանաբար ես դարձա PostgreSQL DBA:

Եվ իմ կարիերայի ընթացքում ինձ միշտ հետաքրքրել են վիճակագրության, մոնիտորինգի և հեռաչափության թեմաները: Եվ երբ ես համակարգի ադմինիստրատոր էի, ես շատ սերտ համագործակցում էի Zabbix-ի հետ: Եվ ես գրեցի մի փոքր շարք սցենարներ, ինչպիսիք են zabbix-extensions. Նա բավականին հայտնի էր իր ժամանակներում։ Եվ այնտեղ հնարավոր էր վերահսկել շատ տարբեր կարևոր բաներ, ոչ միայն Linux, այլ նաև տարբեր բաղադրիչներ։

Այժմ ես աշխատում եմ PostgreSQL-ի վրա: Ես արդեն գրում եմ մեկ այլ բան, որը թույլ է տալիս աշխատել PostgreSQL վիճակագրության հետ: Այն կոչվում է pgCenter (հոդված Habré - Հետգրես վիճակագրություն առանց նյարդերի և լարվածության).

Մի փոքրիկ ներածական նշում. Ի՞նչ իրավիճակներ ունեն մեր հաճախորդները, մեր հաճախորդները: Տվյալների բազայի հետ կապված ինչ-որ վթար կա։ Եվ երբ տվյալների բազան արդեն վերականգնվել է, գալիս է վարչության պետը կամ զարգացման պետն ու ասում. «Ընկերներ, մենք պետք է վերահսկենք տվյալների բազան, քանի որ վատ բան է տեղի ունեցել, և մենք պետք է թույլ չտանք, որ դա տեղի ունենա ապագայում»: Եվ այստեղ սկսվում է մոնիտորինգի համակարգի ընտրության կամ գոյություն ունեցող մոնիտորինգի համակարգի հարմարեցման հետաքրքիր գործընթացը, որպեսզի կարողանաք վերահսկել ձեր տվյալների բազան՝ PostgreSQL, MySQL կամ մի քանի այլ: Եվ գործընկերները սկսում են առաջարկել. «Ես լսել եմ, որ կա այսինչ տվյալների բազա: Եկեք օգտագործենք այն»: Գործընկերները սկսում են վիճել միմյանց հետ։ Եվ վերջում պարզվում է, որ մենք ընտրում ենք տվյալների բազա, բայց PostgreSQL մոնիտորինգը բավականին վատ է ներկայացված դրանում, և մենք միշտ պետք է ինչ-որ բան ավելացնենք։ Վերցրեք մի քանի պահեստ GitHub-ից, կլոնավորեք դրանք, հարմարեցրեք սցենարները և ինչ-որ կերպ հարմարեցրեք դրանք: Եվ վերջում դա ստացվում է ինչ-որ ձեռքի աշխատանք:

Հետևաբար, այս զրույցի ընթացքում ես կփորձեմ ձեզ որոշակի գիտելիքներ տալ, թե ինչպես ընտրել մոնիտորինգ ոչ միայն PostgreSQL-ի, այլ նաև տվյալների բազայի համար: Եվ կտա ձեզ այն գիտելիքները, որոնք թույլ կտան ձեզ ավարտին հասցնել ձեր մոնիտորինգը՝ դրանից որոշակի օգուտ ստանալու համար, որպեսզի կարողանաք օգուտ քաղել ձեր տվյալների բազայի վրա՝ անհապաղ կանխելու ցանկացած առաջիկա արտակարգ իրավիճակներ, որոնք կարող են առաջանալ:

Եվ գաղափարները, որոնք կլինեն այս զեկույցում, կարող են ուղղակիորեն հարմարեցվել ցանկացած տվյալների բազայի, լինի դա DBMS կամ noSQL: Հետևաբար, կա ոչ միայն PostgreSQL, այլև կլինեն բազմաթիվ բաղադրատոմսեր, թե ինչպես դա անել PostgreSQL-ում: Կլինեն հարցումների օրինակներ, սուբյեկտների օրինակներ, որոնք PostgreSQL-ն ունի մոնիտորինգի համար: Եվ եթե ձեր DBMS-ն ունի նույն բաները, որոնք թույլ են տալիս դրանք դնել մոնիտորինգի մեջ, կարող եք նաև հարմարեցնել դրանք, ավելացնել դրանք և լավ կլինի։

Ես չեմ լինի զեկույցում
խոսեք այն մասին, թե ինչպես մատուցել և պահպանել չափումները: Տվյալների հետմշակման և օգտատիրոջը ներկայացնելու մասին ոչինչ չեմ ասի։ Իսկ ահազանգելու մասին ոչինչ չեմ ասի։
Բայց քանի որ պատմությունը զարգանում է, ես ցույց կտամ առկա մոնիտորինգի տարբեր սքրինշոթներ և ինչ-որ կերպ կքննադատեմ դրանք: Բայց, այնուամենայնիվ, կաշխատեմ ապրանքանիշեր չնշել, որպեսզի այդ ապրանքների համար գովազդ կամ հակագովազդ չստեղծեմ։ Հետևաբար, բոլոր զուգադիպությունները պատահական են և թողնված են ձեր երևակայությանը:

Նախ, եկեք պարզենք, թե ինչ է մոնիտորինգը: Մոնիտորինգը շատ կարևոր բան է: Սա հասկանում են բոլորը։ Բայց միևնույն ժամանակ, մոնիտորինգը չի առնչվում բիզնեսի արտադրանքին և ուղղակիորեն չի ազդում ընկերության շահույթի վրա, ուստի մնացորդային հիմունքներով մոնիտորինգին միշտ հատկացվում է ժամանակ: Եթե ​​մենք ժամանակ ունենք, ապա մոնիտորինգ ենք անում, եթե ժամանակ չունենք, ապա լավ, մենք այն կդնենք հետնահերթության մեջ և մի օր կվերադառնանք այս առաջադրանքներին:

Հետևաբար, մեր պրակտիկայից, երբ մենք գալիս ենք հաճախորդներին, մոնիտորինգը հաճախ թերի է և չունի որևէ հետաքրքիր բան, որը կօգնի մեզ ավելի լավ աշխատել տվյալների բազայի հետ: Եվ հետևաբար մոնիտորինգը միշտ պետք է ավարտվի:

Տվյալների շտեմարաններն այնպիսի բարդ բաներ են, որոնք նույնպես պետք է վերահսկվեն, քանի որ տվյալների բազաները տեղեկատվության շտեմարան են: Իսկ տեղեկատվությունը շատ կարևոր է ընկերության համար, այն ոչ մի կերպ չի կարելի կորցնել։ Բայց միևնույն ժամանակ տվյալների բազաները ծրագրային ապահովման շատ բարդ մասեր են: Դրանք բաղկացած են մեծ թվով բաղադրիչներից։ Եվ այս բաղադրիչներից շատերը պետք է վերահսկվեն:

Եթե ​​խոսքը կոնկրետ PostgreSQL-ի մասին է, ապա այն կարելի է ներկայացնել մեծ թվով բաղադրիչներից բաղկացած սխեմայի տեսքով։ Այս բաղադրիչները փոխազդում են միմյանց հետ: Եվ միևնույն ժամանակ, PostgreSQL-ն ունի, այսպես կոչված, Stats Collector ենթահամակարգը, որը թույլ է տալիս հավաքել վիճակագրություն այս ենթահամակարգերի աշխատանքի մասին և ինչ-որ ինտերֆեյս տրամադրել ադմինիստրատորին կամ օգտագործողին, որպեսզի նա կարողանա դիտել այս վիճակագրությունը:

Այս վիճակագրությունը ներկայացված է որոշակի գործառույթների և տեսակետների տեսքով։ Դրանք կարելի է անվանել նաև սեղաններ։ Այսինքն, օգտագործելով սովորական psql հաճախորդը, դուք կարող եք միանալ տվյալների շտեմարանին, ընտրություն կատարել այս գործառույթների և դիտումների վրա և ստանալ որոշակի թվեր PostgreSQL ենթահամակարգերի աշխատանքի վերաբերյալ:

Դուք կարող եք ավելացնել այս թվերը ձեր սիրելի մոնիտորինգի համակարգին, նկարել գրաֆիկներ, ավելացնել գործառույթներ և երկարաժամկետ հեռանկարում ստանալ վերլուծություն:

Բայց այս զեկույցում ես ամբողջությամբ չեմ լուսաբանի այս բոլոր գործառույթները, քանի որ այն կարող է տևել ամբողջ օրը: Ես բառացիորեն կանդրադառնամ երկու, երեք կամ չորս բաների և կասեմ, թե ինչպես են դրանք օգնում մոնիտորինգն ավելի լավ դարձնել:

Իսկ եթե խոսում ենք տվյալների բազայի մոնիտորինգի մասին, ապա ի՞նչն է պետք վերահսկել։ Առաջին հերթին, մենք պետք է վերահսկենք հասանելիությունը, քանի որ տվյալների բազան ծառայություն է, որը ապահովում է տվյալների հասանելիությունը հաճախորդներին, և մենք պետք է վերահսկենք հասանելիությունը, ինչպես նաև տրամադրենք դրա որոշ որակական և քանակական բնութագրեր:

Մենք նաև պետք է վերահսկենք հաճախորդներին, որոնք միանում են մեր տվյալների բազային, քանի որ նրանք կարող են լինել և՛ նորմալ հաճախորդներ, և՛ վնասակար հաճախորդներ, որոնք կարող են վնասել տվյալների բազան: Նրանք նաև պետք է վերահսկվեն և հետևեն նրանց գործունեությանը:

Երբ հաճախորդները միանում են տվյալների շտեմարանին, ակնհայտ է, որ նրանք սկսում են աշխատել մեր տվյալների հետ, ուստի մենք պետք է հետևենք, թե ինչպես են հաճախորդները աշխատում տվյալների հետ. Այսինքն՝ մենք պետք է գնահատենք այն ծանրաբեռնվածությունը, որը ստեղծվում է մեր հաճախորդների կողմից:

Բայց ծանրաբեռնվածությունը նույնպես բաղկացած է, իհարկե, խնդրանքներից: Հավելվածները միանում են տվյալների բազային, մուտք են գործում տվյալներ՝ օգտագործելով հարցումներ, ուստի կարևոր է գնահատել, թե ինչ հարցումներ ունենք տվյալների բազայում, վերահսկել դրանց համապատասխանությունը, որ դրանք ծուռ չեն գրված, որ որոշ տարբերակներ պետք է վերաշարադրվեն և պատրաստվեն, որպեսզի դրանք ավելի արագ աշխատեն։ և ավելի լավ կատարմամբ:

Եվ քանի որ մենք խոսում ենք տվյալների բազայի մասին, տվյալների բազան միշտ ֆոնային գործընթացներ է: Ֆոնային գործընթացները օգնում են պահպանել տվյալների բազայի արդյունավետությունը լավ մակարդակի վրա, ուստի նրանք պահանջում են որոշակի քանակությամբ ռեսուրսներ իրենց գործելու համար: Եվ միևնույն ժամանակ, դրանք կարող են համընկնել հաճախորդի հարցումների ռեսուրսների հետ, ուստի ագահ ֆոնային գործընթացները կարող են ուղղակիորեն ազդել հաճախորդի հարցումների կատարման վրա: Հետևաբար, դրանք նույնպես պետք է վերահսկվեն և հետևվեն, որպեսզի ֆոնային գործընթացների առումով աղավաղումներ չլինեն:

Եվ այս ամենը տվյալների բազայի մոնիտորինգի առումով մնում է համակարգի չափման մեջ։ Բայց հաշվի առնելով, որ մեր ենթակառուցվածքի մեծ մասը շարժվում է դեպի ամպեր, առանձին հյուրընկալողի համակարգի չափորոշիչները միշտ հետին պլան են մղվում: Բայց տվյալների շտեմարաններում դրանք դեռևս արդիական են և, իհարկե, անհրաժեշտ է նաև վերահսկել համակարգի չափումները:

Համակարգային չափումների հետ կապված ամեն ինչ քիչ թե շատ լավ է, մոնիտորինգի բոլոր ժամանակակից համակարգերն արդեն աջակցում են այս չափորոշիչներին, բայց ընդհանուր առմամբ, որոշ բաղադրիչներ դեռ բավարար չեն, և որոշ բաներ պետք է ավելացնել: Դրանց էլ կանդրադառնամ, դրանց մասին կլինեն մի քանի սլայդներ։

Ծրագրի առաջին կետը հասանելիությունն է: Ի՞նչ է մատչելիությունը: Հասանելիությունը, իմ ընկալմամբ, բազայի կարողությունն է սպասարկել կապերը, այսինքն՝ բազան բարձրացվում է, այն որպես ծառայություն ընդունում է միացումներ հաճախորդներից: Եվ այս մատչելիությունը կարելի է գնահատել որոշակի հատկանիշներով։ Շատ հարմար է այս բնութագրերը ցուցադրել վահանակների վրա:

Բոլորը գիտեն, թե ինչ են վահանակները: Սա այն դեպքում, երբ դուք մեկ անգամ նայեցիք էկրանին, որի վրա ամփոփված են անհրաժեշտ տեղեկությունները: Եվ դուք կարող եք անմիջապես որոշել, արդյոք տվյալների բազայում խնդիր կա, թե ոչ:
Համապատասխանաբար, տվյալների բազայի և այլ հիմնական բնութագրերի առկայությունը միշտ պետք է ցուցադրվեն վահանակների վրա, որպեսզի այդ տեղեկատվությունը լինի ձեռքի տակ և միշտ հասանելի լինի ձեզ: Որոշ լրացուցիչ մանրամասներ, որոնք արդեն օգնում են միջադեպերի հետաքննությանը, որոշ արտակարգ իրավիճակներ հետաքննելիս, դրանք արդեն պետք է տեղադրվեն երկրորդական վահանակների վրա կամ թաքնվեն ներքևող հղումներում, որոնք տանում են դեպի երրորդ կողմի մոնիտորինգի համակարգեր:

Մոնիտորինգի հայտնի համակարգի օրինակ. Սա շատ թույն մոնիտորինգի համակարգ է: Նա շատ տվյալներ է հավաքում, բայց իմ տեսանկյունից նա ունի վահանակների տարօրինակ հասկացություն: «Ստեղծել վահանակ» հղում կա: Բայց երբ դուք ստեղծում եք վահանակ, դուք ստեղծում եք երկու սյունակների ցուցակ, գրաֆիկների ցուցակ: Եվ երբ պետք է ինչ-որ բան նայել, սկսում ես մկնիկի հետ սեղմել, ոլորել, փնտրել ցանկալի աղյուսակը։ Եվ սա ժամանակ է պահանջում, այսինքն՝ վահանակներ, որպես այդպիսին, չկան: Կան միայն գծապատկերների ցուցակներ:

Ի՞նչ պետք է ավելացնեք այս վահանակներին: Դուք կարող եք սկսել այնպիսի հատկանիշով, ինչպիսին է արձագանքման ժամանակը: PostgreSQL-ն ունի pg_stat_statements տեսք: Այն անջատված է լռելյայնորեն, բայց այն համակարգի կարևոր դիտումներից մեկն է, որը միշտ պետք է միացված լինի և օգտագործվի: Այն պահպանում է տվյալների բազայում կատարված բոլոր առաջադրվող հարցումների մասին տեղեկությունները:

Համապատասխանաբար, մենք կարող ենք սկսել այն փաստից, որ մենք կարող ենք վերցնել բոլոր հարցումների կատարման ընդհանուր ժամանակը և բաժանել այն հայտերի քանակի վրա՝ օգտագործելով վերը նշված դաշտերը: Բայց սա հիվանդանոցում միջին ջերմաստիճանն է: Մենք կարող ենք սկսել այլ դաշտերից՝ հարցման կատարման նվազագույն ժամանակը, առավելագույնը և միջինը: Եվ մենք նույնիսկ կարող ենք կառուցել տոկոսներ; PostgreSQL-ն ունի դրա համար համապատասխան գործառույթներ: Եվ մենք կարող ենք ստանալ որոշ թվեր, որոնք բնութագրում են մեր տվյալների բազայի պատասխանի ժամանակը արդեն կատարված հարցումների համար, այսինքն՝ մենք չենք կատարում կեղծ հարցումը «ընտրել 1» և նայում ենք պատասխանի ժամանակին, այլ վերլուծում ենք արդեն ավարտված հարցումների պատասխանի ժամանակը և նկարում։ կա՛մ առանձին պատկեր, կա՛մ դրա հիման վրա գրաֆիկ ենք կառուցում։

Կարևոր է նաև վերահսկել այն սխալների քանակը, որոնք ներկայումս ստեղծվում են համակարգի կողմից: Եվ դրա համար կարող եք օգտագործել pg_stat_database տեսքը։ Մենք կենտրոնանում ենք xact_rollback դաշտի վրա: Այս դաշտը ցույց է տալիս ոչ միայն տվյալների բազայում տեղի ունեցող հետադարձումների քանակը, այլև հաշվի է առնում սխալների քանակը: Համեմատաբար ասած, մենք կարող ենք ցուցադրել այս ցուցանիշը մեր վահանակում և տեսնել, թե որքան սխալներ ունենք ներկայումս: Եթե ​​շատ սխալներ կան, ապա սա լավ պատճառ է տեղեկամատյանները նայելու և տեսնելու, թե դրանք ինչ տեսակի սխալներ են և ինչու են առաջանում, ապա ներդրումներ կատարել և լուծել դրանք:

Դուք կարող եք ավելացնել այնպիսի բան, ինչպիսին է տախոմետրը: Սրանք են մեկ վայրկյանում գործարքների քանակը և վայրկյանում հարցումների քանակը: Համեմատաբար ասած, դուք կարող եք օգտագործել այս թվերը որպես ձեր տվյալների բազայի ընթացիկ կատարողականություն և դիտել, թե արդյոք կան հարցումների գագաթնակետեր, գործարքների գագաթնակետեր, կամ, ընդհակառակը, տվյալների բազան թերբեռնված է, քանի որ որոշ հետին պլան ձախողվել է: Կարևոր է միշտ նայել այս ցուցանիշին և հիշել, որ մեր նախագծի համար նման կատարումը նորմալ է, բայց վերևում և ներքևի արժեքներն արդեն ինչ-որ խնդրահարույց և անհասկանալի են, ինչը նշանակում է, որ մենք պետք է նայենք, թե ինչու են այս թվերը: այնքան բարձր.

Գործարքների քանակը գնահատելու համար մենք կարող ենք կրկին դիմել pg_stat_database տեսքին: Մենք կարող ենք ավելացնել պարտավորությունների և հետադարձումների քանակը և ստանալ գործարքների քանակը վայրկյանում:

Արդյո՞ք բոլորը հասկանում են, որ մի քանի հարցումներ կարող են տեղավորվել մեկ գործարքի մեջ: Հետևաբար, TPS-ը և QPS-ը մի փոքր տարբերվում են:

Մեկ վայրկյանում հարցումների քանակը կարելի է ստանալ pg_stat_statements-ից և պարզապես հաշվարկել բոլոր կատարված հարցումների գումարը: Հասկանալի է, որ ընթացիկ արժեքը համեմատում ենք նախորդի հետ, հանում, ստանում ենք դելտան և ստանում քանակը։

Ցանկության դեպքում կարող եք ավելացնել լրացուցիչ չափումներ, որոնք նաև օգնում են գնահատել մեր տվյալների բազայի հասանելիությունը և վերահսկել, թե արդյոք եղել են խափանումներ:

Այս չափիչներից մեկը գործառնական ժամանակն է: Բայց PostgreSQL-ում գործարկման ժամանակը մի փոքր բարդ է: Ես ձեզ կասեմ, թե ինչու: Երբ PostgreSQL-ը սկսվում է, գործարկման ժամանակը սկսում է զեկուցել: Բայց եթե ինչ-որ պահի, օրինակ, ինչ-որ առաջադրանք աշխատում էր գիշերը, եկավ OOM-մարդասպանը և բռնի կերպով դադարեցրեց PostgreSQL երեխայի գործընթացը, ապա այս դեպքում PostgreSQL-ն դադարեցնում է բոլոր հաճախորդների կապը, վերակայում է բեկորային հիշողության տարածքը և սկսում է վերականգնումը: վերջին անցակետը. Եվ մինչ անցակետից այս վերականգնումը տևում է, տվյալների բազան միացումներ չի ընդունում, այսինքն՝ այս իրավիճակը կարելի է գնահատել որպես պարապուրդ: Բայց ժամանակի հաշվիչը չի զրոյացվի, քանի որ առաջին իսկ պահից հաշվի է առնում postmaster-ի գործարկման ժամանակը։ Հետեւաբար, նման իրավիճակները կարելի է բաց թողնել:

Դուք նաև պետք է վերահսկեք վակուումային աշխատողների թիվը: Բոլորը գիտե՞ն, թե ինչ է Autovacuum-ը PostgreSQL-ում: Սա հետաքրքիր ենթահամակարգ է PostgreSQL-ում: Նրա մասին բազմաթիվ հոդվածներ են գրվել, բազմաթիվ զեկույցներ են արվել։ Շատ քննարկումներ կան վակուումի և այն մասին, թե ինչպես պետք է աշխատի: Շատերը դա համարում են անհրաժեշտ չարիք։ Բայց դա այդպես է։ Սա աղբահավաքի մի տեսակ անալոգ է, որը մաքրում է տողերի հնացած տարբերակները, որոնք անհրաժեշտ չեն որևէ գործարքի և ազատում է տարածք աղյուսակներում և ինդեքսներում նոր տողերի համար:

Ինչու՞ պետք է վերահսկել այն: Քանի որ վակուումը երբեմն շատ է ցավում: Այն սպառում է մեծ քանակությամբ ռեսուրսներ, և արդյունքում հաճախորդների հարցումները սկսում են տուժել:

Եվ դա պետք է վերահսկվի pg_stat_activity դիտման միջոցով, որի մասին կխոսեմ հաջորդ բաժնում։ Այս տեսքը ցույց է տալիս տվյալների բազայի ընթացիկ գործունեությունը: Եվ այս գործունեության միջոցով մենք կարող ենք հետևել վակուումների քանակին, որոնք աշխատում են հենց հիմա: Մենք կարող ենք հետևել վակուումներին և տեսնել, որ եթե մենք գերազանցել ենք սահմանը, ապա դա պատճառ է, որպեսզի ուսումնասիրենք PostgreSQL կարգավորումները և ինչ-որ կերպ օպտիմալացնենք վակուումի աշխատանքը:

PostgreSQL-ի մասին մեկ այլ բան այն է, որ PostgreSQL-ը շատ հիվանդ է երկար գործարքներից: Հատկապես այն գործարքներից, որոնք երկար ժամանակ կախված են և ոչինչ չեն անում: Սա այսպես կոչված stat idle-in-transaction-ն է: Նման գործարքը պահում է կողպեքներ և թույլ չի տալիս վակուումը աշխատել: Եվ արդյունքում սեղանները ուռչում են ու մեծանում։ Եվ հարցումները, որոնք աշխատում են այս աղյուսակների հետ, սկսում են ավելի դանդաղ աշխատել, քանի որ դուք պետք է թափեք տողերի բոլոր հին տարբերակները հիշողությունից մինչև սկավառակ և ետ: Հետևաբար, ամենաերկար գործարքների տևողությունը, ամենաերկար վակուումային հարցումները նույնպես պետք է վերահսկվեն: Եվ եթե մենք տեսնում ենք որոշ գործընթացներ, որոնք աշխատում են շատ երկար ժամանակ, արդեն ավելի քան 10-20-30 րոպե OLTP բեռի համար, ապա մենք պետք է ուշադրություն դարձնենք դրանց վրա և հարկադրաբար դադարեցնենք դրանք, կամ օպտիմիզացնենք հավելվածը, որպեսզի նրանք չեն կանչվում և այդքան երկար չեն կախվում։ Վերլուծական ծանրաբեռնվածության համար 10-20-30 րոպեն նորմալ է, կան նաև ավելի երկար:

Հաջորդը մենք ունենք տարբերակ կապված հաճախորդների հետ: Երբ մենք արդեն ստեղծել ենք վահանակ և տեղադրել դրա վրա հիմնական հասանելիության չափանիշները, մենք կարող ենք նաև ավելացնել լրացուցիչ տեղեկություններ կապված հաճախորդների մասին:

Կապված հաճախորդների մասին տեղեկատվությունը կարևոր է, քանի որ PostgreSQL-ի տեսանկյունից հաճախորդները տարբեր են: Կան լավ հաճախորդներ, կան վատ հաճախորդներ:

Պարզ օրինակ. Հաճախորդի կողմից ես հասկանում եմ դիմումը: Հավելվածը միացել է տվյալների շտեմարանին և անմիջապես սկսում է այնտեղ ուղարկել իր հարցումները, տվյալների բազան մշակում և կատարում է դրանք, իսկ արդյունքները վերադարձնում է հաճախորդին: Սրանք լավ և ճիշտ հաճախորդներ են:

Լինում են իրավիճակներ, երբ հաճախորդը միացել է, կապը պահում է, բայց ոչինչ չի անում։ Գտնվում է պարապ վիճակում։

Բայց կան վատ հաճախորդներ: Օրինակ, նույն հաճախորդը միացավ, բացեց գործարք, ինչ-որ բան արեց տվյալների բազայում և հետո մտավ կոդի մեջ, օրինակ՝ արտաքին աղբյուր մուտք գործելու կամ այնտեղ ստացված տվյալները մշակելու համար։ Բայց նա գործարքը չի փակել։ Եվ գործարքը կախված է տվյալների բազայում և պահվում է գծի կողպեքում: Սա վատ պայման է։ Եվ եթե հանկարծ ինչ-որ տեղ իր ներսում որևէ հավելված ձախողվի բացառությամբ, ապա գործարքը կարող է բաց մնալ շատ երկար ժամանակ։ Եվ սա ուղղակիորեն ազդում է PostgreSQL-ի աշխատանքի վրա: PostgreSQL-ն ավելի դանդաղ կլինի: Հետևաբար, կարևոր է հետևել նման հաճախորդներին ժամանակին և հարկադրաբար դադարեցնել նրանց աշխատանքը: Եվ դուք պետք է օպտիմալացնեք ձեր հավելվածը, որպեսզի նման իրավիճակներ չառաջանան։

Մյուս վատ հաճախորդները սպասում են հաճախորդներին: Բայց նրանք վատանում են հանգամանքների պատճառով։ Օրինակ, պարզ անգործուն գործարք. այն կարող է բացել գործարքը, կողպել որոշ տողեր, այնուհետև ինչ-որ տեղ կոդի մեջ այն կձախողվի՝ թողնելով կախված գործարք: Մեկ այլ հաճախորդ կգա և կպահանջի նույն տվյալները, բայց նա կհանդիպի կողպեքի, քանի որ այդ կախված գործարքն արդեն իսկ պահում է որոշ պահանջվող տողերի կողպեքներ: Իսկ երկրորդ գործարքը կկապվի, սպասելով, որ առաջին գործարքը ավարտվի կամ բռնի կերպով փակվի այն ադմինիստրատորի կողմից: Հետևաբար, սպասվող գործարքները կարող են կուտակվել և լրացնել տվյալների բազայի միացման սահմանաչափը: Իսկ երբ լիմիտը լրացվում է, հավելվածն այլևս չի կարող աշխատել տվյալների բազայի հետ։ Նախագծի համար սա արդեն արտակարգ իրավիճակ է։ Հետևաբար, վատ հաճախորդներին պետք է հետևել և ժամանակին արձագանքել նրանց:

Մոնիտորինգի ևս մեկ օրինակ. Եվ այստեղ արդեն կա պատշաճ վահանակ: Կապերի մասին տեղեկություններ կան վերևում: DB միացում – 8 հատ: Եվ դա բոլորն է: Մենք տեղեկություն չունենք, թե որ հաճախորդներն են ակտիվ, որ հաճախորդներն են պարզապես պարապ, ոչինչ չեն անում։ Սպասող գործարքների և առկախ կապերի մասին տեղեկություններ չկան, այսինքն՝ սա մի թիվ է, որը ցույց է տալիս կապերի քանակը և վերջ։ Եվ հետո ինքներդ գուշակեք։

Համապատասխանաբար, այս տեղեկատվությունը մոնիտորինգին ավելացնելու համար անհրաժեշտ է մուտք գործել pg_stat_activity համակարգի տեսք: Եթե ​​դուք շատ ժամանակ եք անցկացնում PostgreSQL-ում, ապա սա շատ լավ դիտում է, որը պետք է դառնա ձեր ընկերը, քանի որ այն ցույց է տալիս ընթացիկ գործունեությունը PostgreSQL-ում, այսինքն՝ ինչ է կատարվում դրանում: Յուրաքանչյուր գործընթացի համար կա առանձին տող, որը ցույց է տալիս այս գործընթացի մասին տեղեկատվությունը. որ հոսթից է կատարվել կապը, ինչ օգտվողի տակ, ինչ անունով, երբ է սկսվել գործարքը, ինչ հարցում է ներկայումս աշխատում, վերջին անգամ ինչ հարցում է կատարվել: Եվ, համապատասխանաբար, մենք կարող ենք գնահատել հաճախորդի վիճակը՝ օգտագործելով stat դաշտը: Համեմատաբար ասած, մենք կարող ենք խմբավորել ըստ այս դաշտի և ստանալ այն վիճակագրությունը, որը ներկայումս գտնվում է տվյալների բազայում և կապերի քանակը, որոնք ունեն այս վիճակագրությունը տվյալների բազայում: Իսկ արդեն ստացված թվերը կարող ենք ուղարկել մեր մոնիտորինգին ու դրանց հիման վրա գրաֆիկներ նկարել։
Կարևոր է նաև գնահատել գործարքի տևողությունը: Ես արդեն ասացի, որ կարևոր է գնահատել վակուումների տևողությունը, բայց գործարքները գնահատվում են նույն կերպ։ Կան xact_start և query_start դաշտեր: Դրանք, համեմատաբար, ցույց են տալիս գործարքի մեկնարկի ժամը և հարցման մեկնարկի ժամը։ Մենք վերցնում ենք now() ֆունկցիան, որը ցույց է տալիս ընթացիկ ժամադրոշմը, և հանում ենք գործարքը և պահանջում ժամանակի դրոշմը։ Եվ մենք ստանում ենք գործարքի տեւողությունը, պահանջի տեւողությունը:

Եթե ​​մենք տեսնում ենք երկարատև գործարքներ, ապա դրանք արդեն պետք է ավարտին հասցնենք։ OLTP բեռի դեպքում երկար գործարքներն արդեն 1-2-3 րոպեից ավելի են. OLAP-ի ծանրաբեռնվածության համար երկար գործարքները նորմալ են, բայց եթե դրանք ավարտելու համար պահանջվում է ավելի քան երկու ժամ, ապա սա նաև նշան է, որ մենք ինչ-որ տեղ շեղում ունենք:

Երբ հաճախորդները միանում են տվյալների բազային, նրանք սկսում են աշխատել մեր տվյալների հետ: Նրանք մուտք են գործում աղյուսակներ, մուտք են գործում ինդեքսներ՝ աղյուսակից տվյալներ ստանալու համար: Եվ կարևոր է գնահատել, թե ինչպես են հաճախորդները փոխազդում այս տվյալների հետ:

Սա անհրաժեշտ է մեր ծանրաբեռնվածությունը գնահատելու և մոտավորապես հասկանալու համար, թե որ աղյուսակներն են մեզ համար «ամենաշոգը»: Օրինակ, դա անհրաժեշտ է այն իրավիճակներում, երբ մենք ցանկանում ենք «տաք» սեղաններ տեղադրել ինչ-որ արագ SSD պահեստի վրա: Օրինակ, որոշ արխիվային աղյուսակներ, որոնք մենք երկար ժամանակ չենք օգտագործել, կարող ենք տեղափոխել ինչ-որ «սառը» արխիվ, SATA կրիչներ և թողնել այնտեղ ապրել, դրանք հասանելի կլինեն ըստ անհրաժեշտության:

Սա նաև օգտակար է ցանկացած թողարկումից և տեղակայումից հետո անոմալիաներ հայտնաբերելու համար: Ենթադրենք, նախագիծը թողարկել է որոշ նոր գործառույթ: Օրինակ, մենք ավելացրել ենք տվյալների բազայի հետ աշխատելու նոր գործառույթ: Եվ եթե մենք գծենք աղյուսակի օգտագործման գրաֆիկները, մենք հեշտությամբ կարող ենք հայտնաբերել այս անոմալիաները այս գրաֆիկների վրա: Օրինակ՝ թարմացրեք պոռթկումները կամ ջնջեք պոռթկումները: Դա շատ տեսանելի կլինի։

Դուք կարող եք նաև անոմալիաներ հայտնաբերել «լողացող» վիճակագրության մեջ: Ինչ է դա նշանակում? PostgreSQL-ն ունի շատ ուժեղ և շատ լավ հարցումների պլանավորող: Իսկ մշակողները շատ ժամանակ են հատկացնում դրա զարգացմանը։ Ինչպե՞ս է նա աշխատում: Լավ պլաններ կազմելու համար PostgreSQL-ը վիճակագրություն է հավաքում աղյուսակներում տվյալների բաշխման վերաբերյալ որոշակի ժամանակային ընդմիջումով և որոշակի հաճախականությամբ: Սրանք ամենատարածված արժեքներն են՝ եզակի արժեքների քանակը, աղյուսակում NULL-ի մասին տեղեկատվություն, շատ տեղեկություններ։

Այս վիճակագրության հիման վրա պլանավորողը կառուցում է մի քանի հարցումներ, ընտրում է ամենաօպտիմալը և օգտագործում այս հարցման պլանը՝ հարցումն ինքն իրագործելու և տվյալներ վերադարձնելու համար:

Եվ պատահում է, որ վիճակագրությունը «լողում է»։ Աղյուսակում ինչ-որ կերպ փոխվել են որակի և քանակի տվյալները, սակայն վիճակագրությունը չի հավաքվել։ Իսկ կազմված պլանները կարող են օպտիմալ չլինել։ Եվ եթե հավաքագրված մոնիտորինգի հիման վրա, աղյուսակների հիման վրա մեր ծրագրերը պարզվեն ոչ օպտիմալ, մենք կկարողանանք տեսնել այդ անոմալիաները։ Օրինակ, ինչ-որ տեղ տվյալները որակապես փոխվեցին և ինդեքսի փոխարեն սկսեց կիրառվել աղյուսակի հաջորդական անցում, այսինքն. եթե հարցումը պետք է վերադարձնի ընդամենը 100 տող (կա 100-ի սահմանաչափ), ապա այս հարցման համար կկատարվի ամբողջական որոնում: Եվ դա միշտ շատ վատ է ազդում կատարողականի վրա։

Եվ դա մենք կարող ենք տեսնել մոնիտորինգում: Եվ արդեն նայեք այս հարցումը, կատարեք դրա բացատրությունը, հավաքեք վիճակագրություն, ստեղծեք նոր լրացուցիչ ինդեքս: Եվ արդեն արձագանքել այս խնդրին: Դրա համար դա կարևոր է:

Մոնիտորինգի ևս մեկ օրինակ. Կարծում եմ՝ նրան շատերը ճանաչեցին, քանի որ նա շատ սիրված է։ Ովքեր օգտագործում են այն իրենց նախագծերում Պրոմեթեւս? Ո՞վ է օգտագործում այս ապրանքը Պրոմեթևսի հետ համատեղ: Փաստն այն է, որ այս մոնիտորինգի ստանդարտ պահոցում կա PostgreSQL-ի հետ աշխատելու վահանակ. postgres_exporter Պրոմեթևս. Բայց կա մի վատ մանրամասն.

Կան մի քանի գրաֆիկներ. Իսկ բայթերը նշվում են որպես միասնություն, այսինքն՝ կա 5 գրաֆիկ: Դրանք են՝ Տեղադրել տվյալներ, Թարմացնել տվյալները, Ջնջել տվյալները, Տվյալների Վերբեռնումը և Վերադարձի տվյալները: Չափման միավորը բայթ է: Բայց բանն այն է, որ վիճակագրությունը PostgreSQL-ում տվյալները վերադարձնում է կրկնակի (տողերով): Եվ, համապատասխանաբար, այս գրաֆիկները շատ լավ միջոց են ձեր ծանրաբեռնվածությունը մի քանի անգամ, տասնյակ անգամ թերագնահատելու համար, քանի որ tuple-ը բայթ չէ, tuple-ը տող է, այն շատ բայթ է և միշտ ունի փոփոխական երկարություն: Այսինքն՝ բայթերով ծանրաբեռնվածության հաշվարկը՝ օգտագործելով tuples, անիրատեսական խնդիր է կամ շատ դժվար։ Հետևաբար, երբ դուք օգտագործում եք վահանակ կամ ներկառուցված մոնիտորինգ, միշտ կարևոր է հասկանալ, որ այն ճիշտ է աշխատում և վերադարձնում է ձեզ ճիշտ գնահատված տվյալները:

Ինչպե՞ս ստանալ վիճակագրություն այս աղյուսակների վրա: Այդ նպատակով PostgreSQL-ն ունի դիտումների որոշակի ընտանիք։ Իսկ հիմնական տեսակետն է pg_stat_user_tables. User_tables - սա նշանակում է օգտագործողի անունից ստեղծված աղյուսակներ: Ի հակադրություն, կան համակարգի տեսակետներ, որոնք օգտագործվում են հենց PostgreSQL-ի կողմից: Եվ կա Alltables-ի ամփոփ աղյուսակ, որը ներառում է և՛ համակարգային, և՛ օգտագործողների: Դուք կարող եք սկսել նրանցից ցանկացածից, որը ձեզ ամենաշատն է դուր գալիս:

Օգտագործելով վերը նշված դաշտերը, կարող եք գնահատել ներդիրների, թարմացումների և ջնջումների քանակը: Վահանակի օրինակը, որը ես օգտագործել եմ, օգտագործում է այս դաշտերը՝ գնահատելու ծանրաբեռնվածության բնութագրերը: Հետևաբար, մենք կարող ենք նաև դրանց վրա հիմնվել: Բայց հարկ է հիշել, որ դրանք բազմակներ են, ոչ թե բայթեր, այնպես որ մենք չենք կարող դա անել հենց բայթերով:

Այս տվյալների հիման վրա մենք կարող ենք կառուցել այսպես կոչված TopN աղյուսակներ։ Օրինակ՝ Թոփ-5, Թոփ-10: Եվ դուք կարող եք հետևել այն տաք սեղաններին, որոնք ավելի շատ են վերամշակվում, քան մյուսները: Օրինակ՝ 5 «տաք» սեղաններ տեղադրելու համար։ Եվ օգտագործելով այս TopN աղյուսակները, մենք գնահատում ենք մեր ծանրաբեռնվածությունը և կարող ենք գնահատել աշխատանքային ծանրաբեռնվածության պայթյունները ցանկացած թողարկումից, թարմացումից և տեղակայումից հետո:

Կարևոր է նաև գնահատել աղյուսակի չափը, քանի որ երբեմն ծրագրավորողները նոր գործառույթ են ներդնում, և մեր աղյուսակները սկսում են մեծանալ իրենց մեծ չափերով, քանի որ նրանք որոշել են ավելացնել լրացուցիչ քանակությամբ տվյալներ, բայց չեն կանխատեսել, թե ինչպես դա տեղի կունենա: ազդել տվյալների բազայի չափի վրա: Նման դեպքերը մեզ համար նույնպես անակնկալ են:

Իսկ հիմա մի փոքրիկ հարց ձեզ. Ի՞նչ հարց է առաջանում, երբ նկատում եք ձեր տվյալների բազայի սերվերի բեռը: Ո՞րն է ձեր հաջորդ հարցը:

Բայց իրականում հարցն առաջանում է հետեւյալ կերպ. Ի՞նչ խնդրանքներ է առաջացնում բեռը: Այսինքն՝ հետաքրքիր չէ նայել այն գործընթացներին, որոնք առաջանում են ծանրաբեռնվածությունից։ Հասկանալի է, որ եթե հոսթն ունի տվյալների բազա, ապա տվյալների բազան աշխատում է այնտեղ, և պարզ է, որ այնտեղ կվերացվեն միայն տվյալների բազաները: Եթե ​​բացենք Top-ը, այնտեղ կտեսնենք PostgreSQL-ի գործընթացների ցանկը, որոնք ինչ-որ բան են անում: Top-ից պարզ չի լինի, թե ինչ են անում։

Համապատասխանաբար, դուք պետք է գտնեք այն հարցումները, որոնք առաջացնում են ամենաբարձր բեռը, քանի որ թյունինգ հարցումները, որպես կանոն, ավելի շատ շահույթ են տալիս, քան PostgreSQL-ի կամ օպերացիոն համակարգի կազմաձևումը կամ նույնիսկ սարքաշարը կարգավորելը: Ըստ իմ գնահատականի՝ սա մոտավորապես 80-85-90% է։ Եվ դա արվում է շատ ավելի արագ։ Ավելի արագ է ուղղել հարցումը, քան շտկել կոնֆիգուրացիան, պլանավորել վերագործարկում, հատկապես, եթե տվյալների բազան հնարավոր չէ վերագործարկել կամ ավելացնել սարքավորում: Ավելի հեշտ է ինչ-որ տեղ վերաշարադրել հարցումը կամ ավելացնել ինդեքս՝ այս հարցումից ավելի լավ արդյունք ստանալու համար:

Համապատասխանաբար, անհրաժեշտ է վերահսկել հարցումները և դրանց համապատասխանությունը: Բերենք մոնիտորինգի մեկ այլ օրինակ. Եվ այստեղ նույնպես, կարծես, գերազանց մոնիտորինգ կա։ Տեղեկատվություն կա կրկնօրինակման մասին, կա տեղեկատվություն թողունակության, արգելափակման, ռեսուրսների օգտագործման մասին: Ամեն ինչ լավ է, բայց հարցումների մասին տեղեկություն չկա։ Պարզ չէ, թե ինչ հարցումներ են աշխատում մեր տվյալների բազայում, որքան ժամանակ են դրանք աշխատում, քանիսն են այդ հարցումները: Մենք միշտ պետք է ունենանք այս տեղեկատվությունը մեր մոնիտորինգում:

Եվ այս տեղեկատվությունը ստանալու համար մենք կարող ենք օգտագործել pg_stat_statements մոդուլը: Դրա հիման վրա դուք կարող եք կառուցել մի շարք գրաֆիկներ: Օրինակ, դուք կարող եք տեղեկատվություն ստանալ ամենահաճախակի հարցումների մասին, այսինքն՝ այն հարցումների մասին, որոնք առավել հաճախ են կատարվում: Այո, տեղակայումից հետո նաև շատ օգտակար է դրան նայել և հասկանալ, թե արդյոք կա որևէ հարցումների աճ:

Դուք կարող եք վերահսկել ամենաերկար հարցումները, այսինքն՝ այն հարցումները, որոնց ավարտը տևում է ամենաերկարը: Նրանք աշխատում են պրոցեսորով, սպառում են I/O: Մենք կարող ենք նաև դա գնահատել՝ օգտագործելով total_time, mean_time, blk_write_time և blk_read_time դաշտերը:

Մենք կարող ենք գնահատել և վերահսկել ռեսուրսների օգտագործման առումով ամենածանր հարցումները, դրանք, որոնք կարդում են սկավառակից, աշխատում են հիշողության հետ, կամ, ընդհակառակը, ստեղծում են գրելու ինչ-որ բեռ:

Մենք կարող ենք գնահատել ամենաառատաձեռն խնդրանքները: Սրանք այն հարցումներն են, որոնք վերադարձնում են մեծ թվով տողեր: Օրինակ, սա կարող է լինել ինչ-որ հարցում, որտեղ նրանք մոռացել են սահմանել: Եվ դա պարզապես վերադարձնում է աղյուսակի կամ հարցումի ամբողջ բովանդակությունը հարցվող աղյուսակների միջով:

Եվ դուք կարող եք նաև վերահսկել հարցումները, որոնք օգտագործում են ժամանակավոր ֆայլեր կամ ժամանակավոր աղյուսակներ:

Եվ մենք դեռ ունենք ֆոնային գործընթացներ։ Ֆոնային գործընթացները հիմնականում անցակետեր են կամ կոչվում են նաև անցակետեր, դրանք ավտովակուում և կրկնօրինակում են:

Մոնիտորինգի ևս մեկ օրինակ. Ձախ կողմում կա Maintenance ներդիր, գնացեք այն և հուսով եք, որ ինչ-որ օգտակար բան կտեսնեք: Բայց այստեղ միայն վակուումային աշխատանքի և վիճակագրության հավաքման ժամանակն է, ոչ ավելին։ Սա շատ վատ տեղեկատվություն է, ուստի մենք միշտ պետք է ունենանք տեղեկատվություն այն մասին, թե ինչպես են աշխատում ֆոնային գործընթացները մեր տվյալների բազայում և արդյոք դրանց աշխատանքից որևէ խնդիր կա:

Երբ մենք նայում ենք անցակետերին, մենք պետք է հիշենք, որ անցակետերը մաքրում են կեղտոտ էջերը բեկորային հիշողության տարածքից դեպի սկավառակ, այնուհետև ստեղծում են անցակետ: Եվ այս անցակետը կարող է օգտագործվել որպես վերականգնման վայր, եթե PostgreSQL-ը հանկարծակի դադարեցվի արտակարգ իրավիճակում:

Համապատասխանաբար, բոլոր «կեղտոտ» էջերը սկավառակի վրա լցնելու համար հարկավոր է գրել որոշակի քանակությամբ: Եվ, որպես կանոն, մեծ քանակությամբ հիշողություն ունեցող համակարգերում սա շատ է: Եվ եթե մենք շատ հաճախ անցակետեր անենք կարճ ընդմիջումով, ապա սկավառակի աշխատանքը զգալիորեն կնվազի: Իսկ հաճախորդների հարցումները կտուժեն ռեսուրսների պակասից: Նրանք կմրցեն ռեսուրսների համար և արտադրողականության պակաս կունենան:

Համապատասխանաբար, pg_stat_bgwriter-ի միջոցով՝ օգտագործելով նշված դաշտերը, մենք կարող ենք վերահսկել անցակետերի քանակը, որոնք տեղի են ունենում: Իսկ եթե որոշակի ժամանակահատվածում (10-15-20 րոպեում, կես ժամում) ունենք շատ անցակետեր, օրինակ՝ 3-4-5, ապա սա արդեն կարող է խնդիր լինել։ Իսկ դուք արդեն պետք է փնտրեք տվյալների բազայում, նայեք կոնֆիգուրացիայի մեջ, թե ինչն է առաջացնում անցակետերի նման առատություն։ Միգուցե ինչ-որ մեծ ձայնագրություն է տեղի ունենում: Մենք արդեն կարող ենք գնահատել ծանրաբեռնվածությունը, քանի որ մենք արդեն ավելացրել ենք ծանրաբեռնվածության գրաֆիկները։ Մենք արդեն կարող ենք շտկել անցակետի պարամետրերը և համոզվել, որ դրանք մեծապես չեն ազդում հարցումների կատարման վրա:

Ես նորից վերադառնում եմ autovacuum-ին, քանի որ դա այնպիսի բան է, ինչպես ասացի, որը հեշտությամբ կարող է ավելացնել և՛ սկավառակի, և՛ հարցումների կատարողականը, ուստի միշտ կարևոր է գնահատել ավտովակուումի քանակը:

Տվյալների բազայում ավտովակուումային աշխատողների թիվը սահմանափակ է: Լռելյայնորեն դրանք երեքն են, այնպես որ, եթե մենք միշտ ունենք տվյալների բազայում աշխատող երեք աշխատող, դա նշանակում է, որ մեր ավտովակուումը կազմաձևված չէ, մենք պետք է բարձրացնենք սահմանները, վերանայենք autovacuum-ի կարգավորումները և մտնենք կազմաձևման մեջ:
Կարևոր է գնահատել, թե որ վակուումային աշխատողներ ունենք։ Կամ այն ​​գործարկվել է օգտագործողի կողմից, DBA-ն եկավ և ձեռքով գործարկեց ինչ-որ վակուում, և դա ծանրաբեռնվածություն ստեղծեց: Մենք ինչ-որ խնդիր ունենք. Կամ սա վակուումների քանակն է, որոնք արձակում են գործարքների հաշվիչը: PostgreSQL-ի որոշ տարբերակների համար դրանք շատ ծանր վակուումներ են: Եվ նրանք կարող են հեշտությամբ ավելացնել կատարողականը, քանի որ նրանք կարդում են ամբողջ աղյուսակը, սկանավորում այդ աղյուսակի բոլոր բլոկները:

Եվ, իհարկե, վակուումների տեւողությունը։ Եթե ​​մենք ունենք երկարատև վակուումներ, որոնք աշխատում են շատ երկար ժամանակ, ապա դա նշանակում է, որ մենք կրկին պետք է ուշադրություն դարձնենք վակուումի կազմաձևին և, հնարավոր է, վերանայենք դրա կարգավորումները: Որովհետև կարող է իրավիճակ ստեղծվել, երբ վակուումը երկար ժամանակ (3-4 ժամ) աշխատի սեղանի վրա, բայց վակուումը աշխատելու ընթացքում կրկին հաջողվել է մեծ քանակությամբ մեռած շարքեր կուտակվել աղյուսակում։ Եվ հենց որ վակուումը ավարտվի, նա պետք է նորից վակուումի այս սեղանը: Եվ մենք գալիս ենք մի իրավիճակի՝ անվերջ վակուումի։ Եվ այս դեպքում վակուումը չի հաղթահարում իր աշխատանքը, և աղյուսակները աստիճանաբար սկսում են մեծանալ չափերով, թեև դրա մեջ օգտակար տվյալների ծավալը մնում է նույնը: Հետևաբար, երկար վակուումների ժամանակ մենք միշտ նայում ենք կոնֆիգուրացիան և փորձում ենք այն օպտիմալացնել, բայց միևնույն ժամանակ, որպեսզի հաճախորդի հարցումների կատարումը չտուժի:

Մեր օրերում գործնականում չկա PostgreSQL տեղադրում, որը չունի հոսքային կրկնօրինակում: Replication-ը տվյալների վարպետից կրկնօրինակ տեղափոխելու գործընթաց է:

PostgreSQL-ում կրկնօրինակումը կատարվում է գործարքների մատյանի միջոցով: Վիզարդը ստեղծում է գործարքների մատյան: Գործարքների գրանցամատյանը ցանցային միացումով անցնում է կրկնօրինակին, այնուհետև այն վերարտադրվում է կրկնօրինակի վրա: Դա պարզ է.

Համապատասխանաբար, pg_stat_replication տեսքը օգտագործվում է կրկնօրինակման հետաձգումը վերահսկելու համար: Բայց նրա հետ ամեն ինչ պարզ չէ: 10-րդ տարբերակում տեսքը մի քանի փոփոխության է ենթարկվել։ Նախ, որոշ դաշտեր վերանվանվել են: Եվ որոշ դաշտեր ավելացվել են: 10 տարբերակում հայտնվեցին դաշտեր, որոնք թույլ են տալիս գնահատել կրկնօրինակման հետաձգումը վայրկյաններով: Շատ հարմարավետ է։ Մինչև 10 տարբերակը հնարավոր էր գնահատել կրկնօրինակման հետաձգումը բայթերով: Այս տարբերակը մնում է 10-րդ տարբերակում, այսինքն՝ դուք կարող եք ընտրել այն, ինչը ձեզ համար ավելի հարմար է՝ գնահատեք ուշացումը բայթերով կամ գնահատեք ուշացումը վայրկյաններով: Շատերն անում են երկուսն էլ:

Բայց այնուամենայնիվ, կրկնօրինակման հետաձգումը գնահատելու համար հարկավոր է իմանալ գրանցամատյանի դիրքը գործարքում։ Եվ գործարքների գրանցամատյանի այս դիրքերը հենց pg_stat_replication տեսքում են: Համեմատաբար ասած, մենք կարող ենք երկու կետ վերցնել գործարքների մատյանում՝ օգտագործելով pg_xlog_location_diff() ֆունկցիան։ Հաշվեք նրանց միջև եղած դելտան և ստացեք կրկնօրինակման հետաձգումը բայթերով: Դա շատ հարմար է և պարզ:

10 տարբերակում այս ֆունկցիան վերանվանվել է pg_wal_lsn_diff(): Ընդհանուր առմամբ, բոլոր գործառույթներում, դիտումներում և կոմունալ ծառայություններում, որտեղ հայտնաբերվել է «xlog» բառը, այն փոխարինվել է «wal» արժեքով: Սա վերաբերում է ինչպես դիտումներին, այնպես էլ գործառույթներին: Սա այսպիսի նորամուծություն է։

Բացի այդ, 10-րդ տարբերակում ավելացվել են տողեր, որոնք հատուկ ցույց են տալիս ուշացումը: Դրանք են՝ գրելու ուշացում, flush lag, replay lag: Այսինքն՝ կարևոր է վերահսկել այս բաները։ Եթե ​​մենք տեսնում ենք, որ մենք ունենք կրկնօրինակման հետաձգում, ապա մենք պետք է ուսումնասիրենք, թե ինչու է այն հայտնվել, որտեղից է առաջացել և շտկել խնդիրը:

Համակարգային ցուցանիշներով գրեթե ամեն ինչ կարգին է: Երբ սկսվում է ցանկացած մոնիտորինգ, այն սկսվում է համակարգի չափիչներից: Սա պրոցեսորների, հիշողության, փոխանակման, ցանցի և սկավառակի հեռացումն է: Այնուամենայնիվ, շատ պարամետրեր չկան լռելյայն:

Եթե ​​վերամշակման գործընթացում ամեն ինչ կարգին է, ապա սկավառակի վերամշակման հետ կապված խնդիրներ կան: Որպես կանոն, մոնիտորինգի մշակողները տեղեկատվություն են ավելացնում թողունակության մասին: Այն կարող է լինել iops կամ բայթ: Բայց նրանք մոռանում են ուշացման և սկավառակի սարքերի օգտագործման մասին: Սրանք ավելի կարևոր պարամետրեր են, որոնք թույլ են տալիս գնահատել, թե որքանով են բեռնված մեր սկավառակները և որքան դանդաղ են դրանք: Եթե ​​մենք ունենք մեծ հետաձգում, ապա դա նշանակում է, որ սկավառակների հետ կապված որոշ խնդիրներ կան: Եթե ​​մենք ունենք բարձր կիրառություն, դա նշանակում է, որ սկավառակները չեն հաղթահարում: Սրանք ավելի լավ բնութագրեր են, քան թողունակությունը:

Ավելին, այս վիճակագրությունը կարելի է ստանալ նաև /proc ֆայլային համակարգից, ինչպես դա արվում է վերամշակող պրոցեսորների համար։ Ես չգիտեմ, թե ինչու այս տեղեկատվությունը չի ավելացվում մոնիտորինգին: Բայց, այնուամենայնիվ, կարևոր է սա ունենալ ձեր մոնիտորինգում:

Նույնը վերաբերում է ցանցային ինտերֆեյսներին: Տեղեկություններ կան ցանցի թողունակության մասին փաթեթներով, բայթերով, բայց, այնուամենայնիվ, չկա որևէ տեղեկություն ուշացման և օգտագործման մասին, թեև սա նույնպես օգտակար տեղեկատվություն է:

Ցանկացած մոնիտորինգ ունի թերություններ. Եվ անկախ նրանից, թե ինչպիսի մոնիտորինգ եք անում, այն միշտ չի համապատասխանի որոշ չափանիշների: Բայց, այնուամենայնիվ, դրանք զարգանում են, նոր հնարավորություններ և նոր բաներ են ավելացվում, այնպես որ ընտրեք ինչ-որ բան և ավարտեք այն:

Եվ ավարտելու համար դուք միշտ պետք է պատկերացում ունենաք, թե ինչ է նշանակում տրամադրված վիճակագրությունը և ինչպես կարող եք դրանք օգտագործել խնդիրները լուծելու համար:

Եվ մի քանի հիմնական կետ.

• Դուք միշտ պետք է վերահսկեք հասանելիությունը և ունենաք վահանակներ, որպեսզի կարողանաք արագ գնահատել, որ տվյալների բազայում ամեն ինչ կարգին է:
• Դուք միշտ պետք է պատկերացում ունենաք, թե ինչ հաճախորդներ են աշխատում ձեր տվյալների բազայի հետ՝ վատ հաճախորդներին հեռացնելու և նրանց ոչնչացնելու համար:
• Կարևոր է գնահատել, թե ինչպես են այս հաճախորդները աշխատում տվյալների հետ: Դուք պետք է պատկերացում ունենաք ձեր ծանրաբեռնվածության մասին:
• Կարևոր է գնահատել, թե ինչպես է ձևավորվում այս ծանրաբեռնվածությունը, ինչ հարցումների օգնությամբ։ Դուք կարող եք գնահատել հարցումները, կարող եք դրանք օպտիմալացնել, վերափոխել դրանք, կառուցել ինդեքսներ նրանց համար: Դա շատ կարեւոր է.
• Ֆոնային գործընթացները կարող են բացասաբար ազդել հաճախորդների հարցումների վրա, ուստի կարևոր է հետևել, որ նրանք չափազանց շատ ռեսուրսներ չեն օգտագործում:
• Համակարգի չափումները թույլ են տալիս պլաններ կազմել ձեր սերվերների մասշտաբավորման և հզորության մեծացման համար, ուստի կարևոր է նաև հետևել և գնահատել դրանք:

Եթե ​​ձեզ հետաքրքրում է այս թեման, ապա կարող եք հետևել այս հղումներին։
http://bit.do/stats_collector - սա վիճակագրության հավաքագրողի պաշտոնական փաստաթղթերն են: Կա բոլոր վիճակագրական դիտումների նկարագրությունը և բոլոր ոլորտների նկարագրությունը: Դուք կարող եք կարդալ, հասկանալ և վերլուծել դրանք: Եվ դրանց հիման վրա կառուցեք ձեր գրաֆիկները և ավելացրեք դրանք ձեր մոնիտորինգին:

Հարցման օրինակներ.
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

Սա մեր կորպորատիվ պահեստն է և իմ սեփականը: Դրանք պարունակում են հարցումների օրինակներ: Այնտեղ ընտրված* շարքից հարցումներ չկան: Արդեն կան միացումներով պատրաստ հարցումներ՝ օգտագործելով հետաքրքիր գործառույթներ, որոնք թույլ են տալիս չմշակված թվերը վերածել ընթեռնելի, հարմար արժեքների, այսինքն՝ դրանք բայթեր են, ժամանակ։ Դուք կարող եք դրանք վերցնել, նայել, վերլուծել դրանք, ավելացնել դրանք ձեր մոնիտորինգին, դրանց հիման վրա կառուցել ձեր մոնիտորինգը:

Հարցեր

Հարց. Դուք ասացիք, որ չեք գովազդելու ապրանքանիշեր, բայց ինձ դեռ հետաքրքիր է. ինչպիսի՞ վահանակներ եք օգտագործում ձեր նախագծերում:
Պատասխան. Այն տարբերվում է: Պատահում է, որ գալիս ենք հաճախորդի մոտ, և նա արդեն ունի իր մոնիտորինգը։ Եվ մենք հաճախորդին խորհուրդ ենք տալիս, թե ինչ պետք է ավելացվի իր մոնիտորինգին: Ամենավատ իրավիճակը Zabbix-ի հետ է: Քանի որ այն չունի TopN գրաֆիկներ կառուցելու հնարավորություն: Մենք ինքներս ենք օգտագործում Օկմետր, քանի որ մոնիտորինգի շուրջ խորհրդակցում էինք այս տղաների հետ։ Նրանք վերահսկում էին PostgreSQL-ը՝ հիմնվելով մեր տեխնիկական բնութագրերի վրա: Ես գրում եմ իմ սեփական ընտանի կենդանիների նախագիծը, որը տվյալներ է հավաքում Պրոմեթևսի միջոցով և ներկայացնում դրանք Գրաֆանա. Իմ խնդիրն է ստեղծել իմ սեփական արտահանողը Պրոմեթևսում և հետո ամեն ինչ մատուցել Գրաֆանայում:

Հարց. Կա՞ն արդյոք AWR հաշվետվությունների անալոգներ կամ... ագրեգացիա: Դուք գիտե՞ք նման բանի մասին։
Պատասխան. Այո, ես գիտեմ, թե ինչ է AWR-ն, դա լավ բան է: Այս պահին կան մի շարք հեծանիվներ, որոնք իրականացնում են մոտավորապես հետևյալ մոդելը. Ժամանակի որոշակի միջակայքում որոշ բազային տողեր գրվում են նույն PostgreSQL-ում կամ առանձին պահեստում: Դուք կարող եք դրանք google-ում փնտրել ինտերնետում, դրանք այնտեղ են: Նման բան մշակողներից մեկը նստած է sql.ru ֆորումում՝ PostgreSQL թեմայում։ Դուք կարող եք բռնել նրան այնտեղ: Այո, կան նման բաներ, դրանք կարելի է օգտագործել։ Գումարած իր մեջ pgCenter Ես նաև գրում եմ մի բան, որը ձեզ թույլ է տալիս նույն բանն անել:

Հ.Գ.1 Եթե դուք օգտագործում եք postgres_exporter, ի՞նչ վահանակ եք օգտագործում: Դրանք մի քանիսն են։ Դրանք արդեն հնացել են։ Միգուցե համայնքը թարմացված կաղապար ստեղծի՞։

PS2 Հեռացվել է pganalyze-ը, քանի որ այն սեփականության SaaS առաջարկ է, որը կենտրոնանում է կատարողականի մոնիտորինգի և ավտոմատացված թյունինգի առաջարկների վրա:

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Ո՞ր ինքնակառավարվող postgresql մոնիտորինգը (վահանակով) եք համարում լավագույնը:

• 30,0%Zabbix + լրացումներ Ալեքսեյ Լեսովսկուց կամ zabbix 4.4 կամ libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze-ը սեփականատիրական SaaS է. ես չեմ կարող ջնջել այն1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

Քվեարկել է 10 օգտատեր։ 26 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com