Բացակայող swap ֆայլը, որը սառեցրեց մեր սերվերները

Սեպտեմբերի 24-ին մեր արտադրական սերվերներից մեկը դադարեց պատասխանել։ Load balancer-ը այն անառողջ նշեց, և մեր հեռավոր հրամանների գործիքը չէր կարողանում հասնել դրան, բայց ոչինչ չէր խափանվել և ոչինչ չէր սպանվել հիշողության չափից ավելի օգտագործման համար։ Սերվերը թրեշինգ էր անում․ swap տարածության չլինելու և կոնտեյներների՝ մեքենայի հիշողությունից ավելին օգտագործելու թույլտվության պայմաններում Linux-ը ժամանակն անցկացնում էր ֆայլերը դուրս հանելով և նորից կարդալով, որոնք իրեն պետք էին աշխատելու համար, և գրեթե առաջ չէր գնում։ 2 ԳԲ swap ֆայլի ավելացումը յուրաքանչյուր սերվերի վրա լուծեց խնդիրը։ Ավելի հետաքրքիր դասը վերաբերում էր առողջության ստուգումներին։

Ինչ էր «կախված» նշանակում

• Load balancer-ի առողջության ստուգումները այդ սերվերի վրա ժամանակը սպառեցին։
• AWS Systems Manager-ի միջոցով ուղարկված հրամանները մնում էին «Pending» վիճակում և երբեք չէին աշխատում։
• Logs-ում out-of-memory սպանություն չկար։ Ոչ մի պրոցես չէր մահացել։

Մեկ շաբաթ առաջ մենք արտադրությունը տեղափոխել էինք ավելի փոքր ARM սերվերների վրա, յուրաքանչյուրը 2 ԳԲ RAM-ով։ Մեր staging սերվերը՝ ավելի փոքր նույնիսկ, նույն կերպ էր սառել deploy-ի ընթացքում կոնտեյներային պատկեր բացելիս։

Ինչու հիշողության սխալ չկար

Linux-ը պրոցես է սպանում միայն այն ժամանակ, երբ իսկապես սպառվում է վերականգնելի հիշողությունը։ Մինչ այդ այն հիշողություն է վերցնում page cache-ից՝ ֆայլերի պատճեններից, որոնք պահում է RAM-ում, ներառյալ աշխատող ծրագրերի կոդը։

Մեր սերվերների վրա կոնտեյներների միացյալ հիշողության սահմանները գումարվում էին մոտ 3.3 ԳԲ՝ մոտ 1.8 ԳԲ օգտագործելի հիշողությամբ մեքենայի վրա։ Սովորաբար դրանք բոլորը միաժամանակ չեն օգտագործում իրենց սահմանը։ Երբ օգտագործում էին, միջուկը շարունակում էր դուրս հանել ծրագրի կոդը cache-ից՝ տեղ ազատելու համար, իսկ հենց այդ կոդը նորից աշխատելիս՝ կարդալ դիսկից։ Այդ ցիկլը՝ թրեշինգը, կարող է մեքենան գրեթե ամբողջությամբ անարձագանք դարձնել, մինչ տեխնիկապես երբեք չի սպառում հիշողությունը։ Այսպիսով ոչինչ չի սպանվում, և ոչինչ չի վերականգնվում։

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

Շտկումը

Սերվերի bootstrap սկրիպտն այժմ ստեղծում է 2 ԳԲ swap ֆայլ ցածր swappiness կարգավորմամբ (10) ամեն անգամ, երբ սերվերը բեռնվում է կամ վերականգնվում է։ Ցածր swappiness-ը նշանակում է, որ միջուկը դեռ նախընտրում է աշխատանքային հիշողությունը պահել RAM-ում, բայց հազվադեպ դիպված էջերը կարող են տեղափոխվել դիսկ՝ ծրագրի կոդը cache-ից դուրս մղելու փոխարեն։ Մենք կիրառեցինք այն կենդանի երկու արտադրական սերվերների և staging-ի վրա, իսկ deploy խողովակաշարը bootstrap սկրիպտը վերահրապարակում է յուրաքանչյուր արտադրական deploy-ի ժամանակ, որպեսզի փոխարինված սերվերը նույնպես ստանա այն։

Ավելի մտահոգիչը․ անառողջ սերվերը մնաց

Մեր սերվերների խումբը օգտագործում էր EC2 առողջության ստուգումներ՝ «մեքենան աշխատո՞ւմ է», ոչ load balancer-ի առողջության ստուգումներ՝ «պատասխանո՞ւմ է արդյոք հարցումներին»։ Այսպիսով սերվերը, որից load balancer-ը հրաժարվել էր, խմբի համար դեռ առողջ էր։ Այն երբեք չէր փոխարինվի։ Արտադրությունը հանգիստ կաշխատեր մեկ սերվերի վրա, մինչև ինչ-որ մեկը նկատեր և մյուսը վերամեկնարկեր։

Խմբը load balancer-ի առողջության ստուգումների վրա փոխելը ակնհայտ շտկումն է թվում, բայց մեզ համար պարզ չէ․ deploy-ի ընթացքում սերվերները միտումնավոր սխալով են պատասխանում իրենց առողջության endpoint-ին, որպեսզի balancer-ը դրանք դուրս բերի (տե՛ս ինչպես հասանք զրո 502-ի deploy-ներին։ Խումբը, որը փոխարինում է սերվերները այդ ազդանշանով, կփոխարիներ դրանք յուրաքանչյուր deploy-ի մեջտեղում։

Ուստի առայժմ ավելացրինք քայլ մեր deploy-ի ստուգաթերթում՝ յուրաքանչյուր deploy-ից հետո ստուգել յուրաքանչյուր թիրախի առողջությունը load balancer-ի վրա, ոչ միայն այն, որ deploy աշխատանքը անցել է։ Եթե հրամանները սերվերին մնում են «Pending» վիճակում, այն թրեշինգ է անում․ վերամեկնարկեք այն, այն արդեն դուրս է շրջանառությունից։

Ինչ սովորեցինք

• «Չխափանվելը» չի նշանակում «առողջ»։ Թրեշինգը սխալ չի արտադրում, միայն այնքան ծայրահեղ դանդաղություն, որ մեքենան դադարում է պատասխանել։
• Փոքր սերվերները swap են պետք։ Նույնիսկ քիչ, ցածր swappiness-ով, տալիս է միջուկին տեղ, որտեղ դնել սառը հիշողությունը։
• Հիշողության սահմանները, որոնք գումարվում են ավելի, քան մեքենան ունի, խաղադրույք են։ Երբեմն կորցնում եք այն։ Իմացեք, թե երբ եք այն արել։
• Իմացեք, թե որ առողջության ստուգումին է ձեր ավտոմասշտաբավորումը վստահում։ Առողջության ստուգում, որը միայն հարցնում է «VM-ը միացա՞ծ է», չի փոխարինի այն սերվերը, որը դադարել է աշխատել։