Linux-ի թյունինգ՝ PostgreSQL-ի աշխատանքը բարելավելու համար: Իլյա Կոսմոդեմյանսկի

Իլյա Կոսմոդեմյանսկու 2015 թվականի զեկույցի սղագրությունը «Linux թյունինգ՝ PostgreSQL-ի աշխատանքը բարելավելու համար»

Հրաժարում. Ես նշում եմ, որ այս զեկույցը թվագրված է 2015 թվականի նոյեմբերին. անցել է ավելի քան 4 տարի և անցել է շատ ժամանակ: Զեկույցում քննարկված 9.4 տարբերակն այլևս չի աջակցվում: Վերջին 4 տարիների ընթացքում թողարկվել է PostgreSQL-ի 5 նոր թողարկում և թողարկվել է Linux միջուկի 15 տարբերակ: Եթե ​​դուք վերաշարադրեք այս հատվածները, կհայտնվեք այլ զեկույցով: Բայց այստեղ մենք դիտարկում ենք Linux-ի հիմնարար թյունինգ PostgreSQL-ի համար, որն այսօր էլ արդիական է:

Ես Իլյա Կոսմոդեմյանսկին եմ։ Ես աշխատում եմ PostgreSQL-Consulting-ում: Իսկ հիմա ես մի փոքր կխոսեմ այն ​​մասին, թե ինչ անել Linux-ի հետ առհասարակ տվյալների բազաների և մասնավորապես PostgreSQL-ի հետ կապված, քանի որ սկզբունքները բավականին նման են։

Ինչի՞ մասին ենք խոսելու։ Եթե ​​դուք շփվում եք PostgreSQL-ի հետ, ապա որոշ չափով պետք է լինեք UNIX-ի ադմին։ Ինչ է դա նշանակում? Եթե ​​համեմատենք Oracle-ը և PostgreSQL-ը, ապա Oracle-ում դուք պետք է լինեք 80% DBA տվյալների բազայի ադմինիստրատոր և 20% Linux-ի ադմին:

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

Ինչու ենք մենք խոսում Linux-ի մասին: Ամենևին այն պատճառով, որ մենք Linux կոնֆերանսին ենք Peter, այլ այն պատճառով, որ ժամանակակից պայմաններում տվյալների բազաների օգտագործման ամենաարդարացված օպերացիոն համակարգերից մեկը, մասնավորապես, PostgreSQL-ը Linux-ն է։ Քանի որ FreeBSD-ն, ցավոք, զարգանում է շատ տարօրինակ ուղղությամբ: Եվ խնդիրներ կլինեն և՛ կատարողականի, և՛ շատ այլ բաների հետ կապված։ PostgreSQL-ի կատարումը Windows-ում, ընդհանուր առմամբ, առանձին լուրջ խնդիր է, որը հիմնված է այն փաստի վրա, որ Windows-ը չունի նույն ընդհանուր հիշողությունը, ինչ UNIX-ը, մինչդեռ PostgreSQL-ն ամեն ինչ կապված է դրա հետ, քանի որ այն բազմապրոցեսային համակարգ է:

Եվ ես կարծում եմ, որ բոլորին ավելի քիչ է հետաքրքրում Solaris-ի նման էկզոտիկները, ուստի եկեք գնանք:

Linux-ի ժամանակակից բաշխումն ունի ավելի քան 1 syctl տարբերակ՝ կախված նրանից, թե ինչպես եք կառուցում միջուկը: Միևնույն ժամանակ, եթե մենք նայենք տարբեր ընկույզներին, մենք կարող ենք ինչ-որ բան հարմարեցնել շատ առումներով: Կան ֆայլային համակարգի պարամետրեր, թե ինչպես դրանք տեղադրել: Եթե ​​հարցեր ունեք, թե ինչպես սկսել այն՝ ինչ միացնել BIOS-ում, ինչպես կարգավորել սարքաշարը և այլն:

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

Ի՞նչ ավանդական թյունինգ թիրախներ կան Linux-ում: Ես կարծում եմ, որ քանի որ դուք բոլորդ գործ ունեք Linux-ի ադմինիստրացիայի հետ, առանձնակի կարիք չկա բացատրելու, թե ինչ թիրախներ են:

Դուք կարող եք կարգավորել.

• Պրոցեսոր
• Հիշողություն:
• Պահեստավորում:
• Այլ. Այս մասին վերջում կխոսենք խորտիկի համար: Նույնիսկ, օրինակ, այնպիսի պարամետրեր, ինչպիսիք են էներգախնայողության քաղաքականությունը, կարող են ազդել աշխատանքի վրա շատ անկանխատեսելի և ոչ ամենահաճելի ձևով:

Որո՞նք են PostgreSQL-ի և ընդհանրապես տվյալների բազայի առանձնահատկությունները: Խնդիրն այն է, որ դուք չեք կարող կսմթել որևէ առանձին ընկույզ և տեսնել, որ մեր կատարողականությունը զգալիորեն բարելավվել է:

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

Սկզբունքորեն, ինչ-որ չափով իրավիճակը նույնն է PostgreSQL-ի դեպքում: Տարբերությունն այն է, որ տվյալների բազան դեռ ի վիճակի չէ իր համար վերցնել բոլոր ռեսուրսները, այսինքն՝ ինչ-որ տեղ Linux-ի մակարդակով, դուք պետք է ինքներդ կարգավորեք այդ ամենը:

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

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

Սկավառակներն ապրում են այս համակարգի ներքո: Ես նկարեցի սա որպես սկավառակ: Փաստորեն, կարող է լինել RAID վերահսկիչ և այլն:

Եվ այս մուտք-ելքը, այսպես թե այնպես, տեղի է ունենում այս հարցի միջոցով։

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

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

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

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

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

Եվ եկեք անցնենք այս կետերից յուրաքանչյուրի միջով:

Որպեսզի այս էջերն ավելի արագ շարժվեն առաջ և առաջ, դուք պետք է հասնեք հետևյալին.

• Նախ, դուք պետք է ավելի արդյունավետ աշխատեք հիշողության հետ:
• Երկրորդ, այս անցումը, երբ էջերը հիշողությունից անցնում են սկավառակ, պետք է ավելի արդյունավետ լինի:
• Եվ երրորդ, պետք է լավ սկավառակներ լինեն։

Եթե ​​սերվերում ունեք 512 ԳԲ օպերատիվ հիշողություն, և այդ ամենը հայտնվում է SATA կոշտ սկավառակի վրա՝ առանց որևէ քեշի, ապա տվյալների բազայի ամբողջ սերվերը վերածվում է ոչ միայն դդմի, այլև SATA ինտերֆեյսով դդմի։ Դուք ուղղակիորեն կբախվեք դրան: Եվ ոչինչ չի փրկի ձեզ:

Ինչ վերաբերում է հիշողության հետ կապված առաջին կետին, ապա կան երեք բան, որոնք կարող են շատ դժվարացնել կյանքը.

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

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

Ի՞նչ է իրականում կատարվում: NUMA-ն նշանակում է ոչ միասնական հիշողության հասանելիություն: Ի՞նչ իմաստ ունի: Դուք ունեք պրոցեսոր, դրա կողքին կա նրա տեղական հիշողությունը։ Եվ այս հիշողության փոխկապակցումը կարող է հիշողություն քաշել այլ պրոցեսորներից:

Եթե ​​դուք վազում եք numactl --hardware, ապա դուք կստանաք նման մեծ թերթիկ: Ի թիվս այլ բաների, կլինի նաև հեռավորությունների դաշտ։ Կլինեն թվեր՝ 10-20, նման բան։ Այս թվերը ոչ այլ ինչ են, քան հոփերի քանակ՝ այս հեռակառավարվող հիշողությունը վերցնելու և այն տեղական օգտագործման համար: Սկզբունքորեն, լավ գաղափար է: Սա լավ արագացնում է կատարումը մի շարք ծանրաբեռնվածության պայմաններում:

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

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

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

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

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

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

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

