Տիպիկ սխալներ հավելվածներում, որոնք հանգեցնում են փքվածության postgresql-ում: Անդրեյ Սալնիկով

Առաջարկում եմ կարդալ Անդրեյ Սալնիկովի 2016 թվականի սկզբի զեկույցի սղագրությունը «Տիպիկ սխալներ հավելվածներում, որոնք հանգեցնում են փքվածության postgresql-ում»

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

Ուրախ եմ ողջունել բոլորին: Այս զեկույցն այնքան տեխնիկական չէ, որքան իմ գործընկերոջ նախորդը: Այս զեկույցը հիմնականում ուղղված է backend համակարգերի մշակողներին, քանի որ մենք ունենք բավականին մեծ թվով հաճախորդներ: Եվ նրանք բոլորն էլ նույն սխալներն են անում։ Ես ձեզ կասեմ նրանց մասին: Ես կբացատրեմ, թե ինչ ճակատագրական ու վատ բաների են հանգեցնում այս սխալները։

Ինչու են սխալներ թույլ տալիս: Դրանք արվում են երկու պատճառով՝ պատահական, միգուցե ստացվի և որոշ մեխանիզմների անտեղյակության պատճառով, որոնք առաջանում են տվյալների բազայի և հավելվածի միջև, ինչպես նաև հենց տվյալների բազայում:

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

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

Ափսեի նախնական տվյալները՝ բավականին փոքր է՝ 2 ՄԲ։ Տվյալների բազայի և կոնկրետ նշանի պատասխանի ժամանակը նույնպես շատ լավ է։ Եվ բավականին լավ ծանրաբեռնվածություն՝ ըստ ափսեի, վայրկյանում 2 գործողություն։

Եվ այս զեկույցի միջոցով ես ձեզ ցույց կտամ գրաֆիկներ, որպեսզի դուք հստակ հասկանաք, թե ինչ է կատարվում։ Միշտ կլինի 2 սլայդ գրաֆիկներով: Առաջին սլայդն այն է, ինչ տեղի է ունենում ընդհանուր առմամբ սերվերում:

Եվ այս իրավիճակում մենք տեսնում ենք, որ մենք իսկապես փոքր նշան ունենք. Ցուցանիշը փոքր է՝ 2 ՄԲ: Սա ձախ կողմում գտնվող առաջին գրաֆիկն է:

Սերվերի միջին արձագանքման ժամանակը նույնպես կայուն է և կարճ: Սա վերևի աջ գրաֆիկն է:

Ներքևի ձախ գրաֆիկը ցույց է տալիս ամենաերկար գործարքները: Մենք տեսնում ենք, որ գործարքներն արագ են ավարտվում։ Եվ ավտովակուումը դեռ չի աշխատում այստեղ, քանի որ դա մեկնարկային թեստ էր: Այն կշարունակի գործել և օգտակար կլինի մեզ։

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

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

Եվ հիմա մենք ունենք ողբերգություն. Չգիտես ինչու, վաղուց մոռացված գործարք կա։ Պատճառները սովորաբար բոլորը տարօրինակ են.

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

Ո՞ւր են տանում նման բաները։

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

Եվ տեսնենք, թե ինչ կլինի: Ներքևի ձախ գրաֆիկը ցույց է տալիս, որ մենք երկար երկար գործարք ունենք: Եվ եթե նայենք վերևի ձախ գրաֆիկին, ապա կտեսնենք, որ մեր աղյուսակի չափը հանկարծակի ցատկել է երկու մեգաբայթից մինչև 300 մեգաբայթ: Միևնույն ժամանակ, աղյուսակում տվյալների քանակը չի փոխվել, այսինքն՝ այնտեղ բավականին մեծ քանակությամբ աղբ կա։

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

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

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

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

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

Մասնավորապես, ըստ հաշիվների փորձարկման ցուցանակի, որտեղ մենք փոխում ենք մնացորդները. հարցման պատասխանի ժամանակը կարծես թե վերադարձել է նորմալ: Բայց իրականում մեկուկես անգամ ավելի բարձր է։

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

Ընդհանուր առմամբ լավ է, բայց իրավիճակն ավելի վատ է, քան եղել է: Մաքրել տվյալների բազայի դեգրադացիան՝ որպես այս տվյալների բազայի հետ աշխատող մեր հավելվածի հետևանք:

Եվ հասկանալու համար, թե ինչ է կատարվում այնտեղ, եթե նախորդ զեկույցում չէիք, հիմա եկեք մի փոքր տեսություն ստանանք: Տեսություն ներքին գործընթացի մասին. Ինչու է մեքենայի վակուումը և ինչ է դա անում:

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

