Բարձր կատարողականություն և բնիկ բաժանում. Zabbix TimescaleDB աջակցությամբ

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

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

Zabbix-ում հավաքագրման և պահպանման ժամանակ ձգձգումների խնդիրները լուծվում են քեշավորման միջոցով՝ մի քանի տեսակի քեշ, տվյալների բազայում քեշավորում։ Երրորդ խնդիրը լուծելու համար քեշավորումը հարմար չէ, ուստի Zabbix-ն օգտագործեց TimescaleDB: Նա ձեզ կպատմի այդ մասին Անդրեյ Գուշչին - տեխնիկական աջակցության ինժեներ Zabbix SIA. Անդրեյը աջակցում է Zabbix-ին ավելի քան 6 տարի և ունի կատարման անմիջական փորձ:

Ինչպե՞ս է աշխատում TimescaleDB-ն, ի՞նչ արդյունավետություն կարող է տալ այն սովորական PostgreSQL-ի համեմատ: Ի՞նչ դեր է խաղում Zabbix-ը TimescaleDB տվյալների բազայի համար: Ինչպե՞ս սկսել զրոյից և ինչպես գաղթել PostgreSQL-ից և ո՞ր կոնֆիգուրացիան ունի ավելի լավ կատարում: Այս ամենի մասին կտրվածքի տակ։

Արտադրողականության մարտահրավերներ

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

Տվյալների արագ հավաքում և մշակում: Լավ մոնիտորինգի համակարգը պետք է արագ ստանա բոլոր տվյալները և մշակի դրանք ըստ ձգանման արտահայտությունների՝ ըստ իր չափանիշների: Մշակելուց հետո համակարգը նույնպես պետք է արագ պահի այս տվյալները տվյալների բազայում՝ հետագա օգտագործման համար:

Պատմության պահպանում. Լավ մոնիտորինգի համակարգը պետք է պահպանի պատմությունը տվյալների բազայում և ապահովի հեշտ մուտք դեպի չափումներ: Պատմությունը անհրաժեշտ է, որպեսզի օգտագործվի հաշվետվություններում, գծապատկերներում, գործարկիչներում, շեմերի և զգուշացման տվյալների հաշվարկված տարրերում:

Պատմության մաքրում: Երբեմն գալիս է մի օր, երբ դուք կարիք չեք ունենա պահպանել չափումները: Ինչու՞ են ձեզ անհրաժեշտ տվյալները, որոնք հավաքվել են 5 տարի առաջ, մեկ-երկու ամիս. որոշ հանգույցներ ջնջվել են, որոշ հոսթինգներ կամ չափումներ այլևս անհրաժեշտ չեն, քանի որ դրանք հնացած են և այլևս չեն հավաքվում: Լավ մոնիտորինգի համակարգը պետք է պահպանի պատմական տվյալները և ժամանակ առ ժամանակ ջնջի դրանք, որպեսզի տվյալների բազան չմեծանա:

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

Քեշավորում Zabbix-ում

Zabbix-ում առաջին և երկրորդ զանգերը լուծվում են քեշավորման միջոցով: RAM-ն օգտագործվում է տվյալների հավաքագրման և մշակման համար: Պահպանման համար - պատմություն գործարկիչներում, գրաֆիկներում և տվյալների հաշվարկված տարրերում: Տվյալների բազայի կողմում կա որոշ քեշավորում հիմնական ընտրանքների համար, օրինակ՝ գրաֆիկները:

Ինքնին Zabbix սերվերի կողմից քեշավորումը հետևյալն է.

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Մտածեք նրանց մանրամասն:

ConfigurationCache

Սա հիմնական քեշն է, որտեղ մենք պահում ենք չափումներ, հոսթինգներ, տվյալների տարրեր, գործարկիչներ՝ այն ամենը, ինչ մեզ անհրաժեշտ է PreProcessing-ի և տվյալների հավաքագրման համար:

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

Տվյալների հավաքագրումը

Դիագրամը բավականին մեծ է, բայց դրա մեջ գլխավորն այն է հավաքողներ. Սրանք տարբեր «փոշեկուլներ» են՝ հավաքման գործընթացներ: Նրանք պատասխանատու են հավաքման տարբեր տեսակների համար. նրանք հավաքում են տվյալներ SNMP-ի, IPMI-ի միջոցով և այդ ամենը փոխանցում PreProcessing-ին:

Կոլեկտորները ուրվագծված են նարնջագույնով։

Zabbix-ը հաշվարկել է ագրեգացիոն տարրեր, որոնք անհրաժեշտ են չեկերը համախմբելու համար: Եթե ​​մենք ունենք դրանք, մենք նրանց համար տվյալները վերցնում ենք անմիջապես ValueCache-ից:

PreProcessing HistoryCache

Բոլոր կոլեկցիոներներն օգտագործում են ConfigurationCache՝ աշխատանք ստանալու համար: Հետո դրանք տեղափոխում են PreProcessing։

PreProcessing-ը օգտագործում է ConfigurationCache-ը՝ PreProcessing քայլերը ստանալու համար: Այն մշակում է այս տվյալները տարբեր ձևերով:

Տվյալները PreProcessing-ի միջոցով մշակելուց հետո մենք այն պահում ենք HistoryCache-ում՝ մշակման համար: Սա ավարտում է տվյալների հավաքագրումը, և մենք անցնում ենք Zabbix-ի հիմնական գործընթացին. պատմության համաժամեցում, քանի որ այն մոնոլիտ ճարտարապետություն է։

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

ValueCache, պատմություն և միտումների քեշ

Պատմության համաժամեցումը հիմնական գործընթացն է, որն ատոմային կերպով մշակում է տվյալների յուրաքանչյուր տարր, այսինքն՝ յուրաքանչյուր արժեք:

Պատմության համաժամեցումը արժեքներ է վերցնում HistoryCache-ից և ստուգում է կոնֆիգուրացիան՝ հաշվարկների համար գործարկիչների առկայության համար: Եթե ​​կան, ապա հաշվարկում է։

Պատմության համաժամեցումը ստեղծում է իրադարձություն, էսկալացիա՝ ծանուցումներ ստեղծելու համար, եթե պահանջվում է կոնֆիգուրացիայից և գրառումներ: Եթե ​​կան գործարկիչներ հետագա մշակման համար, ապա այն պահում է այս արժեքը ValueCache-ում, որպեսզի մուտք չգործի պատմության աղյուսակ: Ահա թե ինչպես է ValueCache-ը լցված տվյալների հետ, որոնք անհրաժեշտ են գործարկիչները և հաշվարկված տարրերը հաշվարկելու համար:

Պատմության համաժամեցումը գրում է բոլոր տվյալները տվյալների բազայում, և այն գրում է սկավառակի վրա: Մշակման գործընթացը ավարտվում է այստեղ:

Քեշավորում տվյալների բազայում

Տվյալների բազայի կողմում կան տարբեր քեշեր, երբ ցանկանում եք դիտել գծապատկերներ կամ հաշվետվություններ իրադարձությունների վերաբերյալ.

• Innodb_buffer_pool MySQL կողմում;
• shared_buffers PostgreSQL կողմում;
• effective_cache_size Oracle-ի կողմից;
• shared_pool DB2 կողմում:

Կան բազմաթիվ այլ քեշեր, բայց դրանք հիմնականներն են բոլոր տվյալների բազաների համար: Նրանք թույլ են տալիս պահպանել տվյալներ RAM-ում, որոնք հաճախ անհրաժեշտ են հարցումների համար: Նրանք ունեն իրենց սեփական տեխնոլոգիաները դրա համար:

Տվյալների բազայի կատարումը կարևոր է

Zabbix սերվերն անընդհատ տվյալներ է հավաքում և գրում: Երբ վերագործարկվում է, այն նաև կարդում է պատմությունից ValueCache-ը լրացնելու համար: Օգտագործում է սցենարներ և հաշվետվություններ Zabbix API, որը կառուցված է վեբ ինտերֆեյսի վրա: Zabbix API-ն մուտք է գործում տվյալների բազա և առբերում է անհրաժեշտ տվյալները գրաֆիկների, հաշվետվությունների, իրադարձությունների ցուցակների և վերջին խնդիրների համար:

Վիզուալիզացիայի համար - Գրաֆանա. Սա մեր օգտատերերի շրջանում տարածված լուծում է: Այն կարող է ուղղակիորեն հարցումներ ուղարկել Zabbix API-ի և տվյալների բազայի միջոցով և ստեղծել որոշակի մրցակցություն տվյալների ստացման համար: Հետևաբար, տվյալների բազայի ավելի նուրբ և ավելի լավ կարգավորում է անհրաժեշտ՝ արդյունքների արագ առաքմանը և թեստավորմանը համապատասխանելու համար:

Տնտեսուհի

Zabbix-ում կատարողականի երրորդ մարտահրավերը պատմության մաքրումն է Housekeeper-ի միջոցով: Այն հետևում է բոլոր պարամետրերին. տվյալների տարրերը ցույց են տալիս, թե որքան ժամանակ է պետք պահել փոփոխությունների (տենդենցների) դինամիկան օրերով:

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

Տնային տնտեսուհին սկսում և ջնջում է տեղեկատվությունը տվյալների բազայից՝ օգտագործելով սովորական «ընտրությունները»: Սա միշտ չէ, որ արդյունավետ է, ինչպես երևում է ներքին գործընթացների կատարողական գրաֆիկներից:

Կարմիր գրաֆիկը ցույց է տալիս, որ History syncer-ը մշտապես զբաղված է: Վերևում գտնվող նարնջագույն գրաֆիկը Housekeeper-ն է, որն անընդհատ աշխատում է: Նա սպասում է, որ տվյալների բազան ջնջի իր նշած բոլոր տողերը:

Ե՞րբ պետք է անջատել Housekeeper-ը: Օրինակ, կա «Item ID» և դուք պետք է ջնջեք վերջին 5 հազար տողերը որոշակի ժամկետում: Իհարկե, դա տեղի է ունենում ինդեքսով։ Բայց սովորաբար տվյալների բազան շատ մեծ է, և տվյալների բազան դեռ կարդում է սկավառակից և տեղադրում այն ​​քեշի մեջ: Սա միշտ շատ թանկ գործողություն է տվյալների բազայի համար և, կախված տվյալների բազայի չափից, կարող է հանգեցնել կատարողականի խնդիրների:

Տնային տնտեսուհին հեշտ է անջատել: Վեբ ինտերֆեյսում կա «Ադմինիստրացիա ընդհանուր» պարամետր Տնային տնտեսավարի համար: Մենք անջատում ենք ներքին Housekeeping-ը ներքին միտումների պատմության համար, և այն այլևս չի կառավարում այն:

Տնային տնտեսուհին անջատված էր, գրաֆիկները հավասարեցվեցին. ի՞նչ խնդիրներ կարող են լինել այս դեպքում և ի՞նչը կարող է օգնել լուծելու կատարողականի երրորդ մարտահրավերը:

Partitioning - բաժանում կամ բաժանում

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

Սովորաբար, միջնորմները կազմաձևվում են կախված «կարգավորումից»՝ մեկ օրվա ընթացքում ստեղծված տվյալների քանակից: Որպես կանոն, բաժանումը տրվում է մեկ օրում, սա նվազագույնն է։ Նոր խմբաքանակի միտումների համար՝ 1 ամիս:

Արժեքները կարող են փոխվել, եթե «կարգավորումը» շատ մեծ է: Եթե ​​փոքր «կարգավորումը» մինչև 5 nvps է (նոր արժեքներ վայրկյանում), միջինը՝ 000-ից մինչև 5, ապա մեծը 000 nvps-ից բարձր է: Սրանք մեծ և շատ մեծ տեղակայանքներ են, որոնք պահանջում են տվյալների բազայի մանրակրկիտ կազմաձևում:

Շատ մեծ տեղակայանքների դեպքում մեկ օրվա ժամկետը չի կարող օպտիմալ լինել: Ես տեսել եմ օրական 40 ԳԲ կամ ավելի MySQL բաժիններ: Սա շատ մեծ քանակությամբ տվյալներ է, որոնք կարող են խնդիրներ առաջացնել և պետք է կրճատվեն:

Ի՞նչ է տալիս բաժանումը:

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

Արագ հեռացում - DELETE. Ընտրված է մեկ ֆայլ/ենթաաղյուսակ, այլ ոչ թե ջնջման համար նախատեսված տողերի ընտրություն:

Զգալիորեն արագացնում է տվյալների որոնումը SELECT - օգտագործում է մեկ կամ մի քանի միջնորմ, այլ ոչ թե ամբողջ աղյուսակը: Եթե ​​մուտք եք գործում երկու օրվա վաղեմություն ունեցող տվյալներ, դրանք ավելի արագ են վերցվում տվյալների բազայից, քանի որ ձեզ հարկավոր է միայն մեկ ֆայլ բեռնել քեշի մեջ և վերադարձնել այն, այլ ոչ թե մեծ աղյուսակ:

Հաճախ շատ տվյալների բազաներ նույնպես արագացված են INSERT - ներդիրներ մանկական սեղանի մեջ:

TimescaleDB

v 4.2-ի համար մենք մեր ուշադրությունը դարձրինք TimescaleDB-ին: Սա PostgreSQL-ի ընդլայնումն է՝ բնիկ ինտերֆեյսով: Ընդլայնումը արդյունավետ աշխատում է ժամանակային շարքերի տվյալների հետ՝ չկորցնելով հարաբերական տվյալների բազաների առավելությունները: TimescaleDB-ը նաև ինքնաբերաբար բաժանվում է:

TimescaleDB-ն ունի հայեցակարգ հիպերսեղան (hypertable), որը դուք ստեղծում եք: Այն պարունակում է կտորներ - միջնորմներ. Հատվածները ավտոմատ կերպով կառավարվում են հիպերսեղանի բեկորներ, որոնք չեն ազդում այլ բեկորների վրա: Յուրաքանչյուր կտոր ունի իր ժամանակային տիրույթը:

TimescaleDB ընդդեմ PostgreSQL

TimescaleDB-ն իսկապես արդյունավետ է աշխատում: Ընդլայնման արտադրողները պնդում են, որ իրենք օգտագործում են հարցումների մշակման ավելի ճիշտ ալգորիթմ, մասնավորապես inserts : Քանի որ տվյալների բազայի ներդիրի չափը մեծանում է, ալգորիթմը պահպանում է մշտական ​​կատարումը:

200 միլիոն տողից հետո PostgreSQL-ը սովորաբար սկսում է զգալիորեն թուլանալ և կորցնում է կատարումը մինչև 0: TimescaleDB-ն թույլ է տալիս արդյունավետ կերպով տեղադրել «ներդիրներ» ցանկացած քանակությամբ տվյալների համար:

Տեղակայում

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

Zabbix տվյալների բազայի համար մենք պարզապես ակտիվացնում ենք ընդլայնումը.

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Դուք ակտիվացնում եք extension և ստեղծեք այն Zabbix տվյալների բազայի համար: Վերջին քայլը հիպերսեղանի ստեղծումն է:

Պատմության աղյուսակների տեղափոխում TimescaleDB

Դրա համար կա հատուկ գործառույթ create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

Ֆունկցիան ունի երեք պարամետր. Առաջին - աղյուսակը տվյալների բազայում, որի համար պետք է ստեղծել հիպերաղյուսակ։ Երկրորդ - դաշտը, ըստ որի պետք է ստեղծել chunk_time_interval - օգտագործվող միջնորմների կտորների միջակայքը: Իմ դեպքում ինտերվալը մեկ օր է՝ 86։

Երրորդ պարամետր - migrate_data. Եթե ​​դուք սահմանել true, ապա բոլոր ընթացիկ տվյալները փոխանցվում են նախապես ստեղծված կտորներին: Ես ինքս օգտագործել եմ այն migrate_data. Ես ունեի մոտ 1 ՏԲ, որը տևեց ավելի քան մեկ ժամ: Նույնիսկ որոշ դեպքերում, թեստավորման ժամանակ, ես ջնջել եմ նիշերի տեսակների պատմական տվյալները, որոնք չեն պահանջվում պահեստավորման համար, որպեսզի չփոխանցեմ դրանք:

Վերջին քայլը - UPDATE: ներ db_extension դնել timescaledbորպեսզի տվյալների բազան հասկանա, որ այս ընդլայնումը գոյություն ունի: Zabbix-ն ակտիվացնում է այն և ճիշտ օգտագործում տվյալների բազայի շարահյուսությունն ու հարցումները՝ այն հնարավորությունները, որոնք անհրաժեշտ են TimescaleDB-ի համար:

Սարքավորման կոնֆիգուրացիա

Ես օգտագործել եմ երկու սերվեր: Առաջին - VMware մեքենա. Այն բավականին փոքր է՝ 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 ԳՀց պրոցեսոր, 16 ԳԲ օպերատիվ հիշողություն և 200 ԳԲ SSD:

