Հոդվածի թարգմանությունը պատրաստվել է դասընթացի մեկնարկի նախօրեին .
Պարբերաբար, արի ու տես, որ հարցեր են առաջանում միջուկի թյունինգի վերաբերյալ Գլաստերի առաջարկությունների և դրա անհրաժեշտության մասին:
Նման անհրաժեշտություն հազվադեպ է առաջանում։ Աշխատանքային բեռների մեծ մասում միջուկը շատ լավ է աշխատում: Չնայած կա մի բացասական կողմ. Պատմականորեն, Linux միջուկը պատրաստ է սպառել մեծ հիշողություն, եթե հնարավորություն տրվի, ներառյալ քեշը որպես կատարողականությունը բարելավելու հիմնական միջոց:
Շատ դեպքերում դա լավ է աշխատում, բայց ծանր բեռի դեպքում դա կարող է հանգեցնել խնդիրների:
Մենք մեծ փորձ ունենք հիշողության ինտենսիվ համակարգերի հետ, ինչպիսիք են CAD, EDA և նմանատիպերը, որոնք սկսեցին դանդաղել ծանր բեռի տակ: Եվ երբեմն մենք խնդիրներ էինք ունենում Գլասթերում: Հիշողության օգտագործումը և սկավառակի հետաձգումը երկար օրերի ընթացքում ուշադիր դիտարկելուց հետո մենք ստացանք դրանց գերբեռնվածությունը, հսկայական iowait, միջուկի սխալները (միջուկի օփս), սառեցումները և այլն:
Այս հոդվածը տարբեր իրավիճակներում կատարված բազմաթիվ թյունինգային փորձերի արդյունք է: Այս պարամետրերի շնորհիվ բարելավվել է ոչ միայն ընդհանուր արձագանքումը, այլև կլաստերը զգալիորեն կայունացել է։
Ինչ վերաբերում է հիշողության կարգավորմանը, ապա առաջինը, որին պետք է ուշադրություն դարձնել, վիրտուալ հիշողության ենթահամակարգն է (VM, վիրտուալ հիշողություն), որն ունի մեծ թվով տարբերակներ, որոնք կարող են ձեզ շփոթեցնել:
vm.swappiness
Parameter vm.swappiness որոշում է, թե որքան է միջուկը օգտագործում swap (swap, paging) RAM-ի համեմատ: Նաև սկզբնական կոդում սահմանվում է որպես «քարտեզագրված հիշողությունը գողանալու միտում»։ Բարձր փոխանակումը նշանակում է, որ միջուկը ավելի շատ հակված կլինի փոխանակել քարտեզագրված էջերը: Փոխանակման ցածր արժեքը նշանակում է հակառակը. միջուկը ավելի քիչ կէջեր հիշողության մեջ: Այլ կերպ ասած, այնքան բարձր է արժեքը vm.swappiness, այնքան համակարգը կօգտագործի swap-ը:
Փոխանակման մեծ օգտագործումը անցանկալի է, քանի որ տվյալների հսկայական բլոկներ բեռնվում և բեռնաթափվում են RAM-ում: Շատերը պնդում են, որ swapiness արժեքը պետք է մեծ լինի, բայց իմ փորձով, այն «0» դնելը հանգեցնում է ավելի լավ կատարման:
Ավելին կարող եք կարդալ այստեղ -
Բայց, կրկին, այս կարգավորումները պետք է կիրառվեն խնամքով և միայն որոշակի հավելվածի փորձարկումից հետո: Բարձր բեռնված հոսքային հավելվածների համար այս պարամետրը պետք է սահմանվի «0»: Երբ փոխվում է «0»-ի, համակարգի արձագանքումը բարելավվում է:
vm.vfs_cache_pressure
Այս պարամետրը վերահսկում է միջուկի կողմից սպառվող հիշողությունը գրացուցակի և ինոդի օբյեկտների քեշավորման համար (դենտրի և ինոդ):
100 լռելյայն արժեքով միջուկը կփորձի «արդար» հիմունքներով ազատել dentry և inode քեշերը pagecache-ից և swapcache-ից: Vfs_cache_pressure-ի նվազումը հանգեցնում է նրան, որ միջուկը պահում է դենտրի և ինոդի քեշերը: Երբ արժեքը «0» է, միջուկը երբեք չի մաքրի ատամնաշարը և ինոդի քեշը հիշողության ճնշման պատճառով, և դա կարող է հեշտությամբ հանգեցնել հիշողության կորստի սխալի: 100-ից բարձր vfs_cache_pressure-ի ավելացումը հանգեցնում է նրան, որ միջուկը առաջնահերթություն է տալիս ատամնաբուժական և ինոդային լվացմանը:
GlusterFS-ն օգտագործելիս մեծ քանակությամբ տվյալներ և շատ փոքր ֆայլեր ունեցող շատ օգտատերեր կարող են հեշտությամբ օգտագործել զգալի քանակությամբ RAM սերվերում՝ inode/dentry caching-ի պատճառով, ինչը կարող է հանգեցնել արդյունավետության վատթարացման, քանի որ միջուկը պետք է մշակի տվյալների կառուցվածքները համակարգի վրա: 40 ԳԲ հիշողությամբ: Այս արժեքը 100-ից բարձր սահմանելը շատ օգտատերերի օգնել է հասնել ավելի արդար քեշավորման և միջուկի բարելավված արձագանքման:
vm.dirty_background_ratio և vm.dirty_ratio
Առաջին պարամետր (vm.dirty_background_ratio) որոշում է կեղտոտ էջերով հիշողության տոկոսը, որին հասնելուց հետո անհրաժեշտ է սկսել հետին պլանում գտնվող կեղտոտ էջերը սկավառակի վրա: Քանի դեռ այս տոկոսը չի հասել, ոչ մի էջ չի լցվում սկավառակի վրա: Եվ երբ վերակայումը սկսվում է, այն աշխատում է հետին պլանում՝ չընդհատելով ընթացիկ գործընթացները:
Երկրորդ պարամետրը (vm.dirty_ratio) սահմանում է հիշողության այն տոկոսը, որը կարող են զբաղեցնել կեղտոտ էջերը՝ նախքան բռնկման բռնկումը: Այս շեմը հասնելուց հետո բոլոր գործընթացները դառնում են համաժամանակյա (արգելափակված) և չեն թույլատրվում շարունակել այնքան ժամանակ, քանի դեռ նրանց պահանջած I/O-ն իրականում չի ավարտվել, և տվյալները սկավառակի վրա չեն: Ծանր I/O-ի դեպքում դա խնդիր է առաջացնում, քանի որ տվյալների քեշավորում չկա, և I/O կատարող բոլոր գործընթացները արգելափակված են՝ սպասելով I/O-ին: Սա հանգեցնում է մեծ թվով կախված պրոցեսների, բարձր բեռի, համակարգի անկայունության և վատ կատարման:
Այս կարգավորումների նվազեցումը հանգեցնում է նրան, որ տվյալները ավելի հաճախ են լցվում սկավառակի վրա և չեն պահվում RAM-ում: Սա կարող է օգնել հիշողության ծանրաբեռնված համակարգերին, որոնք բավարար են 45-90 ԳԲ էջի քեշերը սկավառակի վրա լցնելու դեպքում, ինչը հանգեցնում է առջևի հավելվածների հսկայական ուշացման՝ նվազեցնելով ընդհանուր արձագանքման և ինտերակտիվությունը:
«1» > /proc/sys/vm/pagecache
Էջի քեշը քեշ է, որը պահում է ֆայլերի և գործարկվող ծրագրերի տվյալները, այսինքն՝ դրանք ֆայլերի իրական բովանդակությամբ կամ արգելափակող սարքերով էջեր են: Այս քեշը օգտագործվում է սկավառակի ընթերցումների քանակը նվազեցնելու համար: «1» արժեքը նշանակում է, որ RAM-ի 1%-ն օգտագործվում է քեշի համար, և սկավառակից ավելի շատ ընթերցումներ կլինեն, քան RAM-ից: Անհրաժեշտ չէ փոխել այս կարգավորումը, բայց եթե դուք պարանոյիկ եք վերահսկում էջի քեշը, կարող եք օգտագործել այն:
«վերջնաժամկետ» > /sys/block/sdc/queue/scheduler
I/O ժամանակացույցը Linux միջուկի բաղադրիչ է, որը կարգավորում է կարդալու և գրելու հերթերը: Տեսականորեն ավելի լավ է օգտագործել «noop» խելացի RAID կարգավորիչի համար, քանի որ Linux-ը ոչինչ չգիտի սկավառակի ֆիզիկական երկրաչափության մասին, ուստի ավելի արդյունավետ է թույլ տալ, որ կարգավորիչը, որը լավ գիտի սկավառակի երկրաչափությունը, մշակի հարցումը այնքան արագ, որքան հնարավոր է. Բայց կարծես «վերջնաժամկետը» բարելավում է կատարումը: Դուք կարող եք ավելին կարդալ ժամանակացույցների մասին Linux միջուկի սկզբնական կոդի փաստաթղթերում. linux/Documentation/block/*osched.txt. Եվ նաև ես տեսել եմ կարդալու թողունակության աճ խառը գործողությունների ժամանակ (շատերը գրում են):
«256» > /sys/block/sdc/queue/nr_requests
I/O հարցումների քանակը բուֆերում՝ նախքան դրանք ժամանակացույցին փոխանցելը: Որոշ կարգավորիչների ներքին հերթի չափը (queue_depth) ավելի մեծ է, քան I/O ժամանակացույցի nr_requests-ը, ուստի I/O ժամանակացույցը փոքր հնարավորություններ ունի ճիշտ առաջնահերթություն սահմանելու և միաձուլելու հարցումները: Վերջնաժամկետների և CFQ ժամանակացույցների համար ավելի լավ է, երբ nr_requests-ը 2 անգամ գերազանցում է վերահսկիչի ներքին հերթը: Հարցումների միաձուլումը և վերադասավորումն օգնում է ժամանակացույցին ավելի պատասխանատու լինել ծանր բեռի դեպքում:
echo «16» > /proc/sys/vm/page-cluster
Էջ-կլաստերի պարամետրը վերահսկում է էջերի քանակը, որոնք միաժամանակ գրվում են swap-ում: Վերոնշյալ օրինակում արժեքը սահմանվել է «16»՝ ըստ RAID շերտի 64 ԿԲ չափի: Անիմաստ է swappiness = 0-ի դեպքում, բայց եթե դուք սահմանել եք swappiness 10 կամ 20, ապա այս արժեքի օգտագործումը կօգնի ձեզ, երբ RAID շերտի չափը 64K է:
blockdev --setra 4096 /dev/<devname> (-sdb, hdc կամ dev_mapper)
Շատ RAID կարգավորիչների լռելյայն արգելափակման սարքի կարգավորումները հաճախ հանգեցնում են սարսափելի աշխատանքի: Վերոնշյալ տարբերակն ավելացնելով ստեղծվում է 4096 * 512 բայթ հատվածների առաջ ընթերցման հնարավորություն: Առնվազն հոսքային գործառնությունների համար արագությունը մեծանում է չիպի սկավառակի քեշը լրացնելով նախնական ընթերցմամբ այն ժամանակահատվածում, որն օգտագործվում է միջուկի կողմից I/O պատրաստելու համար: Քեշը կարող է պարունակել տվյալներ, որոնք կպահանջվեն հաջորդ ընթերցման ժամանակ: Չափազանց շատ նախաբեռնումը կարող է սպանել պատահական I/O մեծ ֆայլերի համար, եթե այն սպառում է սկավառակի հնարավոր օգտակար ժամանակը կամ բեռնում է տվյալներ քեշից դուրս:
Ստորև բերված են ևս մի քանի առաջարկներ ֆայլային համակարգի մակարդակով: Բայց դրանք դեռ չեն փորձարկվել։ Համոզվեք, որ ձեր ֆայլային համակարգը գիտի շերտի չափը և զանգվածի սկավառակների քանակը: Օրինակ, որ սա 5K stripe raid64 զանգված է վեց սկավառակից (իրականում հինգը, քանի որ մեկ սկավառակ օգտագործվում է հավասարության համար): Այս առաջարկությունները հիմնված են տեսական ենթադրությունների վրա և կազմված տարբեր բլոգներից/հոդվածներից RAID փորձագետների կողմից:
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Խոշոր ֆայլերի համար հաշվի առեք վերը թվարկված գծերի չափսերի ավելացումը:
Նախազգուշացում Վերևում նկարագրված ամեն ինչ խիստ սուբյեկտիվ է որոշ տեսակի հավելվածների համար: Այս հոդվածը չի երաշխավորում որևէ բարելավում առանց համապատասխան հավելվածների նախնական փորձարկման: Այն պետք է օգտագործվի միայն այն դեպքում, եթե դա անհրաժեշտ է բարելավել համակարգի ընդհանուր արձագանքումը, կամ եթե այն լուծում է ընթացիկ խնդիրները:
Լրացուցիչ նյութեր.
Կարդալ ավելին
Source: www.habr.com