Ինչու՞ է ձեզ անհրաժեշտ մեքենայի վակուում: Ինչ-որ պահի գալիս է ավտովակուումը, մուտք է գործում տվյալների բազա և հարցնում. «Խնդրում եմ, տվեք ինձ ամենահին գործարքի ID-ն, որը ներկայումս բաց է տվյալների բազայում»: Տվյալների բազան վերադարձնում է այս ID-ն: Եվ ավտովակուումը, հենվելով դրա վրա, դասավորում է աղյուսակի գծերը: Եվ եթե նա տեսնում է, որ որոշ տողեր փոխվել են շատ ավելի հին գործարքներով, ապա նա իրավունք ունի դրանք նշել որպես տողեր, որոնք մենք կարող ենք հետագայում նորից օգտագործել՝ այնտեղ նոր տվյալներ գրելով։ Սա ֆոնային գործընթաց է:

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

Ի՞նչ է պատահել վթարի ժամանակ. Ինչպե՞ս եղավ այդ գործընթացը այնտեղ։

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

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

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

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

Ի՞նչ հետևանքներ կարող են լինել մեզ համար:

• Իմ օրինակում աղյուսակը և ինդեքսն աճել են 150 անգամ։ Մեր որոշ հաճախորդներ ունեցել են ավելի շատ մահացու դեպքեր, երբ նրանք պարզապես սկսել են սպառվել սկավառակի տարածքից:
• Սեղանների չափն ինքնին երբեք չի նվազի։ Autovacuum-ը որոշ դեպքերում կարող է կտրել սեղանի պոչը, եթե կան միայն մեռած գծեր: Բայց քանի որ մշտական ​​պտույտ կա, մի կանաչ տողը վերջում կարող է սառչել և չթարմացվել, մինչդեռ մնացած բոլորը գրվելու են ինչ-որ տեղ ափսեի սկզբում: Բայց սա այնքան անհավանական իրադարձություն է, որ ձեր սեղանն ինքնին կփոքրանա չափերով, այնպես որ դրա վրա հույս չունենաք:
• Տվյալների բազան պետք է տեսակավորի անօգուտ տողերի մի ամբողջ փունջ: Եվ մենք վատնում ենք սկավառակի ռեսուրսները, մենք վատնում ենք պրոցեսորի ռեսուրսները և էլեկտրաէներգիան:
• Եվ սա ուղղակիորեն ազդում է մեր հավելվածի վրա, քանի որ եթե սկզբում մենք ծախսում էինք 10 միլիվայրկյան խնդրանքի վրա, 10 միլիվայրկյան մեր կոդի վրա, ապա խափանման ժամանակ մենք սկսեցինք ծախսել մեկ վայրկյան հարցման վրա և 10 միլիվայրկյան կոդի վրա, այսինքն. կիրառման արդյունավետության մեծությունը նվազել է: Եվ երբ վթարը լուծվեց, մենք սկսեցինք ծախսել 20 միլիվայրկյան խնդրանքով, 10 միլիվայրկյան՝ կոդի վրա: Սա նշանակում է, որ արտադրողականությունը դեռ մեկուկես անգամ անկում է ապրել։ Եվ այս ամենը մեկ գործարքի պատճառով, որը սառեցվել է, գուցե մեր մեղքով:
• Եվ հարցը. «Ինչպե՞ս կարող ենք ամեն ինչ վերադարձնել», որպեսզի մեզ մոտ ամեն ինչ լավ լինի, և խնդրանքները հայտնվեն նույնքան արագ, որքան վթարից առաջ:

Այդ նպատակով կա աշխատանքի որոշակի ցիկլ, որն իրականացվում է։

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

Այս աղյուսակները գտնելուց հետո դուք պետք է սեղմեք դրանք: Դրա համար արդեն գործիքներ կան։ Մեր ընկերությունում մենք օգտագործում ենք երեք գործիք. Առաջինը ներկառուցված VACUUM FULL-ն է: Նա դաժան է, կոպիտ և անողոք, բայց երբեմն շատ օգտակար է։ Pg_repack и pgcompactable - Սրանք երրորդ կողմի կոմունալ ծառայություններ են աղյուսակները սեղմելու համար: Եվ նրանք ավելի ուշադիր են վերաբերվում տվյալների բազային:

Դրանք օգտագործվում են կախված նրանից, թե որն է ձեզ ավելի հարմար։ Բայց ես ձեզ կասեմ այս մասին ամենավերջում: Հիմնական բանը այն է, որ կան երեք գործիքներ. Ընտրելու շատ տարբերակներ կան:

Ամեն ինչ շտկելուց և համոզվելուց հետո, որ ամեն ինչ լավ է, մենք պետք է իմանանք, թե ինչպես կանխել այս իրավիճակը ապագայում.

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

Այս գծապատկերներում ես ուզում էի ցույց տալ ձեզ, թե ինչպես է փոխվել տվյալների բազայի նշանը և վարքագիծը այն բանից հետո, երբ ես այս դեպքում անցա VACUUM FULL նշանը: Սա ինձ համար արտադրություն չէ։

