Нэг хүнд чат манай API-г унагаж болох нь

9-р сарын 28-нд, хувилбар гарснаас 17 минутын дараа, бидний production API-ийн хоёр сервер нэгэн зэрэг санах ой дуусч, дахин эхэлсэн, мөн тав орчим минутын турш ачааллын балансер илгээх эрүүл сервергүй байсан. Бидний эхний засвар API-д хоёр дахин их санах ой өгсөн. Жинхэнэ шалтгаан тэр өдрийн оройд гарсан: нэг тодорхой чатыг нээхэд API нэг хүсэлтээр 53 МБ мессеж ачаалахыг хүссэн. Чатын түүх одоо тоогоор төдийгүй хэмжээгээр хязгаарлагдсан хуудсуудаар ачаалагдаж, тэр чат 5 МБ-ийн эхний хуудастай нээгддэг болсон, бүх зүйл унахгүй.

Юу унасан бэ

Манай API хоёр серверийн тус бүр дээр ачааллын балансерийн ард контейнер хэлбэрээр ажилладаг. Контейнер бүр 384 MiB санах ойн хязгаартай байсан. Амрахад 130–140 MiB ашигладаг тул хязгаар хангалттай зай мэт харагдаж байв.

Хоёр контейнер хоёуланд нь хязгаарт нэгэн зэрэг хүрч, «JavaScript heap out of memory» гэж унасан. Heap бол Node.js процессын ажиллаж буй объектуудад зориулсан санах ой юм. Хоёр сервер нэгэн зэрэг унасан тул хүсэлтийг чиглүүлэх газар үлдсэнгүй. Хоёр сервертэй тохиргооны хувьд энэ бол хамгийн муу төрлийн тасалдал: нөөцлөлт зөвхөн эвдрэл нэгэн зэрэг болоогүй үед л тусалдаг.

Эхний засвар: илүү зай

Цаг хугацаа нь хувилбартай холбоотой байсан. Хувилбарын дараа агентын эргэлтүүд, хувилбар тасалсан, дахин үргэлжлүүлж, яриагаа дахин хадгалдаг; тэр ачаалал санах ойн оргилд хүргэх шиг харагдсан.

Тиймээс эхний өөрчлөлт нь API-ийн хязгаарыг 384 MiB-аас 768 MiB болгосон. Бид үүнийг хоёр серверт тэр өдөртөө шууд хэрэгжүүлж, дараагийн deploy 384-ийг буцаахгүйн тулд тохиргооны файлд ч commit хийсэн. Серверт гараар хийсэн засварыг дараагийн deploy буцаавал ижил тасалдал дахин гарах нийтлэг арга юм.

Илүү санах ой сайн хамгаалалт байсан. Энэ нь тайлбар биш байсан.

Жинхэнэ шалтгаан: нэг хүсэлт, 71 МБ

Дараа нь тэр өдөр бид production-ий хуучин санах ойн хязгаар ашиглаад нэг чатын хуулбар дээр унадгийг дахин үйлдсэн. Хуулбар нь deploy-гүйгээр API-г өөрөө унагасан.

Төсөл нээхэд вэб апп API-аас чатын түүхийг хүсдэг. Энэ endpoint хамгийн сүүлийн 30 мессежийг бүтнээр буцаадаг байсан. Ихэнх чатын хувьд 30 мессеж жижиг. Энэ чатын хувьд хамгийн сүүлийн 30 мессеж өгөгдлийн санд 53 МБ, хариу нь 71 МБ байсан. Агентын хариултуудын хэдэн нь 4–10 МБ тус бүр байсан, ихэвчлэн дэд агентуудын бичлэгүүд: үндсэн агентын зарим хэсгийг зэрэгцүүлэн гүйцэтгэхээр эхлүүлдэг туслах агентууд, тэдгээрийн бүрэн ажлыг хариултын хамт хадгалдаг.

Тэр нэг хариултыг бүтээхэд API-д байснаас илүү heap шаардсан. Мөн төслийг нээх, шинэчлэх бүр хүсэлтийг дахин илгээдэг байсан. Нэг чат нь аль серверт ногдсоныг нь унагаж чадна, мөн хуудсыг дахин ачаалж болдог тул хоёуланд хүрч болно.

«30 мессеж» гэдэг нь хэзээ ч жинхэнэ хэмжээний хязгаар байгаагүй. Энэ нь тооны хязгаар байсан бөгөөд ихэвчлэн чатуудад жижиг байдаг байсан.

Засвар: тоо ба хэмжээ хоёуланд нь хязгаарласан хуудсууд

