Ахицын шошгон дахь санах ойн алдагдал, out-of-memory ослын шалтгаан

Нэг оройн 9-р сард хэрэглэгчийн ажлын талбарт AI агент эргэлтийн дундуур out-of-memory алдаатай унасан. Гол сэжигтнүүд — хэт олон дэд агент зэрэг ажиллах, эсвэл контекст хэт том болох — хоёулаа буруу байсан. Жинхэнэ шалтгаан нь төлөвийн шошго байв: загвар богино shell командыг хэдхэн тэмдэгтээр урсгах үед бид хэсэг бүр дээр хүртэл нь ирсэн бүх команд-ыг ахицын шошго болгон дахин илгээдэг байсан. 124 КБ-ын нэг команд ойролцоогоор 41,000 үйл явдал, 690 МБ-ын дараалсан мөрүүд болсон.

Агент хэрхэн урсгадаг вэ

Mythex дээр бүтээхэд агент таны төслийн хувийн cloud sandbox дотор ажилладаг. Загвар бичих явцад гаралт нь таны браузерт урсдаг: текст үгээр үгээр гарч, агент хэрэгсэл ажиллуулах үед — жишээ нь файл бичдэг shell команд — та түүний шошгыг шууд шинэчлэгдэхийг харж, юу хийж байгааг мэднэ.

Загвар жижиг хэсгээр урсгадаг. Бидний ашигласан загварт эдгээр хэсгүүд ихэвчлэн гурван тэмдэгт урттай байв.

Эхний таамаглал буруу байсан

Таарсан асуудал масштабын асуудал мэт харагдсан тул бид тэндээс эхэлсэн.

• Зэрэгцээ дэд агентууд уу? Эргэлтэд хоёр л ашигласан, тус бүр ойролцоогоор 1.5 МБ төлөв барьсан. Хангалтгүй.
• Хадгалагдсан trace-ууд уу? Бидний tracing run tree-г санах ойд хадгалдаг байсан, гэвч ослын үеийн heap-ийн хэмжээтэй огт ойрхон биш байсан.

Хоёулаа боломжит түүх байсан бөгөөд хоёулаа итгэхэд хямд байсан. Аль нь ч ослыг давтаж чадаагүй. Бид дахин дахин сурдаг сургамж: таамаглал нь давтагдахгүй бол шалтгаан биш.

Үнэхээр давтаж үзэх нь

Бид үйлдвэрлэлтэй ижил санах ойн хязгаартай түр sandbox бүтээж, бодит сүлжээний удаан уншигчтай, гэхдээ хуурамч загвар агуулсан — бодит мэт гурван тэмдэгтийн хэсгээр том файл урсгадаг. Бид сокетийн нөгөө талын уншигчийг жинхэнэ сүлжээ шиг удаан болгосон.

Энэ л ажилласан. Heap өсөж, процесс ижил алдаатай унасан.

Механизм нь ажиглахад энгийн байсан. Загвар том команд — энэ тохиолдолд 124 КБ-ын файл бичдэг heredoc — бичиж байх үед бидний streaming код хэсэг бүр дээр хэрэгслийн шошгыг шинэчилдэг байв. Шошго нь шинэ гурван тэмдэгт биш, хүртэл нь ирсэн бүх команд байв. Тиймээс үйл явдлууд өсдөг: 3 тэмдэгт, дараа нь 6, 9… 124 КБ хүртэл, ойролцоогоор 41,000 удаа. Сокет тэдгээрийг үүсгэснээс хурдан илгээж чадаагүй тул бичих буферт мөрүүд хуримтлагдаж — ойролцоогоор 690 МБ.

Засвар

• Шошгыг хязгаарла. Ахицын шошго юу болж байгааг хэлэхэд л хангалттай. Одоо 200 тэмдэгтээр хязгаарлагдсан, мөн хэсэгчилсэн команд дахин уншихыг бид хурдыг хязгаарладаг.
• Квадрат залгалтаас зайлсхий. Урсгалын хэсгүүдийг давтан string залгах нь том гаралтын хувьд O(n²). Бид шугаман хугацаанд залгадаг chunk-д суурилсан арга руу шилжсэн.

Дараа нь бид урсгалын үйл явдлаар хязгааргүй өсч болох бүх зүйлийг хайж, хязгаарласан:

• Чатад харагдах амьд командын гаралт багцлагдаж, сүүлийн 8,000 тэмдэгтээр хадгалагддаг.
• Үйл явдлын мөр бүр 4 МБ-аар хязгаарлагдсан.
• Браузерт дахин холбогдсоны дараа дээд хэмжээнд хүрэхийн тулд ашигладаг replay буфер төсөл бүрт 8 МБ-аар хязгаарлагдсан.
• Хуучин checkpoint-ууд эргэлтийн явцад хасагддаг, хамгийн шинэ төлөв болон өмнөх эргэлтүүдэд хэрэгтэй anchor-уудыг хадгална.

Үерийг үнэнчээр туршиж үзэх нь

Энэ нь туршихад илүү хэцүү байсан хоёр шалтгаантай:

1. Бодит загвар хамтран ажилладаггүй. Маш том файл хэвлэхийг хүсвэл загвар ихэвчлэн татгалзана, нэгтгэнэ, эсвэл илүү ухаалгаар бичнэ. Үерийг туршихын тулд бодит агентын кодоор ажиллах, таны хэлснийг яг хийдэг скрипттэй загвар хэрэгтэй.
2. Скриптүүд загвар шиг ажиллах ёстой. Бидний анхны скрипт загвар бүрт ижил хариултын ID-г дахин ашигладаг байсан тул агентын framework хариу бүрийг өмнөхийн орлуулалт гэж үзэж, эргэлтийг эрт дуусгадаг байв. Энэ нь UI шинэчлэлтийн алдаа шиг харагдсан. Тийм биш — туршилтын harness бидэнд худлаа хэлж байсан. Мөн санах ойн тоо бодит байхын тулд скрипт дээр загварын жинхэнэ контекстийн хязгаарыг хэрэгжүүлэх шаардлагатай байсан.

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

• Streaming UI бага алдааг үржүүлдэг. «Хэсэг бүрт» илгээсэн аливаа зүйл хэдэн арван мянга удаа илгээгддэг. Дельта илгээ, эсвэл ачааллыг хязгаарла.
• Удаан хил дамнасан буфер бүрийг хязгаарла. Сокет, replay лог, checkpoint бүр дээд хязгаар хэрэгтэй.
• Засахаас өмнө давтаж үз. Бидний эхний хоёр тайлбар үнэн мэт сонсогдсон ч буруу байсан.

Хэрэв сүүлийн үед Mythex чатад маш урт файл агент зогсохгүй гарч ирсэн бол энэ бол шалтгаануудын нэг.