Սեղանի չափը անմիջապես վերադարձավ իր նորմալ աշխատանքային վիճակին՝ մի քանի մեգաբայթ: Սա մեծապես չի ազդել սերվերի միջին արձագանքման ժամանակի վրա:

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

Այստեղ ավարտվում է առաջին պատմությունը։ Ամենատարածվածն է։ Եվ դա պատահում է բոլորի հետ՝ անկախ հաճախորդի փորձից և ծրագրավորողների որակավորումից: Վաղ թե ուշ դա տեղի է ունենում։

Երկրորդ պատմությունը, որտեղ մենք բաշխում ենք բեռնվածությունը և օպտիմիզացնում սերվերի ռեսուրսները

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

Իսկ ինչպիսի՞ն է այս իրավիճակը: Կոնկրետ այս գրաֆիկների վրա ես նաև ավելացրել եմ գործարքների տևողությունը կրկնօրինակից՝ գործարքի տևողության համար: Մնացած բոլոր գրաֆիկները վերաբերում են միայն Master սերվերին:

Այս պահին իմ հաշվետվական վահանակը մեծացել էր: Դրանք ավելի շատ են: Մենք տեսնում ենք, որ սերվերի արձագանքման միջին ժամանակը կայուն է: Մենք տեսնում ենք, որ կրկնօրինակի վրա մենք ունենք երկարաժամկետ գործարք, որն աշխատում է 2 ժամ: Մենք տեսնում ենք ավտովակուումի հանգիստ աշխատանքը, որը մշակում է մեռյալ գծեր: Եվ մեզ մոտ ամեն ինչ լավ է:

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

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

Մենք մտնում ենք առցանց և սկսում ենք կարդալ, թե ինչու է դա տեղի ունենում: Եվ մենք լուծում ենք գտնում։

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

Մենք ցանկանում ենք, որ ամեն ինչ կատարյալ լինի: Մենք ավելի ենք բարձրանում: Եվ ինտերնետում մենք գտանք մի հիանալի պարամետր՝ hot_standby_feedback: Եկեք միացնենք այն: Hot_standby_feedback-ը թույլ է տալիս մեզ հետ պահել Master-ի ավտովակուումը: Այսպիսով, մենք լիովին ազատվում ենք կրկնօրինակման կոնֆլիկտներից: Իսկ հաշվետվություններով մեզ մոտ ամեն ինչ լավ է ստացվում։

Իսկ ի՞նչ է կատարվում այս պահին Master սերվերի հետ: Եվ մենք ընդհանուր խնդիրների մեջ ենք Master սերվերի հետ: Այժմ մենք տեսնում ենք գրաֆիկները, երբ ես միացված եմ այս երկու կարգավորումները: Եվ մենք տեսնում ենք, որ մեր կրկնօրինակի նիստը ինչ-որ կերպ սկսեց ազդել Master սերվերի իրավիճակի վրա: Նա իսկապես ազդեցություն ունի, քանի որ նա դադարեցրեց ավտովակուումը, որը մաքրում է վերջնաժամկետները: Մեր սեղանի չափը կրկին բարձրացել է: Ամբողջ տվյալների բազայում հարցումների կատարման միջին ժամանակը նույնպես կտրուկ աճեց: Ավտովակումները մի փոքր սեղմվեցին:

Մասնավորապես, մեր ափսեից մենք տեսնում ենք, որ դրա վրա առկա տվյալների թարմացումը նույնպես թռավ դեպի երկինք: CPU-ի սպառումը նույնպես մեծապես աճել է: Մենք կրկին անցնում ենք մեծ թվով մեռած, անպետք գծերի միջով։ Եվ այս նշանի արձագանքման ժամանակը և գործարքների քանակը նվազել են:

Ինչ տեսք կունենա, եթե մենք չգիտենք, թե ինչի մասին էի խոսում նախկինում:

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

Այս պահին մեր կրկնօրինակի հարցումը մշակվել և հեռացվել է: Մենք ստացանք հաշվետվությունը։ Բիզնեսը դեռ երջանիկ է։ Ինչպես տեսնում եք, մեր նշանը կրկին մեծացել է և չի պատրաստվում փոքրանալ։ Սեսիաներով գրաֆիկի վրա ես թողեցի այս երկար գործարքի մի հատվածը կրկնօրինակից, որպեսզի կարողանաք գնահատել, թե որքան ժամանակ է պահանջվում, մինչև իրավիճակը կայունանա:

Նիստն ավարտվել է։ Եվ միայն որոշ ժամանակ անց սերվերը քիչ թե շատ կարգի է գալիս։ Իսկ Master սերվերի հարցումների պատասխանման միջին ժամանակը վերադառնում է նորմալ: Որովհետև, վերջապես, ավտովակուումը հնարավորություն ունի մաքրել և նշել այս վերջնաժամկետները: Եվ նա սկսեց իր գործն անել։ Եվ որքան արագ է նա դա անում, այնքան արագ մենք կարգի կբերենք:

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

