Մեկ ծանր չատը կարող էր API-ն վթարի ենթարկել

Սեպտեմբերի 28-ին, մոտ 17 րոպե թողարկումից հետո, մեր երկու production API սերվերները միաժամանակ սպառեցին հիշողությունը, վերագործարկվեցին, և մոտ հինգ րոպե բեռնվածքի հավասարակշռիչը ոչ մի առողջ սերվեր չուներ, որ տրաֆիկ ուղարկեր։ Մեր առաջին շտկումը API-ին տվեց երկու անգամ ավելի հիշողություն։ Իրական պատճառը նույն օրը հետո երևաց. մի կոնկրետ չատ բացելը API-ից խնդրում էր մեկ հարցումով բեռնել 53 ՄԲ հաղորդագրություններ։ Չատի պատմությունը այժմ բեռնվում է էջերով, որոնք սահմանափակված են և՛ չափով, և՛ քանակով, և այդ չատը բացվում է 5 ՄԲ առաջին էջով՝ վթարի փոխարեն։

Ի՞նչ ընկավ

Մեր API-ն աշխատում է որպես կոնտեյներ յուրաքանչյուր երկու սերվերից մեկի վրա, բեռնվածքի հավասարակշռիչի հետևում։ Յուրաքանչյուր կոնտեյների հիշողության սահմանը 384 MiB էր։ Հանգստի վիճակում այն օգտագործում է 130–140 MiB, ուստի սահմանը բավական ազատ տեսք ուներ։

Երկու կոնտեյներն էլ միաժամանակ հասան այդ սահմանին և վթարի ենթարկվեցին «JavaScript heap out of memory»-ով։ Heap-ը այն հիշողությունն է, որ Node.js պրոցեսը օգտագործում է իր օբյեկտների համար։ Քանի որ երկու սերվերն էլ միաժամանակ ընկան, հարցումներն ուղղորդելու տեղ չմնաց։ Սա ամենավատ տեսակի խափանումն է երկու սերվերով կառուցվածքի համար. կրկնօրինակումը օգնում է միայն այն դեպքում, երբ խնդիրները չեն պատահում միաժամանակ։

Առաջին շտկումը. ավելի շատ տարածք

Ժամանակը ցույց էր տալիս թողարկմանը։ Թողարկումից հետո այն agent-ի քայլերը, որ թողարկումը կտրել էր, վերսկսվում են և նորից պահում են իրենց տրանսկրիպտները, և այդ աշխատանքի պայթյունը ակնհայտ աղբյուր թվաց հիշողության աճի համար։

Ուստի առաջին փոփոխությունը բարձրացրեց API-ի սահմանը 384 MiB-ից մինչև 768 MiB։ Կիրառեցինք այն ուղիղ երկու սերվերների վրա նույն օրը և գրանցեցինք deploy կոնֆիգուրացիայում, որպեսզի հաջորդ deploy-ը լուռ չվերադարձնի 384-ը։ Ձեռքով արված շտկումը, որը հաջորդ deploy-ը հետ է բերում, նույն խափանումը նորից վերադարձնելու սովորական եղանակն է։

Ավելի հիշողությունը ողջամիտ անվտանգության պաշար էր։ Այն բացատրություն չէր։

Իրական պատճառը. մեկ հարցում, 71 ՄԲ

Նույն օրը ավելի ուշ մենք վերարտադրեցինք վթարը մի չատի պատճենի վրա՝ օգտագործելով production-ի հին հիշողության սահմանը։ Պատճենը միայն իր վրա կործանեց API-ն՝ առանց որևէ deploy-ի։

Երբ բացում եք նախագիծ, վեբ հավելվածը API-ից խնդրում է չատի պատմությունը։ Վերջնակետը վերադարձնում էր ամենանոր 30 հաղորդագրությունը ամբողջությամբ։ Շատ չատերի համար 30 հաղորդագրությունը փոքր է։ Այս չատի համար ամենանոր 30 հաղորդագրությունը բազայում 53 ՄԲ էր, իսկ պատասխանը՝ 71 ՄԲ։ Agent-ի մի քանի պատասխաններ 4–10 ՄԲ էին յուրաքանչյուրը, հիմնականում ենթա-agent-ների տրանսկրիպտները․ օգնական agent-ները, որոնք գլխավոր agent-ը սկսում է՝ առաջադրանքի մի մասը զուգահեռ աշխատելու համար, և որոնց ամբողջական աշխատանքը պահվում է պատասխանի հետ։

Այդ մեկ պատասխանը կառուցելը ավելի շատ heap էր պահանջում, քան API-ն ուներ։ Եվ նախագծի բացումը կամ թարմացումը յուրաքանչյուր անգամ նորից ուղարկում էր հարցումը։ Մեկ չատը կարող էր վթարի մատնել ցանկացած սերվեր, որի վրա որ հայտնվեր, և քանի որ էջը կարող էր վերբեռնվել, այն կարող էր հասնել երկուսին էլ։

«30 հաղորդագրություն»-ը երբեք իրական չափի սահման չէր եղել։ Դա քանակի սահման էր, որը պատահաբար փոքր էր սովորական չատերի համար։