Түүхийн хуудас одоо 30 мессеж эсвэл ойролцоогоор 4 МБ, аль нь түрүүнд хүрэхээс хамаараад.

Энэ хоёр алхамаар ажилладаг:

1. Эхлээд хэмжээг асуу. API өгөгдлийн сангаас сүүлийн мессежүүдийн ID болон хадгалагдсан хэмжээг агуулгагүйгээр асуудаг. Энэ асуулга мессежүүд ямар том байсан ч хямд.
2. Таарах зүйлийг л ачаал. Шинээс хуучин руу алхаж, дараагийн мессеж хуудсыг 4 МБ-аас хэтрүүлэх хүртэл нэмдэг. Зөвхөн тэр мөрүүдийг бүтнээр ачаална.

Хоёр дүрэм нь үүнийг аюулгүй байлгадаг:

• Хамгийн сүүлийн мессеж хэмжээнээс үл хамааран хуудсанд үргэлж орно. Юу ч буцаадаггүй хуудас чатыг гацаах болно, буцаж гүйлгэх арга үлдэхгүй.
• Юу ч таслагддаггүй. Мессеж хэзээ ч тайрагдахгүй, унахгүй. Үлдсэн чат «Өмнөх мессежүүдийг харах» товчоор, хуучин мессежүүд аль хэдийн ашиглаж байсан шиг, нэг хуудсаар ачаална.

Дахин ижил хэв маягтай газар олдсон. Та хариултыг зогсоох үед API хамгийн сүүлийн хэдэн хариултыг шалгаж, хоосон байгаа эсэхийг харж, цэвэрлэх ёстой эсэхийг шалгадаг. Үүнийг найман бүтэн мессеж ачаалж хийдэг байсан. Олон мегабайт хариулттай чатын хувьд энэ нь жижиг хэлбэрийн ижил асуудал. Одоо API өгөгдлийн сангаас тийм/үгүй асуулт асуудаг — энэ мессеж ямар нэг агуулгатай юу — агуулгыг өөрөө ачаалахгүйгээр.

Бид яаж шалгасан бэ

Чатын хуулбар дээр, хуучин 384 MiB хязгаартай ажиллуулж:

• Эхний хуудас 5 МБ. Өмнө нь ижил хүсэлт API-г унагадаг байсан.
• Ижил чатыг нээсэн таван хөтчийн таб нэгэн зэрэг хамгийн их 154 МБ санах ой.
• Чатын бүхий л түүхээр гүйлгэхэд 190 мессеж бүгд нэг удаа, дараалалтай буцдаг.

Хуудас сонгох логикт нэгж тест бас бий, тэр чатын хамгийн сүүлийн мессежүүдийн жинхэнэ хэмжээгээр бүтээсэнийг оруулаад. Эхний хуудас нэг мессежтэй ирж, илүү байгааг хэлж, дараагийн хуудас дараагийнхаас эхэлнэ.

Бидний авсан дүгнэлт

• Тоо бол хэмжээний хязгаар биш. Хэмжээгээрээ хязгааргүй өсч болох зүйлийн «хамгийн сүүлийн N»-ийг буцаадаг аливаа endpoint-д байт төсөв хэрэгтэй. Өгөгдөл эцэстээ тэр цоорхойг олдог.
• Тодорхой сэжигтэн үргэлж шалтгаан биш. Deploy бол ажлыг нэмэгдүүлэх жинхэнэ өдөөгч байсан, мөн илүү санах ой үнэтэй байсан. Гэвч crash нь deploy-гүйгээр давтагдсан, мөн үүнийг давтаж чадаагүй бол бид санах ойн нэмэгдүүлэлтээр зогсох байсан.
• Хоёр сервер ижил хүсэлт авахад хамт унадаг. Нөөцлөлт нэг сервер унахаас хамгаалдаг. Аливаа сервер рүү хүрсэн хүсэлтийг эвддэг хүсэлтээс хамгаалдаггүй, ялангуяа хэрэглэгч хуудсыг дахин ачаалж дахин оролдох үед.
• Тохиргоонд засаарай, зөвхөн машин дээр биш. Санах ойн нэмэлт тэр өдөртөө deploy тохиргоонд орсон тул дараагийн deploy үүнийг хадгалсан.

Энэ бол агентын гаралттай холбоотой бидний саяхны санах ойн түүхийн хоёр дахь нь. Эхнийх нь 690 МБ мөр дараалуулсан статус шошго байсан. Mythex дээр дэд агент ашигладаг бол тэд хэрхэн ажилладагийг docs-д уншиж болно.