Ամեն դեպքում, մենք ստանում ենք կատարողականի նվազում, ինչպես առաջին դեպքում, մեկուկես-երկու անգամ, իսկ երբեմն էլ ավելի:

Կարծես ամեն ինչ ճիշտ ենք արել։ Բաշխեք բեռը. Սարքավորումները պարապ չեն. Խնդրանքները բաժանեցինք ըստ մեր մտքի, բայց այնուամենայնիվ ամեն ինչ վատ ստացվեց։

• Չե՞ք միացնում hot_standby_feedback-ը: Այո, խորհուրդ չի տրվում այն ​​միացնել առանց առանձնապես ուժեղ պատճառների։ Քանի որ այս շրջադարձն ուղղակիորեն ազդում է Master սերվերի վրա և կասեցնում է այնտեղ ավտովակուումի աշխատանքը: Միացնելով այն ինչ-որ կրկնօրինակի վրա և մոռանալով դրա մասին՝ կարող եք սպանել Վարպետին և մեծ խնդիրներ ունենալ հավելվածի հետ:
• Մեծացնե՞լ max_standby_streaming_delay-ը: Այո, զեկույցների համար դա ճիշտ է: Եթե ​​ունեք երեք ժամանոց հաշվետվություն և չեք ցանկանում, որ այն խափանվի կրկնօրինակման հակասությունների պատճառով, ապա պարզապես ավելացրեք ուշացումը: Երկարաժամկետ հաշվետվությունը երբեք չի պահանջում տվյալներ, որոնք հայտնվել են տվյալների բազայում հենց հիմա: Եթե ​​դուք ունեք այն երեք ժամով, ապա այն աշխատում եք հին տվյալների ժամանակաշրջանի համար: Իսկ ձեզ համար երեք ժամ ուշացում կամ վեց ժամ ուշացում չի լինի, բայց դուք հետևողականորեն հաշվետվություններ կստանաք և դրանց ընկնելու հետ կապված խնդիրներ չեք ունենա։
• Բնականաբար, դուք պետք է վերահսկեք երկար նիստերը կրկնօրինակների վրա, հատկապես, եթե որոշեք միացնել hot_standby_feedback-ը կրկնօրինակի վրա: Քանի որ ամեն ինչ կարող է պատահել: Մենք այս կրկնօրինակը տվեցինք մշակողին, որպեսզի նա կարողանա ստուգել հարցումները: Նա խելահեղ խնդրանք է գրել. Նա գործարկեց այն և գնաց թեյ խմելու, և մենք ստացանք հաստատված Վարպետը: Կամ գուցե մենք սխալ հավելված ենք տեղադրել այնտեղ: Իրավիճակները բազմազան են. Կրկնօրինակների վերաբերյալ նիստերը պետք է վերահսկվեն նույնքան ուշադիր, որքան Master-ը:
• Եվ եթե դուք ունեք արագ և երկար հարցումներ կրկնօրինակների վերաբերյալ, ապա այս դեպքում ավելի լավ է դրանք բաժանել բեռը բաշխելու համար: Սա հղում է դեպի streaming_delay: Արագների համար ունեցեք մեկ կրկնօրինակ՝ կրկնօրինակման փոքր ուշացումով: Երկարատև հաշվետվության հարցումների դեպքում ունեցեք կրկնօրինակ, որը կարող է հետ մնալ 6 ժամով կամ մեկ օրով: Սա լրիվ նորմալ իրավիճակ է։

Մենք վերացնում ենք հետևանքները նույն կերպ.

• Մենք գտնում ենք փքված սեղաններ:
• Եվ մենք այն սեղմում ենք մեզ հարմար ամենահարմար գործիքով։

Երկրորդ պատմությունն ավարտվում է այստեղ. Անցնենք երրորդ պատմությանը.

Նաև բավականին տարածված է մեզ համար, որտեղ մենք միգրացիա ենք անում:

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

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

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

Միգրացիան իրականացրինք ու նորից խնդիրներ ունեցանք։

Միգրացիան հաջող էր, բայց.

• Հին ֆունկցիոնալությունն այժմ ավելի երկար է տևում ավարտելու համար:
• Սեղանը նորից մեծացավ։
• Սերվերի ծանրաբեռնվածությունը կրկին ավելի մեծ դարձավ, քան նախկինում:
• Եվ, իհարկե, մենք դեռ շարունակում ենք այն ֆունկցիոնալությունը, որը լավ էր աշխատում, մենք մի փոքր բարելավել ենք այն:

Եվ սա կրկին փքվածություն է, որը կրկին փչացնում է մեր կյանքը:

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