Ռոբերտ Հաասի լավ գրառում կա. Սա PostgreSQL կոմիտերներից մեկն է: Ցածր մակարդակի բոլոր գոգնոցների հիմնական մշակողներից մեկը: Եվ եթե հետևեք այս գրառման հղումներին, դրանք նկարագրում են մի քանի գունեղ պատմություններ այն մասին, թե ինչպես է NUMA-ն դժվարացնում կյանքը մարդկանց համար: Նայեք, ուսումնասիրեք համակարգի ադմինիստրատորի ստուգաթերթը, թե ինչ պետք է կարգավորվի սերվերի վրա, որպեսզի մեր տվյալների բազան լավ աշխատի: Այս կարգավորումները պետք է գրվեն և ստուգվեն, քանի որ հակառակ դեպքում դա այնքան էլ լավ չի լինի:

Խնդրում ենք նկատի ունենալ, որ դա վերաբերում է բոլոր կարգավորումներին, որոնց մասին ես կխոսեմ: Բայց սովորաբար տվյալների շտեմարանները հավաքվում են master-slave ռեժիմով՝ սխալների հանդուրժողականության համար: Մի մոռացեք այս կարգավորումները կատարել ստրուկի վրա, քանի որ մի օր դուք վթարի եք ենթարկվելու, և դուք կանցնեք ստրուկին, և նա կդառնա տերը:

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

Հաջորդ կետը հսկայական էջերն են: Հսկայական էջերը դժվար է առանձին փորձարկել, և դա անելն իմաստ չունի, թեև կան չափանիշներ, որոնք կարող են դա անել: Դրանք հեշտ է Google-ի համար:

Ի՞նչ իմաստ ունի: Դուք ունեք ոչ շատ թանկ սերվեր՝ շատ օպերատիվ հիշողությամբ, օրինակ՝ ավելի քան 30 ԳԲ։ Դուք չեք օգտագործում հսկայական էջեր: Սա նշանակում է, որ դուք հաստատ գերբեռնված եք հիշողության օգտագործման առումով: Եվ այս գլխավճարը հեռու է ամենահաճելիից:

Ինչո՞ւ է այդպես։ Այսպիսով, ինչ է կատարվում: Օպերացիոն համակարգը հիշողությունը հատկացնում է փոքր կտորներով: Դա այնքան հարմար է, որ պատմականորեն այդպես է եղել: Իսկ եթե մանրամասնենք, ՕՀ-ն պետք է վիրտուալ հասցեները վերածի ֆիզիկականի: Եվ այս գործընթացը ամենապարզը չէ, ուստի ՕՀ-ն պահում է այս գործողության արդյունքը Translation Lookaside Buffer-ում (TLB):

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

Երկու - որքան շատ է քեշն աճում նման իրավիճակում, այնքան ավելի հավանական է, որ դուք կունենաք քեշի բացթողումներ: Եվ այս քեշի արդյունավետությունը արագորեն նվազում է, քանի որ դրա չափը մեծանում է: Հետեւաբար, օպերացիոն համակարգերը հանդես եկան պարզ մոտեցմամբ. Այն վաղուց օգտագործվել է Linux-ում։ Այն հայտնվել է FreeBSD-ում ոչ այնքան վաղուց: Բայց մենք խոսում ենք Linux-ի մասին: Սրանք հսկայական էջեր են:

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

Եվ ինչպե՞ս կարելի է դա ընկերանալ PostgreSQL-ի հետ: Նախ, հսկայական էջերը պետք է միացված լինեն Linux միջուկում:

Երկրորդ, դրանք պետք է հստակորեն նշվեն sysctl պարամետրով` քանիսն են: Այստեղ թվերը որոշ հին սերվերից են: Դուք կարող եք հաշվարկել, թե քանի ընդհանուր բուֆեր ունեք, որպեսզի հսկայական էջերը տեղավորվեն այնտեղ:

Եվ եթե ձեր ամբողջ սերվերը նվիրված է PostgreSQL-ին, ապա լավ մեկնարկային կետ է RAM-ի կամ 25%-ը հատկացնել ընդհանուր բուֆերներին, կամ 75%-ը, եթե վստահ եք, որ ձեր տվյալների բազան անպայման տեղավորվում է այս 75%-ի մեջ։ Մեկնարկային կետ մեկ. Եվ հաշվի առեք, եթե ունեք 256 ԳԲ օպերատիվ հիշողություն, ապա, համապատասխանաբար, կունենաք 64 ԳԲ մեծ բուֆերներ։ Մոտավորապես հաշվարկեք որոշակի մարժանով. ինչի վրա պետք է սահմանվի այս ցուցանիշը:

Մինչև 9.2 տարբերակը (եթե չեմ սխալվում՝ սկսած 8.2 տարբերակից), հնարավոր էր միացնել PostgreSQL-ը հսկայական էջերի հետ՝ օգտագործելով երրորդ կողմի գրադարանը։ Եվ դա միշտ պետք է արվի: Նախ, ձեզ անհրաժեշտ է միջուկը, որպեսզի կարողանաք ճիշտ տեղաբաշխել հսկայական էջերը: Եվ, երկրորդ, որպեսզի դրանց հետ աշխատող հավելվածը կարողանա օգտագործել դրանք։ Դա հենց այնպես չի օգտագործվի: Քանի որ PostgreSQL-ը հիշողություն է հատկացրել համակարգի 5 ոճով, դա կարելի է անել՝ օգտագործելով libhugetlbfs. սա գրադարանի ամբողջական անվանումն է:

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

Բայց համայնքը ուշադրություն դարձրեց այս խնդրին և 9.4-ում նրանք շատ լավ վերամշակեցին այս իրադարձությունը։ Իսկ 9.4-ում postgresql.conf-ում հայտնվեց մի պարամետր, որում կարող եք միացնել փորձել, միացնել կամ անջատել:

Փորձելն ամենաանվտանգ տարբերակն է: Երբ PostgreSQL-ը սկսվում է, երբ այն հատկացնում է ընդհանուր հիշողությունը, այն փորձում է գրավել այս հիշողությունը հսկայական էջերից: Եվ եթե այն չի աշխատում, ապա այն վերադառնում է սովորական ընտրության: Եվ եթե ունեք FreeBSD կամ Solaris, ապա կարող եք փորձել, դա միշտ ապահով է:

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

Եվս մեկ փոքրիկ նշում, նախքան հետագա գնալը: Թափանցիկ հսկայական էջերը դեռ PostgreSQL-ի մասին չեն: Նա չի կարող դրանք նորմալ օգտագործել։ Եվ նման ծանրաբեռնվածության համար թափանցիկ հսկայական էջերի դեպքում, երբ անհրաժեշտ է ընդհանուր հիշողության մեծ կտոր, օգուտները գալիս են միայն շատ մեծ ծավալներով: Եթե ​​դուք ունեք տերաբայթ հիշողություն, ապա դա կարող է ի հայտ գալ: Եթե ​​մենք խոսում ենք ավելի շատ ամենօրյա հավելվածների մասին, երբ ձեր սարքում ունեք 32, 64, 128, 256 ԳԲ հիշողություն, ապա սովորական հսկայական էջերը Ok են, և մենք պարզապես անջատում ենք Transparent-ը:

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

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

Ինչ է կատարվում? Այնտեղ մեծ քանակությամբ RAM ունեք, ամեն ինչ լավ է աշխատում։ Բայց ինչ-ինչ պատճառներով սերվերը կախված է փոխանակման ժամանակ և դրա պատճառով դանդաղում է: Թվում է, թե հիշողությունը շատ է, բայց դա տեղի է ունենում:

Նախկինում մենք խորհուրդ էինք տալիս զրոյի դնել vm.swappiness-ը, այսինքն՝ անջատել փոխանակումը: Նախկինում թվում էր, թե 32 ԳԲ օպերատիվ հիշողությունը և համապատասխան ընդհանուր բուֆերները հսկայական քանակություն են: Փոխանակման հիմնական նպատակն այն է, որ մենք ընկնենք ընդերքը գցելու տեղ: Եվ դա այլեւս առանձնապես չի կատարվել։ Եվ հետո ի՞նչ եք պատրաստվում անել այս կեղևի հետ: Սա մի խնդիր է, որտեղ այնքան էլ պարզ չէ, թե ինչու է անհրաժեշտ փոխանակումը, հատկապես նման չափի:

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

Հետևաբար, այժմ լռելյայն, որքան ես հիշում եմ, բաշխումների մեծ մասը գտնվում է մոտ 6-ի սահմաններում, այսինքն, թե որ կետից պետք է սկսեք օգտագործել swap՝ կախված նրանից, թե որքան հիշողություն է մնացել: Այժմ մենք խորհուրդ ենք տալիս սահմանել vm.swappiness = 1, քանի որ դա գործնականում անջատում է այն, բայց չի տալիս նույն ազդեցությունները, ինչ OOM-մարդասպանի դեպքում, որն անսպասելիորեն եկավ և սպանեց ամբողջը:

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

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

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

Ահա ես ունեմ երկու նկար. Հիմա ես կբացատրեմ, թե ինչ է դա: Սրանք երկու ժամանակի փոխկապակցված գրաֆիկներ են: Առաջին գրաֆիկը սկավառակի օգտագործումն է: Այստեղ այն հասնում է գրեթե 90%-ի այս պահին: Եթե ​​դուք ունեք տվյալների բազայի ձախողում ֆիզիկական սկավառակների հետ, RAID վերահսկիչի օգտագործումը 90%, ապա սա վատ նորություն է: Սա նշանակում է, որ մի փոքր ավելին, և այն կհասնի 100-ի, և I/O-ն կդադարի:

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

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

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

Եթե ​​նայեք Linux-ի տեսանկյունից, եթե լավ սարքավորում եք վերցրել, ճիշտ եք կարգավորել, նորմալ կարգավորել PostgreSQL-ը, որպեսզի այս անցակետերը ավելի քիչ հաճախակի դարձնի, ժամանակի ընթացքում դրանք տարածի միմյանց միջև, ապա դուք մուտք եք գործում Debian-ի լռելյայն պարամետրերի մեջ։ Linux բաշխումների մեծ մասի համար սա պատկերն է՝ vm.dirty_ratio=20, vm.dirty_background_ratio=10:

Ինչ է դա նշանակում? Մեկ ողողող դև հայտնվեց միջուկից 2.6: Pdglush, կախված նրանից, թե ով է օգտագործում, որը զբաղվում է միջուկի բուֆերից կեղտոտ էջերի ֆոնային հեռացմամբ և հեռացնելով, երբ անհրաժեշտ է հեռացնել կեղտոտ էջերը, անկախ ամեն ինչից, երբ հետին պլանի հեռացումը չի օգնում:

Ե՞րբ է գալիս ֆոնը: Երբ սերվերում առկա ընդհանուր RAM-ի 10%-ը զբաղեցնում է միջուկի բուֆերի կեղտոտ էջերը, հետին պլանում կանչվում է հատուկ դուրսգրման ֆունկցիա: Ինչու՞ է դա ֆոն: Որպես պարամետր՝ հաշվի է առնվում, թե քանի էջ պետք է դուրս գրել։ Եվ, ասենք, նա դուրս է գրում N էջ։ Եվ այս բանը որոշ ժամանակ քնում է: Եվ հետո նա նորից գալիս է և պատճենում է ևս մի քանի էջ:

Սա չափազանց պարզ պատմություն է։ Այստեղ խնդիրը նման է լողավազանի, երբ այն լցվում է մի խողովակի մեջ, այն հոսում է մյուսի մեջ։ Մեր անցակետը եկավ, և եթե այն ուղարկեց մի քանի կեղտոտ էջեր դեն նետելու համար, ապա աստիճանաբար ամբողջ գործը կլուծվի միջուկի բուֆերային pgflush-ից:

Եթե ​​այս կեղտոտ էջերը շարունակեն կուտակվել, ապա դրանք կուտակվում են մինչև 20%, որից հետո ՕՀ-ի առաջնահերթությունը ամբողջը սկավառակի վրա դուրս գրելն է, քանի որ հոսանքը կփչանա, և մեզ համար ամեն ինչ վատ կլինի։ Մենք կկորցնենք այս տվյալները, օրինակ.

Ո՞րն է հնարքը: Խաբեությունն այն է, որ ժամանակակից աշխարհում այս պարամետրերը կազմում են մեքենայի վրա եղած ընդհանուր RAM-ի 20-ը և 10%-ը, դրանք բացարձակապես հրեշավոր են ցանկացած սկավառակային համակարգի թողունակության առումով, որը դուք ունեք:

Պատկերացրեք, որ ունեք 128 ԳԲ RAM: 12,8 ԳԲ-ը հասնում է ձեր սկավառակի համակարգին: Եվ անկախ նրանից, թե ինչ քեշ ունեք այնտեղ, անկախ նրանից, թե ինչ զանգված ունեք այնտեղ, դրանք այդքան երկար չեն տևի:

Հետևաբար, խորհուրդ ենք տալիս անմիջապես կարգավորել այս թվերը՝ ելնելով ձեր RAID կարգավորիչի հնարավորություններից: Ես անմիջապես առաջարկություն արեցի այստեղ վերահսկիչի համար, որն ունի 512 ՄԲ քեշ:

Ամեն ինչ համարվում է շատ պարզ. Դուք կարող եք տեղադրել vm.dirty_background բայթերով: Եվ այս կարգավորումները չեղյալ են հայտարարում նախորդ երկուսը: Կամ հարաբերակցությունը լռելյայն է, կամ բայթ ունեցողներն ակտիվացված են, ապա բայթ ունեցողները կաշխատեն: Բայց քանի որ ես DBA-ի խորհրդատու եմ և աշխատում եմ տարբեր հաճախորդների հետ, փորձում եմ ծղոտներ նկարել և հետևաբար, եթե բայթերով, ապա բայթերով: Ոչ ոք երաշխիք չտվեց, որ լավ ադմինը չի ավելացնի ավելի շատ հիշողություն սերվերին, չի վերաբեռնի այն, և ցուցանիշը կմնա նույնը: Պարզապես հաշվարկեք այս թվերը, որպեսզի ամեն ինչ տեղավորվի այնտեղ երաշխիքով:

Ինչ է տեղի ունենում, եթե դուք չեք տեղավորվում: Ես գրել եմ, որ ցանկացած ողողում փաստացի դադարեցվում է, բայց իրականում սա խոսքի պատկեր է։ Օպերացիոն համակարգը մեծ խնդիր ունի՝ այն ունի շատ կեղտոտ էջեր, ուստի IO-ն, որը ստեղծում են ձեր հաճախորդները, արդյունավետորեն դադարեցված է, այսինքն՝ հավելվածը եկել է sql հարցում ուղարկելու տվյալների բազա, այն սպասում է։ Դրա ցանկացած մուտք/ելք ամենացածր առաջնահերթությունն է, քանի որ տվյալների բազան զբաղված է անցակետով: Իսկ թե երբ կավարտի, լրիվ անհասկանալի է։ Եվ երբ դուք հասել եք ոչ ֆոնային լվացման, դա նշանակում է, որ ձեր ամբողջ IO-ն զբաղված է դրանով: Եվ քանի դեռ այն չի ավարտվել, դուք ոչինչ չեք անի:

Այստեղ կա ևս երկու կարևոր կետ, որոնք դուրս են այս զեկույցի շրջանակներից: Այս կարգավորումները պետք է համապատասխանեն postgresql.conf-ի կարգավորումներին, այսինքն՝ անցակետերի կարգավորումներին: Եվ ձեր սկավառակի համակարգը պետք է պատշաճ կերպով կազմաձևված լինի: Եթե ​​դուք ունեք RAID-ի քեշ, ապա այն պետք է ունենա մարտկոց: Մարդիկ գնում են RAID լավ քեշով առանց մարտկոցի: Եթե ​​դուք ունեք SSD-ներ RAID-ում, ապա դրանք պետք է լինեն սերվերային, այնտեղ պետք է լինեն կոնդենսատորներ: Ահա մանրամասն ստուգաթերթ: Այս հղումը պարունակում է իմ զեկույցն այն մասին, թե ինչպես կարելի է կարգավորել կատարողական սկավառակը PostgreSQL-ում: Այնտեղ կան այս բոլոր ստուգաթերթերը։

Էլ ի՞նչը կարող է կյանքը շատ դժվարացնել: Սրանք երկու պարամետր են։ Դրանք համեմատաբար նոր են։ Լռելյայնորեն դրանք կարող են ներառվել տարբեր հավելվածներում: Եվ նրանք կարող են նույնքան դժվարացնել կյանքը, եթե դրանք սխալ միացվեն:

Երկու համեմատաբար նոր բան կա. Նրանք արդեն հայտնվել են երրորդ միջուկներում։ Սա sched_migration_cost է նանվայրկյաններով և sched_autogroup_enabled, որը լռելյայն մեկն է:

Իսկ ինչպե՞ս են նրանք կործանում ձեր կյանքը։ Ի՞նչ է sched_migration_cost-ը: Linux-ում ժամանակացույցը կարող է գործընթաց տեղափոխել մեկ պրոցեսորից մյուսը: Իսկ PostgreSQL-ի համար, որը հարցումներ է կատարում, այլ պրոցեսոր տեղափոխելը լիովին անհասկանալի է: Օպերացիոն համակարգի տեսանկյունից, երբ պատուհանները փոխում եք openoffice-ի և տերմինալի միջև, դա կարող է լավ լինել, բայց տվյալների բազայի համար սա շատ վատ է: Հետևաբար, ողջամիտ քաղաքականություն է migration_cost-ը որոշ մեծ արժեք սահմանել, առնվազն մի քանի հազար նանվայրկյան:

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

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

Իմ գործընկեր Ալեքսեյ Լեսովսկին պարզ pgbench-ով թեստեր արեց, որտեղ մեծության կարգով ավելացրեց migration_cost-ը և անջատեց ավտոխումբը։ Վատ սարքավորումների տարբերությունը գրեթե 10% էր. Postgres փոստային ցուցակում քննարկում կա, որտեղ մարդիկ տալիս են հարցումների արագության նմանատիպ փոփոխությունների արդյունքներ ազդել է 50%. Նման պատմությունները բավականին շատ են։

Եվ վերջապես՝ էներգախնայողության քաղաքականության մասին։ Լավն այն է, որ այժմ Linux-ը կարող է օգտագործվել նոութբուքի վրա: Եվ դա իբր լավ կծախսի մարտկոցը։ Բայց հանկարծ պարզվում է, որ դա կարող է տեղի ունենալ նաև սերվերի վրա։

Ավելին, եթե դուք սերվերներ եք վարձակալում ինչ-որ հոսթերից, ապա «լավ» հոսթերներին չի հետաքրքրում, որ դուք ավելի լավ կատարողականություն ունեք։ Նրանց խնդիրն է ապահովել, որ իրենց երկաթը հնարավորինս արդյունավետ օգտագործվի: Հետևաբար, լռելյայն նրանք կարող են միացնել նոութբուքի էներգիայի խնայողության ռեժիմը օպերացիոն համակարգում:

Եթե ​​դուք օգտագործում եք այս նյութը մեծ բեռի տակ գտնվող տվյալների բազա ունեցող սերվերի վրա, ապա ձեր ընտրությունը acpi_cpufreq + permormance է: Անգամ ցանկության դեպքում խնդիրներ կլինեն։

Intel_pstate-ը մի փոքր այլ դրայվեր է: Եվ հիմա նախապատվությունը տրվում է այս մեկին, քանի որ այն ավելի ուշ է և ավելի լավ է աշխատում։

Եվ, համապատասխանաբար, մարզպետը միայն կատարում է։ Ondemand-ը, powersave-ը և մնացած ամեն ինչ ձեր մասին չեն:

PostgreSQL-ի բացատրական վերլուծության արդյունքները կարող են տարբերվել մի քանի կարգով, եթե դուք միացնեք powersave-ը, քանի որ ձեր տվյալների բազայի տակ գտնվող պրոցեսորը գործնականում կաշխատի բոլորովին անկանխատեսելի կերպով:

Այս տարրերը կարող են ներառվել լռելյայն: Ուշադիր նայեք՝ տեսնելու համար, թե արդյոք նրանք լռելյայն միացրել են: Սա կարող է իսկապես մեծ խնդիր լինել:

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

Հարցեր.

Շնորհակալություն! Եթե, օրինակ, ընկերությունը ցանկանում է գումար խնայել և տվյալների բազան և հավելվածի տրամաբանությունը տեղադրել մեկ սերվերի վրա, կամ եթե ընկերությունը հետևում է միկրոսերվիսային ճարտարապետության նորաձև միտումին, որտեղ PostgreSQL-ն աշխատում է կոնտեյներով: Ո՞րն է հնարքը: Sysctl-ը կազդի ամբողջ միջուկի վրա ամբողջ աշխարհում: Ես չեմ լսել, որ sysctls-ը ինչ-որ կերպ վիրտուալացվել է, որպեսզի նրանք առանձին աշխատեն կոնտեյների վրա: Կա միայն cgroup, և այնտեղ կա միայն վերահսկողության մի մասը: Ինչպե՞ս կարող ես ապրել սրա հետ: Կամ եթե ուզում եք կատարում, ապա գործարկեք PostgreSQL-ն առանձին ապարատային սերվերի վրա և կարգավորեք այն:

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

Ինչումն է խնդիրը? Եթե ​​սա վիրտուալ մեքենա է, ապա, ամենայն հավանականությամբ, դուք կունենաք բազմաթիվ խնդիրներ, օրինակ, այն փաստի հետ, որ վիրտուալ մեքենաների մեծ մասում սկավառակի հետաձգումը բավականին անհամապատասխան է: Նույնիսկ եթե սկավառակի թողունակությունը լավ է, ապա մեկ ձախողված I/O գործարք, որը մեծապես չի ազդում միջին թողունակության վրա, որը տեղի է ունեցել անցակետի պահին կամ WAL-ին գրելու պահին, ապա տվյալների բազան մեծապես կտուժի դրանից: Եվ դուք դա կնկատեք նախքան այս խնդիրների հետ հանդիպելը:

Եթե ​​դուք ունեք NGINX նույն սերվերի վրա, դուք նույնպես կունենաք նույն խնդիրը: Նա կպայքարի ընդհանուր հիշողության համար։ Եվ դուք չեք հասնի այստեղ նկարագրված խնդիրներին:

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

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

Ես հարց ունեմ Amazon AWS-ի հետ կապված. Նրանք ունեն պատկերներ նախապես կազմաձևված: Դրանցից մեկը կոչվում է Amazon RDS: Կա՞ն հատուկ կարգավորումներ նրանց օպերացիոն համակարգի համար:

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

Ինչու՞ Թափանցիկ հսկայական էջերը ազդեցություն չունեն հսկայական TLB-ի համեմատ:

Մի տվեք. Սա կարելի է բացատրել բազմաթիվ ձևերով: Բայց իրականում նրանք դա պարզապես չեն տալիս: Ո՞րն է PostgreSQL-ի պատմությունը: Գործարկման ժամանակ այն հատկացնում է ընդհանուր հիշողության մեծ մասը: Թափանցիկ են դրանք, թե ոչ, լրիվ անտեղի է։ Այն, որ նրանք աչքի են ընկնում սկզբում, ամեն ինչ բացատրում է։ Իսկ եթե հիշողությունը շատ է, և դուք պետք է վերակառուցեք shared_memory հատվածը, ապա Թափանցիկ հսկայական էջերը համապատասխան կլինեն։ PostgreSQL-ում այն ​​պարզապես սկզբում հատկացվում է հսկայական հատվածով և վերջ, և հետո այնտեղ առանձնահատուկ բան տեղի չի ունենում: Դուք, իհարկե, կարող եք օգտագործել այն, բայց կա shared_memory-ի կոռուպցիայի հավանականություն, երբ այն վերաբաշխում է ինչ-որ բան: PostgreSQL-ը չգիտի այս մասին:

Source: www.habr.com