Շտկումը. էջեր՝ սահմանված չափով և քանակով

Պատմության էջը այժմ 30 հաղորդագրություն է կամ մոտ 4 ՄԲ դրանցից, ինչ էլ որ առաջինը լրանա։

Այն աշխատում է երկու քայլով․

1. Նախ խնդրել չափերը։ API-ն բազայից խնդրում է ամենանոր հաղորդագրությունների ID-ները և պահված չափերը՝ առանց բովանդակության։ Այդ հարցումը էժան է, ինչ չափի էլ լինեն հաղորդագրությունները։
2. Բեռնել միայն ինչ տեղավորվում է։ Նորից ամենանորից դեպի ամենահինը քայլելով՝ ավելացնում է հաղորդագրություններ, մինչև հաջորդը էջը կանցնեցնի 4 ՄԲ-ից։ Միայն այդ տողերն են այնուհետև բեռնվում ամբողջությամբ։

Երկու կանոն պահում են սա անվտանգ․

• Ամենանոր հաղորդագրությունը միշտ գնում է էջ, չափից անկախ։ Էջ, որը ոչինչ չի վերադարձնում, չատը կկանգնեցնի՝ առանց հետ ոլորելու հնարավորության։
• Ոչինչ չի կտրվում։ Ոչ մի հաղորդագրություն չի կրճատվում կամ ընկնում։ Չատի մնացածը բեռնվում է «Scroll up for earlier messages» կառավարման միջոցով, որն արդեն օգտագործվում էր ավելի հին հաղորդագրությունների համար, մեկ էջով մեկ անգամ։

Գտանք ևս մեկ տեղ նույն ձևով։ Երբ դադարեցնում եք քայլը, API-ն ստուգում է վերջին մի քանի պատասխանները, արդյոք դրանցից որևէ մեկը դատարկ է և պետք է մաքրվի։ Դա անում էր՝ բեռնելով ութ ամբողջական հաղորդագրություն։ Բազմամեգաբայթանոց պատասխաններով չատի վրա սա նույն խնդիրն էր փոքր ձևով։ Այժմ այն բազային տալիս է այո-կամ-ոչ հարց՝ արդյոք այս հաղորդագրությունն ունի որևէ բովանդակություն, առանց բովանդակությունն ինքը բեռնելու։

Ինչպես ստուգեցինք

Չատի պատճենի վրա՝ հին 384 MiB սահմանով.

• Առաջին էջը 5 ՄԲ է։ Առաջ նույն հարցումը կործանում էր API-ն։
• Հինգ բրաուզերի ներդիր միաժամանակ բացում են չատը, և հիշողության գագաթնակետը 154 ՄԲ է։
• Ամբողջ չատը հետ ոլորելով՝ վերադարձվում են բոլոր 190 հաղորդագրությունները, յուրաքանչյուրը ճիշտ մեկ անգամ, ճիշտ հերթականությամբ։

Էջեր ընտրող տրամաբանությունը նաև ունի միավոր թեստեր, այդ թվում՝ մեկը, որ կառուցված է այդ չատի ամենանոր հաղորդագրությունների իրական չափերից։ Առաջին էջը վերադարձնում է մեկ հաղորդագրություն, ասում է, որ կան ավելին, և հաջորդ էջը սկսվում է դրա հաջորդից։

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

• Քանակը չափի սահման չէ։ Ցանկացած վերջնակետ, որ վերադարձնում է «ամենանոր N»-ը այնպիսի բանից, որ կարող է անսահմանափակ աճել, պետք է նաև բայթային բյուջե ունենա։ Տվյալը վերջում միշտ կգտնի բացը։
• Ակնհայտ կասկածյալը միշտ չէ, որ պատճառն է։ Թողարկումը իրական գրգռիչ էր լրացուցիչ աշխատանքի համար, և ավելի հիշողությունը արժեր ունենալ։ Բայց վթարը վերարտադրվեց առանց թողարկման, և առանց վերարտադրելու մենք կկանգնեինք հիշողության աճի վրա։
• Երկու սերվերը միասին են ձախողվում, երբ ստանում են նույն հարցումը։ Կրկնօրինակումը պաշտպանում է մեկ սերվերի մահից։ Այն չի պաշտպանում այն հարցումից, որը կործանում է ցանկացած սերվեր, որին հասնում է, հատկապես այն, որ օգտատերը բնականաբար կկրկնի՝ էջը վերբեռնելով։
• Շտկեք կոնֆիգուրացիայում, ոչ միայն սերվերի վրա։ Հիշողության աճը նույն օրը մտավ deploy կոնֆիգուրացիա, որպեսզի հաջորդ deploy-ը այն պահեր։

Այս երկրորդ վերջին պատմությունն է agent-ի արտադրանքին վերաբերող հիշողության մասին։ Առաջինը առաջընթացի պիտակ էր, որ հերթագրեց 690 ՄԲ տողեր։ Եթե Mythex-ում ենթա-agent-ներ եք օգտագործում, դրանց աշխատանքի մասին կարող եք կարդալ փաստաթղթերում։