Եվ եթե անդրադառնանք հաշիվներով աղյուսակին, ապա կտեսնենք, որ այս աղյուսակի համար միջին հարցման ժամանակը կրկնապատկվել է։ Պրոցեսորի ծանրաբեռնվածությունը և հիշողության մեջ դասավորված տողերի քանակը ցատկել է 7,5-ից, բայց ավելի քիչ: Եվ պրոցեսորների դեպքում այն ​​ցատկել է 2 անգամ, բլոկ գործառնությունների դեպքում՝ 1,5 անգամ, այսինքն՝ մենք ստացել ենք սերվերի աշխատանքի դեգրադացիա։ Եվ արդյունքում՝ մեր հավելվածի կատարողականի դեգրադացիա։ Միաժամանակ զանգերի թիվը մնացել է մոտավորապես նույն մակարդակի վրա։

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

• Նման մեծ միգրացիաները ինքնաբերաբար չեն լինում։ Նրանք միշտ պետք է լինեն վերահսկողության տակ։
• Պահանջվում է հսկողություն բանիմաց անձի կողմից։ Եթե ​​դուք ունեք DBA ձեր թիմում, ապա թույլ տվեք DBA-ին դա անել: Դա իր գործն է: Եթե ​​ոչ, ապա թող դա անի ամենափորձառու մարդը, ով գիտի, թե ինչպես աշխատել տվյալների բազաների հետ։
• Տվյալների բազայի նոր սխեման, նույնիսկ եթե մենք թարմացնում ենք մեկ սյունակ, մենք միշտ պատրաստվում ենք փուլերով, այսինքն՝ նախապես՝ մինչև հավելվածի նոր տարբերակի դուրս գալը.
• Ավելացվում են նոր դաշտեր, որոնցում մենք կգրանցենք թարմացված տվյալները։
• Տվյալները հին դաշտից նոր դաշտ ենք փոխանցում փոքր մասերով։ Ինչու ենք մենք դա անում: Նախ, մենք միշտ վերահսկում ենք այս գործընթացի ընթացքը։ Մենք գիտենք, որ այսքան խմբաքանակ արդեն փոխանցել ենք ու այնքան էլ մեզ մնացել է։
• Եվ երկրորդ դրական էֆեկտն այն է, որ յուրաքանչյուր նման խմբաքանակի միջև մենք փակում ենք գործարքը, բացում նորը, և դա թույլ է տալիս ավտովակումին աշխատել ըստ ափսեի, նշել վերօգտագործման մեռած գծեր:
• Այն տողերի համար, որոնք կհայտնվեն հավելվածի գործարկման ընթացքում (մեզ մոտ դեռ աշխատում է հին հավելվածը), մենք ավելացնում ենք ձգան, որը նոր արժեքներ է գրում նոր դաշտերում: Մեր դեպքում սա հին արժեքի հարյուրով բազմապատկում է։
• Եթե ​​մենք լիովին համառ ենք և ցանկանում ենք նույն դաշտը, ապա բոլոր միգրացիաների ավարտից հետո և նախքան հավելվածի նոր տարբերակը բացելը, մենք պարզապես վերանվանում ենք դաշտերը: Հներին տրվում են հորինված անուններ, իսկ նոր դաշտերը վերանվանվում են հների։
• Եվ միայն դրանից հետո մենք գործարկում ենք հավելվածի նոր տարբերակը։

Եվ միևնույն ժամանակ մենք փքվածություն չենք ստանա և չենք տուժի կատարողականի առումով։

Այստեղ ավարտվում է երրորդ պատմությունը։

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

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

Իսկ հիմա մի փոքր ավելի մանրամասն այն գործիքների մասին, որոնք ես նշեցի հենց առաջին պատմության մեջ։

Նախքան bloat որոնելը, դուք պետք է տեղադրեք ընդլայնումը pgstattuple.

Որպեսզի դուք ստիպված չլինեք հարցումներ անել, մենք արդեն գրել ենք այս հարցումները մեր աշխատանքում: Դուք կարող եք օգտագործել դրանք: Այստեղ երկու խնդրանք կա.

• Առաջինը բավականին երկար ժամանակ է պահանջում աշխատելու համար, բայց այն ձեզ ցույց կտա աղյուսակի փքվածության ճշգրիտ արժեքները:
• Երկրորդն ավելի արագ է աշխատում և շատ արդյունավետ է, երբ ըստ աղյուսակի պետք է արագ գնահատել փքվածություն կա, թե ոչ։ Եվ դուք նաև պետք է հասկանաք, որ փքվածությունը միշտ առկա է Postgres աղյուսակում: Սա իր MVCC մոդելի առանձնահատկությունն է:
• Իսկ 20% փքվածությունը շատ դեպքերում նորմալ է սեղանների համար: Այսինքն, դուք չպետք է անհանգստանաք և սեղմեք այս աղյուսակը:

Մենք հասկացանք, թե ինչպես կարելի է նույնականացնել աղյուսակները, որոնք ուռած են անօգուտ տվյալներից:

Այժմ այն ​​մասին, թե ինչպես շտկել փքվածությունը.