Ես դրա վրա տեղադրեցի PostgreSQL 10.8-ը Debian 10.8-1.pgdg90+1 ՕՀ-ով և xfs ֆայլային համակարգով: Ես ամեն ինչ կարգավորեցի նվազագույն չափով՝ այս կոնկրետ տվյալների բազան օգտագործելու համար, մինուս այն, ինչ կօգտագործի ինքը Zabbix-ը:

Նույն մեքենայի վրա կար Zabbix սերվեր, PostgreSQL և բեռնման գործակալներ. Ես ունեի 50 ակտիվ նյութեր, որոնք օգտագործում էին LoadableModuleշատ արագ տարբեր արդյունքներ առաջացնելու համար՝ թվեր, տողեր: Ես լցրեցի տվյալների բազան շատ տվյալների հետ:

Սկզբում կոնֆիգուրացիան պարունակում էր 5 տարր տվյալներ մեկ հյուրընկալողի համար: Գրեթե յուրաքանչյուր տարր պարունակում էր ձգան, որը նմանեցնում էր իրական տեղադրմանը: Որոշ դեպքերում եղել են մեկից ավելի ձգան: Մեկ ցանցային հանգույցի համար կային 3-000 ձգան.

Տվյալների նյութի թարմացման ընդմիջում − 4-7 վայրկյան. Ես կարգավորեցի բեռը ինքնին, օգտագործելով ոչ միայն 50 գործակալներ, այլ ավելացնելով ավելին: Բացի այդ, օգտագործելով տվյալների տարրերը, ես դինամիկ կերպով կարգավորեցի բեռը և կրճատեցի թարմացման միջակայքը մինչև 4 վ:

PostgreSQL. 35 nvps

Այս սարքաշարի վրա իմ առաջին գործարկումը եղել է մաքուր PostgreSQL - 35 հազար արժեք վայրկյանում: Ինչպես տեսնում եք, տվյալների տեղադրումը վայրկյանի կոտորակներ է պահանջում՝ ամեն ինչ լավ է և արագ: Միակ բանն այն է, որ 200 ԳԲ SSD սկավառակը արագ լցվում է:

Սա Zabbix սերվերի աշխատանքի ստանդարտ վահանակ է:

Առաջին կապույտ գրաֆիկը վայրկյանում արժեքների քանակն է: Աջ կողմում գտնվող երկրորդ գրաֆիկը կառուցման գործընթացների բեռնումն է: Երրորդը բեռնում է ներքին կառուցման գործընթացները՝ պատմության համաժամեցման սարքերը և Housekeeper-ը, որն այստեղ գործում է բավականին երկար ժամանակ:

Չորրորդ գրաֆիկը ցույց է տալիս HistoryCache-ի օգտագործումը: Սա մի տեսակ բուֆեր է տվյալների բազայում ներդնելուց առաջ: Կանաչ հինգերորդ գրաֆիկը ցույց է տալիս ValueCache-ի օգտագործումը, այսինքն՝ քանի ValueCache-ն է հարվածում գործարկիչների համար, սա վայրկյանում մի քանի հազար արժեք է:

PostgreSQL. 50 nvps

Այնուհետև ես նույն սարքավորման վրա ավելացրի բեռը մինչև 50 հազար արժեք վայրկյանում:

Housekeeper-ից բեռնելիս 10 հազար արժեք տեղադրելը տևել է 2-3 վայրկյան:

Տնային տնտեսուհին արդեն սկսել է խանգարել աշխատանքին.

Երրորդ գրաֆիկը ցույց է տալիս, որ, ընդհանուր առմամբ, թակարդների և պատմության սինչերների ծանրաբեռնվածությունը դեռևս 60% է: Չորրորդ գրաֆիկում HistoryCache-ն արդեն սկսում է բավականին ակտիվորեն լրացվել Housekeeper-ի շահագործման ընթացքում։ Այն լցված է 20%-ով, որը կազմում է մոտ 0,5 ԳԲ։

PostgreSQL. 80 nvps

Այնուհետև ես ավելացրեցի բեռը մինչև 80 հազար արժեք վայրկյանում: Սա մոտավորապես 400 հազար տվյալների տարր է և 280 հազար գործարկիչ:

Պատմության երեսուն սինչերների բեռնման արժեքը արդեն բավականին բարձր է:

Նաև մեծացրել եմ տարբեր պարամետրեր՝ պատմության համաժամեցիչներ, քեշեր։

Իմ ապարատում պատմության համաժամեցիչների բեռնումը առավելագույնս ավելացավ: HistoryCache-ը արագ լցվեց տվյալների հետ. մշակման համար տվյալները կուտակվել էին բուֆերում:

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

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

Երկրորդ սերվեր

Ես վերցրեցի մեկ այլ սերվեր, որն արդեն ուներ 48 պրոցեսոր և 128 ԳԲ օպերատիվ հիշողություն։ Ես կարգավորեցի այն. դրեցի այն 60 պատմության համաժամեցման վրա և հասա ընդունելի կատարման:

Փաստորեն, սա արդեն արտադրողականության սահմանն է, որտեղ ինչ-որ բան պետք է անել:

TimescaleDB. 80 nvps

Իմ հիմնական խնդիրն է փորձարկել TimescaleDB-ի հնարավորությունները Zabbix բեռի դեմ: 80 հազար արժեք վայրկյանում շատ է, չափումների հավաքման հաճախականությունը (իհարկե, բացառությամբ Yandex-ի) և բավականին մեծ «կարգավորման»:

Յուրաքանչյուր գծապատկերում կա անկում. սա հենց տվյալների տեղափոխումն է: Zabbix սերվերում ձախողումներից հետո պատմության համաժամացման բեռնման պրոֆիլը շատ փոխվեց. այն երեք անգամ ընկավ:

TimescaleDB-ն թույլ է տալիս մուտքագրել տվյալները գրեթե 3 անգամ ավելի արագ և օգտագործել ավելի քիչ HistoryCache:

Համապատասխանաբար, դուք ժամանակին կստանաք տվյալներ:

TimescaleDB. 120 nvps

Այնուհետև ես ավելացրեցի տվյալների տարրերի թիվը մինչև 500 հազար: Հիմնական խնդիրն էր փորձարկել TimescaleDB-ի հնարավորությունները. ես ստացա 125 հազար արժեք վայրկյանում հաշվարկված արժեք:

Սա աշխատանքային «կարգավորում» է, որը կարող է երկար ժամանակ աշխատել: Բայց քանի որ սկավառակս ընդամենը 1,5 ՏԲ էր, մի երկու օրում լցրեցի։

Ամենակարևորն այն է, որ միաժամանակ ստեղծվեցին նոր TimescaleDB միջնորմներ։

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

Որպես օրինակ, ես ցույց կտամ համայնքի շատերից մեկ գրաֆիկ: Նկարում TimescaleDB-ն միացված է, որի շնորհիվ պրոցեսորի վրա io.weight օգտագործելու ծանրաբեռնվածությունն ընկել է։ Նվազել է նաև ներքին գործընթացի տարրերի օգտագործումը։ Ավելին, սա սովորական վիրտուալ մեքենա է սովորական նրբաբլիթի սկավառակների վրա, ոչ թե SSD:

Արդյունքները

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

TimescaleDB-ը հեշտ է կարգավորվում, տալիս է կատարողականի առավելություններ, լավ է աշխատում Zabbix-ի և առավելություններ ունի PostgreSQL-ի նկատմամբ.

Եթե ​​դուք օգտագործում եք PostgreSQL և չեք նախատեսում փոխել այն, խորհուրդ եմ տալիս օգտագործեք PostgreSQL-ը TimescaleDB ընդլայնմամբ՝ Zabbix-ի հետ համատեղ. Այս լուծումը արդյունավետորեն աշխատում է մինչև միջին «տեղադրում»:

Երբ ասում ենք «բարձր կատարողականություն», նկատի ունենք Բարձր բեռնում ++. Դուք երկար սպասել չեք ունենա՝ իմանալու տեխնոլոգիաների և գործելակերպերի մասին, որոնք հնարավորություն են տալիս ծառայություններին սպասարկել միլիոնավոր օգտատերերի: Ցուցակ զեկույցներ նոյեմբերի 7-ի և 8-ի համար մենք արդեն կազմել ենք, բայց այստեղ հանդիպումներ ավելին կարելի է առաջարկել:

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

Source: www.habr.com