Հոդվածի թարգմանությունը պատրաստվել է դասընթացի մեկնարկի նախօրեին .
Ժամանակ առ ժամանակ հարցեր են առաջանում Գլյուսթերի կողմից միջուկի կարգավորման վերաբերյալ առաջարկությունների և դրա անհրաժեշտության վերաբերյալ։
Այս անհրաժեշտությունը հազվադեպ է առաջանում: Աշխատանքային բեռների մեծ մասի դեպքում միջուկը շատ լավ է աշխատում: Այնուամենայնիվ, կա նաև թերություն: Պատմականորեն, միջուկը Linux կամավոր կերպով սպառում է մեծ քանակությամբ հիշողություն, եթե հնարավորություն տրվի, այդ թվում՝ քեշավորման համար՝ որպես կատարողականությունը բարելավելու հիմնական միջոց։
Շատ դեպքերում սա լավ է աշխատում, բայց ծանրաբեռնվածության դեպքում կարող է խնդիրներ առաջացնել։
Մենք մեծ փորձ ունենք հիշողությունը մեծ ծավալով աշխատող համակարգերի հետ, ինչպիսիք են CAD-ը, EDA-ն և այլն, որոնք դանդաղում էին ծանրաբեռնվածության տակ։ Եվ երբեմն մենք խնդիրների էինք հանդիպում Gluster-ում։ Հիշողության օգտագործումը և սկավառակի լատենտությունը մի քանի օր ուշադիր հետևելուց հետո մենք ունեցանք սկավառակի գերբեռնվածություն, հսկայական iowait, միջուկի խափանումներ, սառեցումներ և այլն։
Այս հոդվածը տարբեր իրավիճակներում կատարված բազմաթիվ պարամետրերի կարգավորման փորձերի արդյունք է։ Այս պարամետրերի շնորհիվ ոչ միայն բարելավվել է ընդհանուր արձագանքունակությունը, այլև զգալիորեն կայունացել է կլաստերի աշխատանքը։
Հիշողությունը կարգավորելիս առաջին հերթին պետք է ուշադրություն դարձնել վիրտուալ հիշողության (VM) ենթահամակարգին, որն ունի մեծ թվով տարբերակներ, որոնք կարող են շփոթեցնող լինել։
vm.swappiness
Parameter vm.swappiness որոշում է, թե որքանով է միջուկը օգտագործում swap-ը RAM-ի համեմատ: Սկզբնական կոդում այն նաև սահմանվում է որպես «մուտքագրված հիշողությունը գողանալու հակում»: Բարձր swappiness արժեքը նշանակում է, որ միջուկն ավելի հավանական է, որ փոխարինի մուտքագրված էջերը: Ցածր swappiness արժեքը նշանակում է հակառակը. միջուկը կփոխարինի ավելի քիչ էջեր հիշողությունից: Այլ կերպ ասած, որքան բարձր է արժեքը, vm.swappiness, այնքան ավելի շատ համակարգը կօգտագործի սվոփը։
Մեծ քանակությամբ սվոփի օգտագործումը անցանկալի է, քանի որ տվյալների հսկայական բլոկներ են բեռնվում և բեռնաթափվում RAM-ում: Շատերը պնդում են, որ սվոփիությունը պետք է բարձր լինի, բայց իմ փորձից ելնելով՝ այն «0» դնելը բարձրացնում է արտադրողականությունը:
Ավելին կարող եք կարդալ այստեղ՝
Բայց կրկին, այս կարգավորումները պետք է օգտագործվեն զգուշությամբ և միայն կոնկրետ ծրագիրը փորձարկելուց հետո: Բարձր ծանրաբեռնվածությամբ հոսքային ծրագրերի համար այս պարամետրը պետք է սահմանվի «0»: «0»-ի փոխելը բարելավում է համակարգի արձագանքողականությունը:
vm.vfs_cache_pressure
Այս պարամետրը կարգավորում է միջուկի կողմից օգտագործված հիշողությունը դիրեկտորիայի օբյեկտների և ինոդերի քեշավորման համար։
100 լռելյայն արժեքի դեպքում միջուկը կփորձի «արդարացիորեն» ազատել dentry և inode քեշերը pagecache-ի և swapcache-ի նկատմամբ։ vfs_cache_pressure-ի իջեցումը հանգեցնում է նրան, որ միջուկը պահպանում է dentry և inode քեշերը։ Երբ արժեքը «0» է, միջուկը երբեք չի մաքրի dentry և inode քեշերը հիշողության ճնշման պատճառով, և դա հեշտությամբ կարող է հանգեցնել հիշողության պակասի սխալի։ vfs_cache_pressure-ի 100-ից բարձր բարձրացումը հանգեցնում է նրան, որ միջուկը առաջնահերթություն է տալիս dentry և inode քեշերի փոխարինմանը։
GlusterFS-ն օգտագործելիս, մեծ քանակությամբ տվյալներ և շատ փոքր ֆայլեր ունեցող շատ օգտատերեր կարող են հեշտությամբ սպառել սերվերի վրա զգալի քանակությամբ RAM՝ inode/dentry քեշավորման պատճառով, ինչը կարող է հանգեցնել արտադրողականության վատթարացման, քանի որ միջուկը ստիպված է մշակել տվյալների կառուցվածքներ 40 ԳԲ հիշողությամբ համակարգում: Այս պարամետրը 100-ից ավելի սահմանելը շատ օգտատերերի օգնել է հասնել ավելի արդար քեշավորման և բարելավել միջուկի արձագանքողականությունը:
vm.dirty_background_ratio և vm.dirty_ratio
Առաջին պարամետրը (vm.dirty_background_ratio) սահմանում է կեղտոտ էջերով հիշողության տոկոսը, որին հասնելուց հետո անհրաժեշտ է սկսել կեղտոտ էջերի սկավառակի վրա ֆոնային մաքրումը: Մինչև այս տոկոսին հասնելը, էջերը չեն մաքրվում սկավառակի վրա: Եվ երբ մաքրումը սկսվում է, այն կատարվում է ֆոնային ռեժիմով՝ առանց ընդհատելու գործող գործընթացները:
Երկրորդ պարամետրը (vm.dirty_ratio) որոշում է հիշողության այն տոկոսը, որը կարող է զբաղեցվել կեղտոտ էջերով՝ մինչև հարկադիր մաքրումը տեղի ունենա։ Երբ այս շեմին հասնում են, բոլոր գործընթացները դառնում են համաժամանակյա (արգելափակված) և նրանց թույլ չի տրվում շարունակել մինչև իրենց կողմից պահանջված մուտքի/ելքի գործողությունը իրականում չավարտվի և տվյալները չհայտնվեն սկավառակի վրա։ Բարձր մուտքի/ելքի ծանրաբեռնվածության դեպքում սա խնդիր է առաջացնում, քանի որ տվյալների քեշավորում չկա, և մուտքի/ելքի կատարող բոլոր գործընթացները արգելափակված են՝ սպասելով մուտքի/ելքի։ Սա հանգեցնում է մեծ թվով կախված պրոցեսների, բարձր ծանրաբեռնվածության, համակարգի անկայունության և վատ աշխատանքի։
Այս արժեքների նվազեցումը հանգեցնում է նրան, որ տվյալները ավելի հաճախ են տեղափոխվում սկավառակ և չեն պահվում RAM-ում։ Սա կարող է օգնել մեծ քանակությամբ հիշողություն ունեցող համակարգերին, որոնք սովորաբար տեղափոխում են 45-90 ԳԲ էջի քեշ սկավառակ, ինչը մեծ լատենտություն է առաջացնում առջևի ծրագրերի համար՝ նվազեցնելով ընդհանուր արձագանքունակությունը և ինտերակտիվությունը։
"1" > /proc/sys/vm/pagecache
Էջի քեշը քեշ է, որը պահում է ֆայլերի և կատարվող ծրագրերի տվյալները, այսինքն՝ էջեր՝ ֆայլերի կամ բլոկային սարքերի իրական պարունակությամբ: Այս քեշն օգտագործվում է սկավառակի ընթերցումների քանակը նվազեցնելու համար: «1» արժեքը նշանակում է, որ քեշն օգտագործում է RAM-ի 1%-ը, և սկավառակի ընթերցումները կլինեն ավելի շատ, քան RAM-ը: Դուք պարտավոր չեք փոխել այս կարգավորումը, բայց եթե դուք մտահոգված եք էջի քեշը կառավարելու հարցում, կարող եք օգտագործել այն:
"վերջնաժամկետ" > /sys/block/sdc/queue/scheduler
Մուտք/ելք ժամանակացույցը միջուկային բաղադրիչ է։ Linux, որը կարգավորում է ընթերցման և գրման հերթերը։ Տեսականորեն, խելացի RAID կառավարիչի համար ավելի լավ է օգտագործել «noop»-ը, քանի որ Linux Ժամանակացույցը ոչինչ չգիտի սկավառակի ֆիզիկական երկրաչափության մասին, ուստի ավելի արդյունավետ է թույլ տալ, որ կառավարիչը, որը լավ գիտի սկավառակի երկրաչափությունը, հնարավորինս արագ մշակի հարցումը: Այնուամենայնիվ, «վերջնաժամկետը», կարծես, բարելավում է աշխատանքի արդյունավետությունը: Ժամանակացույցերի մասին լրացուցիչ տեղեկություններ կարելի է գտնել միջուկի սկզբնական փաստաթղթերում: Linux: linux/Documentation/block/*osched.txtԵվ ես նաև նկատեցի ընթերցման թողունակության աճ խառը գործողությունների ժամանակ (շատ գրառումներ):
"256" > /sys/block/sdc/queue/nr_requests
Բուֆերում I/O հարցումների քանակը, նախքան դրանք ժամանակացույցին փոխանցելը: Որոշ կառավարիչներ ունեն ներքին հերթ (queue_depth), որը մեծ է I/O ժամանակացույցի nr_requests-ից, ուստի I/O ժամանակացույցը քիչ հնարավորություն ունի ճիշտ առաջնահերթություն տալու և միավորելու հարցումները: Deadline և CFQ ժամանակացույցերի համար ավելի լավ է, երբ nr_requests-ը կառավարիչի ներքին հերթի 2 անգամ մեծ է: Հարցումների միավորումը և վերադասավորումը օգնում են ժամանակացույցին ավելի արագ արձագանքել ծանրաբեռնվածության դեպքում:
արձագանք "16" > /proc/sys/vm/page-cluster
Page-cluster պարամետրը կարգավորում է միաժամանակ փոխանակման համար գրվող էջերի քանակը: Վերևում նշված օրինակում արժեքը սահմանվել է «16»՝ համապատասխանելու RAID շերտի 64 ԿԲ չափին: Սա անիմաստ է, երբ swappiness = 0 է, բայց եթե swappiness-ը սահմանեք 10 կամ 20, ապա այս արժեքի օգտագործումը կօգնի ձեզ, երբ RAID շերտի չափը 64 ԿԲ է:
blockdev --setra 4096 /dev/<devname> (-sdb, hdc կամ dev_mapper)
Շատ RAID կարգավորիչների համար բլոկային սարքի լռելյայն կարգավորումները հաճախ հանգեցնում են վատ աշխատանքի: Վերոնշյալ տարբերակի ավելացումը կարգավորում է 4096 * 512 բայթանոց հատվածների համար նախնական ընթերցումը: Առնվազն հոսքային գործողությունների համար սա մեծացնում է արագությունը՝ սկավառակի բնիկ քեշը լրացնելով նախնական ընթերցմամբ այն ժամանակահատվածում, որը միջուկն օգտագործում է մուտք/ելք պատրաստելու համար: Քեշը կարող է տեղավորել տվյալներ, որոնք կպահանջվեն հաջորդ ընթերցման ժամանակ: Չափազանց շատ նախնական ընթերցումը կարող է խափանել մեծ ֆայլերի պատահական մուտք/ելքը, եթե այն օգտագործում է սկավառակի պոտենցիալ օգտակար ժամանակ կամ բեռնում է տվյալներ քեշից դուրս:
Ստորև բերված են ֆայլային համակարգի մակարդակի վերաբերյալ ևս մի քանի առաջարկություններ։ Սակայն դրանք դեռևս չեն փորձարկվել։ Համոզվեք, որ ձեր ֆայլային համակարգը գիտի շերտի չափը և զանգվածում սկավառակների քանակը։ Օրինակ, դա raid5 զանգված է՝ վեց սկավառակներից բաղկացած 64K շերտի չափսերով (իրականում՝ հինգ, քանի որ մեկ սկավառակն օգտագործվում է պարիտետի համար)։ Այս առաջարկությունները հիմնված են տեսական ենթադրությունների վրա և հավաքված են 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