• Եթե ​​մենք ունենք փոքր պլանշետ և լավ սկավառակներ, այսինքն՝ մինչև գիգաբայթ պլանշետի վրա, միանգամայն հնարավոր է օգտագործել VACUUM FULL-ը։ Նա ձեզանից սեղանի վրա մի քանի վայրկյանով կվերցնի բացառիկ կողպեք և լավ, բայց ամեն ինչ կանի արագ և կոշտ: Ի՞նչ է անում VACUUM FULL-ը: Այն վերցնում է բացառիկ կողպեք սեղանի վրա և վերագրում է կենդանի տողերը հին աղյուսակներից նոր աղյուսակում: Եվ վերջում փոխարինում է նրանց։ Այն ջնջում է հին ֆայլերը և փոխարինում հինները նորերով: Բայց իր աշխատանքի տևողության համար այն վերցնում է սեղանի վրա բացառիկ կողպեք: Սա նշանակում է, որ դուք չեք կարող որևէ բան անել այս աղյուսակի հետ՝ ոչ գրել դրան, ոչ կարդալ, ոչ փոփոխել այն: Իսկ VACUUM FULL-ը տվյալների գրելու համար սկավառակի լրացուցիչ տարածք է պահանջում:
• Հաջորդ գործիքը pg_repack. Իր սկզբունքով այն շատ նման է VACUUM FULL-ին, քանի որ այն նաև վերագրում է տվյալները հին ֆայլերից նորերի վրա և դրանք փոխարինում աղյուսակում։ Բայց միևնույն ժամանակ, այն չի վերցնում սեղանի վրա բացառիկ կողպեք իր աշխատանքի հենց սկզբում, այլ վերցնում է միայն այն պահին, երբ արդեն պատրաստ տվյալներ ունի՝ ֆայլերը փոխարինելու համար։ Նրա սկավառակի ռեսուրսների պահանջները նման են VACUUM FULL-ի պահանջներին: Ձեզ անհրաժեշտ է լրացուցիչ սկավառակի տարածություն, և դա երբեմն կարևոր է, եթե ունեք տերաբայթ սեղաններ: Եվ այն բավականին պրոցեսորային է, քանի որ ակտիվորեն աշխատում է I/O-ով:
• Երրորդ օգտակարությունը pgcompactable. Այն ավելի զգույշ է ռեսուրսների հետ կապված, քանի որ այն աշխատում է մի փոքր այլ սկզբունքներով: pgcompacttable-ի հիմնական գաղափարն այն է, որ այն տեղափոխում է բոլոր կենդանի տողերը աղյուսակի սկիզբ՝ օգտագործելով աղյուսակի թարմացումները: Եվ այնուհետև այն վակուում է գործում այս սեղանի վրա, քանի որ մենք գիտենք, որ սկզբում ունենք կենդանի տողեր, իսկ վերջում` մեռած տողեր: Եվ վակուումն ինքնին կտրում է այս պոչը, այսինքն, այն չի պահանջում շատ լրացուցիչ սկավառակի տարածություն: Եվ դրա հետ մեկտեղ, այն դեռ կարելի է քամել ռեսուրսների առումով։

Ամեն ինչ գործիքներով.

Եթե ​​դուք գտնում եք, որ փքվածության թեման հետաքրքիր է ներսում ավելի խորանալու առումով, ահա մի քանի օգտակար հղումներ.

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - Սա իմ գործընկերոջ զեկույցն է։ Դա ընդհանուր է այն մասին, թե որտեղ է անցնում Պոստգրեսի տարածքը իր աշխատանքի և կյանքի ընթացքում: Եվ տվյալների բազայի ադմինիստրատորների համար շատ մեծ և մանրամասն տեխնիկական նյութ կա bloat-ի մասին:
• https://github.com/dataegret/pg-utils – սա հղում է դեպի մեր պահեստ, որտեղ մենք պահում ենք մի շարք օգտակար սկրիպտներ տվյալների բազայի վիճակը ստուգելու համար: Այնտեղ կարող եք գտնել սկրիպտներ՝ bloat որոնելու համար:
• Երրորդը и չորրորդը հղումներ դեպի գործիքներ, որոնք կօգնեն ձեզ փոքրացնել նշանները:
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - Սա իմ գործընկերոջ գրառումն է: Այնտեղ նա բավականին լուրջ և տեխնիկապես մանրակրկիտ վերլուծում է փքվածությունը ադմիններին մոտ մակարդակով։

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

Հարցեր

Շնորհակալություն զեկույցի համար: Դուք խոսեցիք այն մասին, թե ինչպես կարող եք բացահայտել խնդիրները: Ինչպե՞ս կարելի է նրանց զգուշացնել: Այսինքն, ես ունեի մի իրավիճակ, երբ հարցումները կախված էին ոչ միայն այն պատճառով, որ նրանք մուտք էին գործում որոշ արտաքին ծառայություններ: Սրանք ընդամենը մի քանի վայրի միացումներ էին: Կային մի քանի փոքրիկ, անվնաս խնդրանքներ, որոնք մի օր կախված էին, իսկ հետո սկսեցին ինչ-որ անհեթեթություն անել: Այսինքն՝ շատ նման է քո նկարագրածին։ Ինչպե՞ս հետևել դրան: Նստեք և անընդհատ հետևեք, թե որ խնդրանքն է խրված: Ինչպե՞ս կարելի է դա կանխել:

Այս դեպքում սա ձեր ընկերության ադմինիստրատորների խնդիրն է, պարտադիր չէ, որ DBA-ի համար:

Ես ադմինիստրատոր եմ:

PostgreSQL-ն ունի pg_stat_activity կոչվող տեսք, որը ցույց է տալիս կախված հարցումները: Եվ դուք կարող եք տեսնել, թե որքան երկար է այն կախված այնտեղ:

Պե՞տք է 5 րոպեն մեկ ներս մտնեմ ու նայեմ:

Կարգավորեք cron-ը և ստուգեք: Եթե ​​երկարաժամկետ խնդրանք ունեք, գրեք նամակ և վերջ: Այսինքն՝ պետք չէ աչքերով նայել, այն կարելի է ավտոմատացնել։ Դուք նամակ կստանաք, արձագանքում եք դրան։ Կամ կարող եք ինքնաբերաբար կրակել:

Կա՞ն որևէ ակնհայտ պատճառ, թե ինչու է դա տեղի ունենում:

Ես թվարկել եմ մի քանիսը. Այլ ավելի բարդ օրինակներ. Իսկ զրույց կարող է երկար լինել։

Շնորհակալություն զեկույցի համար: Ես ուզում էի պարզաբանել pg_repack կոմունալը: Եթե ​​նա բացառիկ կողպեք չի անում, ապա...

Նա կատարում է բացառիկ կողպեք:

... այդ դեպքում ես կարող եմ պոտենցիալ կորցնել տվյալները: Արդյո՞ք իմ դիմումն այս ընթացքում որևէ բան չգրանցի:

Ոչ, այն սահուն աշխատում է աղյուսակի հետ, այսինքն՝ pg_repack-ը նախ փոխանցում է գոյություն ունեցող բոլոր կենդանի տողերը: Բնականաբար, այնտեղ ինչ-որ մուտք է տեղի ունենում աղյուսակում։ Նա պարզապես դուրս է նետում այս ձիու պոչը:

Այսինքն՝ նա իրականում դա անում է ի վերջո։

Ի վերջո, նա վերցնում է բացառիկ կողպեք այս ֆայլերը փոխանակելու համար:

Արդյո՞ք այն ավելի արագ կլինի, քան VACUUM FULL-ը:

VACUUM FULL, հենց սկսվեց, անմիջապես վերցրեց բացառիկ կողպեք: Եվ քանի դեռ նա չի անում ամեն ինչ, նա թույլ չի տա նրան գնալ: Իսկ pg_repack-ը բացառիկ կողպում է միայն ֆայլի փոխարինման ժամանակ: Այս պահին այնտեղ չեք գրի, բայց տվյալները չեն կորչի, ամեն ինչ լավ կլինի։

Բարեւ Ձեզ! Դուք խոսեցիք մեքենայի վակուումի աշխատանքի մասին: Կար կարմիր, դեղին և կանաչ ձայնագրող բջիջներով գրաֆիկ: Այսինքն՝ դեղինները՝ ջնջված է նշել։ Եվ արդյունքում կարելի՞ է դրանց մեջ նոր բան գրել։

Այո՛։ Postgres-ը չի ջնջում տողերը: Նա նման յուրահատկություն ունի. Եթե ​​մենք թարմացրինք տողը, մենք նշում էինք հինը որպես ջնջված: Այնտեղ հայտնվում է գործարքի ID-ն, որը փոխել է այս տողը, և մենք գրում ենք նոր տող: Եվ մենք ունենք նիստեր, որոնք կարող են դրանք կարդալ: Ինչ-որ պահի նրանք բավականին ծերանում են։ Եվ ավտովակումի աշխատանքի էությունն այն է, որ այն անցնում է այս տողերով և նշում դրանք որպես ավելորդ: Եվ այնտեղ կարող եք վերագրանցել տվյալները:

Ես հասկանում եմ. Բայց հարցը դա չէ. Ես չավարտեցի: Ենթադրենք, որ սեղան ունենք: Այն ունի փոփոխական չափի դաշտեր։ Եվ եթե ես փորձեմ ինչ-որ նոր բան տեղադրել, այն կարող է պարզապես չտեղավորվել հին խցում:

Ոչ, ամեն դեպքում ամբողջ գիծը թարմացվում է այնտեղ։ Postgres-ն ունի տվյալների պահպանման երկու մոդել: Այն ընտրում է տվյալների տեսակից: Կան տվյալներ, որոնք պահվում են անմիջապես աղյուսակում, և կան նաև tos տվյալներ։ Սրանք մեծ քանակությամբ տվյալներ են՝ տեքստ, json: Դրանք պահվում են առանձին ափսեներում։ Եվ ըստ այս պլանշետների, տեղի է ունենում փքվածության նույն պատմությունը, այսինքն՝ ամեն ինչ նույնն է։ Դրանք ուղղակի թվարկված են առանձին:

Շնորհակալություն զեկույցի համար: Արդյո՞ք ընդունելի է օգտագործել քաղվածքի ժամանակի ավարտի հարցումները՝ տևողությունը սահմանափակելու համար:

Շատ ընդունելի։ Մենք սա օգտագործում ենք ամենուր: Եվ քանի որ մենք չունենք մեր սեփական ծառայությունները, մենք տրամադրում ենք հեռավար աջակցություն, մենք ունենք բավականին բազմազան հաճախորդներ: Եվ սրանով բոլորը լիովին բավարարված են։ Այսինքն, մենք ունենք cron jobs, որոնք ստուգում են: Սեանսների տեւողությունը ուղղակի համաձայնեցվում է հաճախորդի հետ, որից առաջ մենք համաձայն չենք։ Դա կարող է լինել մեկ րոպե, կարող է լինել 10 րոպե: Դա կախված է բազայի բեռից և դրա նպատակից: Բայց մենք բոլորս օգտագործում ենք pg_stat_activity:

Շնորհակալություն զեկույցի համար: Ես փորձում եմ ձեր զեկույցը կիրառել իմ դիմումների վրա: Եվ թվում է, թե մենք գործարք ենք սկսում ամենուր և հստակորեն ավարտում ենք այն ամենուր: Եթե ​​կա որևէ բացառություն, ապա հետադարձը դեռ տեղի է ունենում: Եվ հետո ես սկսեցի մտածել. Ի վերջո, գործարքը կարող է բացահայտորեն չսկսվել: Սա, հավանաբար, ակնարկ է աղջկան: Եթե ​​ես պարզապես թարմացնեմ գրառումը, արդյոք գործարքը կսկսվի PostgreSQL-ում և կավարտվի միայն այն ժամանակ, երբ կապն անջատվի:

Եթե ​​դուք հիմա խոսում եք հավելվածի մակարդակի մասին, ապա դա կախված է ձեր օգտագործած դրայվերից, օգտագործվող ORM-ից: Այնտեղ շատ կարգավորումներ կան։ Եթե ​​դուք միացված եք ավտոմատ հանձնումը, ապա գործարքը սկսվում է այնտեղ և անմիջապես փակվում:

Այսինքն՝ թարմացումից անմիջապես հետո՞ է փակվում։

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

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Եկեք պատկերացնենք, որ մենք ունենք տվյալների բազա, որը ուռչում և ուռչում է, և հետո սերվերի տարածքը սպառվում է: Կա՞ն գործիքներ այս իրավիճակը շտկելու համար:

Սերվերի տարածքը պետք է պատշաճ կերպով վերահսկվի:

Օրինակ, DBA-ն գնացել է թեյ խմելու, եղել է հանգստավայրում և այլն:

Երբ ստեղծվում է ֆայլային համակարգ, ստեղծվում է առնվազն պահուստային տարածք, որտեղ տվյալները գրված չեն:

Իսկ եթե այն ամբողջովին զրոյից ցածր է:

Այնտեղ այն կոչվում է վերապահված տարածք, այսինքն՝ այն կարելի է ազատել և կախված նրանից, թե որքան մեծ է այն ստեղծվել, դուք ստանում եք ազատ տարածք։ Լռելյայն չգիտեմ, թե քանիսն են։ Իսկ մեկ այլ դեպքում մատուցեք սկավառակներ, որպեսզի տեղ ունենաք վերականգնողական գործողություն կատարելու համար։ Դուք կարող եք ջնջել որոշ աղյուսակներ, որոնք ձեզ երաշխավորված չեն:

Կա՞ն այլ գործիքներ:

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

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

Նրանք նույնպես փաթեթավորում են դրանք:

Բայց վակուումը չի՞ ազդում ինդեքսի վրա։

Ոմանք աշխատում են ինդեքսով: Օրինակ՝ pg_rapack, pgcompacttable: Վակուումը վերստեղծում է ինդեքսները և ազդում դրանց վրա։ VACUUM FULL-ի հետ գաղափարն այն է, որ վերագրանցվի ամեն ինչ, այսինքն՝ այն աշխատում է բոլորի հետ:

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

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

Անդրեյ, ես մի հարց ունեմ. Այս հիանալի գրաֆիկները, որ ցուցադրեցիք շնորհանդեսի ժամանակ, արդյոք սրանք ձեր ինչ-որ օգտակարության աշխատանքի արդյունքն են։ Ինչպե՞ս են կազմվել գրաֆիկները:

Սա ծառայություն է Օկմետր.

Արդյո՞ք սա կոմերցիոն արտադրանք է:

Այո՛։ Սա կոմերցիոն արտադրանք է:

Source: www.habr.com