በሂደት መለያ ውስጥ የተደበቀው የማህደረ ትውስታ ብልሽት

መስከረም መጨረሻ ላይ አንድ ምሽት፣ በአንድ ተጠቃሚ የስራ ቦታ ውስጥ ያለው AI ወኪል በተራ መካከል በማህደረ ትውስታ እጥረት (out-of-memory) ስህተት ተበላሸ። ግልጽ ተጠርጣሪዎቹ፦ በአንድ ጊዜ የሚሮጡ ብዙ ንዑስ ወኪሎች፣ ወይም ያደገ በጣም ትልቅ አውድ፣ ሁለቱም ስህተት ነበሩ። እውነተኛው መንስኤ የሁኔታ መለያ ነበር፤ ሞዴሉ ትልቅ የሼል ትዕዛዝን ጥቂት ቁምፊዎች በአንድ ጊዜ እየለቀቀ ሲሆን፣ በእያንዳንዱ ቁራጭ ላይ እስካሁን ያለውን ሙሉ ትዕዛዝ እንደ ሂደት መለያ እንደገና እንልክ ነበር። 124 KB የሆነ አንድ ትዕዛዝ ወደ 41,000 ገደማ ክስተቶች እና ወደ 690 MB በሰልፍ የተጠበቁ ሕብረቁምፊዎች ሆነ።

ወኪሉ ስራውን እንዴት ይለቀቃል

Mythex ላይ ስትገነቡ ወኪሉ በፕሮጀክታችሁ የግል ደመና ሳንድቦክስ ውስጥ ይሰራል። ሞዴሉ ሲጽፍ ውጤቱ ወደ አሳሻችሁ በቀጥታ ይመለሳል፦ ጽሑፍ ቃል በቃል ይታያል፣ መሳሪያ ሲሮጥ፣ ለምሳሌ ፋይል የሚጽፍ የሼል ትዕዛዝ፣ የመሳሪያው መለያ በቀጥታ ይዘምናል፤ ምን እየሰራ እንደሆነ ታውቃላችሁ።

ሞዴሉ በትንሽ ቁራጮች ይለቀቃል። ከምንጠቀምበት ሞዴል ጋር እነዚህ ቁራጮች ብዙ ጊዜ ሶስት ቁምፊዎች ብቻ ነበሩ።

የመጀመሪያዎቹ መላምቶች ስህተት ነበሩ

ብልሹው የመጠን ችግር ይመስል ነበር፤ ስለዚህ እዚያ ጀመርን።

ትይዩ ንዑስ ወኪሎች? ተራው ሁለት ብቻ ተጠቅሞ ነበር፤ እያንዳንዳቸው 1.5 MB ያህል ሁኔታ ይዘው ነበር። በቂ አይደለም።
የተቀመጡ ዱካዎች? የእኛ ትሬሲንግ የሩጫ ዛፍ በማህደረ ትውስታ ያስቀምጥ ነበር፤ ግን በብልሹው ጊዜ ካለው ክምር መጠን ጋር ቅርብ አልነበረም።

ሁለቱም ሊታመኑ የሚችሉ ታሪኮች ነበሩ፤ ሁለቱም በቀላሉ ይታመኑ ነበር። ግን ሁለቱም ብልሹውን አላባዙም። ደጋግመን የምንማረው ትምህርት፦ ብልሹውን ካላባዛ መላምት ምክንያት አይደለም።

በእውነት ማባዛት

ከምርት ጋር ተመሳሳይ የማህደረ ትውስታ ገደብ ያለው ጊዜያዊ ሳንድቦክስ ሰራን፤ እንዲሁም በእውነታዊ ሶስት-ቁምፊ ቁራጮች ትልቅ ፋይል የሚለቅ የውሸት ሞዴል። በሶኬቱ ሌላኛው ጫፍ ያለውን አንባቢም እንደ እውነተኛ አውታረ መረብ ቀርፋፋ አደረግነው።

ይሄ ሰራ። ክምሩ ጨመረ፤ ሂደቱም ተመሳሳዩን ስህተት ይዞ ሞተ።

መንገዱ ሲታይ ቀላል ነበር። ትልቅ ትዕዛዝ (በዚህ ሁኔታ 124 KB ፋይል የሚጽፍ heredoc) ሲጽፍ፣ ስትሪሚንግ ኮዳችን በእያንዳንዱ ቁራጭ የመሳሪያውን መለያ ያዘምን ነበር። መለያው አዲሶቹ ሶስት ቁምፊዎች አልነበረም፤ እስካሁን ያለው ሙሉ ትዕዛዝ ነበር። ስለዚህ ክስተቶቹ ያድጉ ነበር፦ 3 ቁምፊ፣ ከዚያ 6፣ ከዚያ 9፣ … እስከ 124 KB፣ ወደ 41,000 ጊዜ ገደማ። ሶኬቱ ከሚፈጠሩት በፍጥነት መላክ ስላልቻለ፣ በጽሑፍ ቋቱ ውስጥ እንደ ሕብረቁምፊ ተከማቹ፤ ወደ 690 MB ገደማ።

መፍትሄው

መለያውን ገድቡ። የሁኔታ መለያ የሚሆነው የሚሆነውን መግለጽ ብቻ ነው። አሁን በ200 ቁምፊ ተገድቧል፤ እና ከፊል ትዕዛዙን እንደገና የምንቃኘው ድግግሞሽ ተገድቧል።
ወደ ኳድራቲክ መጨመር አቁሙ። ለትልቅ ውጤቶች የተለቀቁ ቁራጮችን በተደጋጋሚ የሕብረቁምፊ መደመር መቀላቀል O(n²) ነው። ወደ በቸንክ-የተመሰረተ አቀራረብ ቀይረን በመስመር ጊዜ እንዲጨምር አደረግን።

ከዚያ በኋላ ያለ ገደብ ሊያድግ የሚችል ሌላ ነገር ፈለግን፤ በፍሰቱ ላይ ብዙ ውጤት እንዳይገታ ገድበነዋል፦

በቻቱ የሚታየው የቀጥታ ትዕዛዝ ውጤት ተሰብስቦ የመጨረሻዎቹን 8,000 ቁምፊዎች ብቻ ይይዛል።
የነጠላ ክስተት መስመሮች በ4 MB ተወስነዋል።
አሳሽ ከተገናኘ በኋላ ለመያዝ የሚጠቀምበት ዳግም-ማጫወቻ ቋት በፕሮጀክት 8 MB ተወስኗል።
የቆዩ ቼክፖይንቶች ተራው ሲሄድ ይሰረዛሉ፤ አዲሱን ሁኔታ እና ቀደምት ተራዎች የሚያስፈልጓቸውን መልህቆች ይይዛሉ።

ጎርፍን በታማኝነት መሞከር

ይህን ከሚገባው በላይ ለመፈተሽ ያስቸገሩ ሁለት ነገሮች፦

እውነተኛ ሞዴሎች አይተባበሩም። ግዙፍ ፋይል እንዲያትሙ ብትጠይቁ ብዙ ጊዜ ፈቃደኛ አይሆኑም፣ ያጠቃልላሉ ወይም በተሻለ መንገድ ይጽፋሉ። ጎርፍን ለመፈተሽ ትክክል የምትሉትን በትክክል የሚያደርግ፣ በእውነተኛው የወኪል ኮድ ውስጥ የሚሮጥ የተቀረጸ ሞዴል ያስፈልጋል።
ስክሪፕቶች እንደ ሞዴሎች መምሰል አለባቸው። የመጀመሪያው የተቀረጸ ሞዴላችን በእያንዳንዱ ምላሽ ላይ ተመሳሳይ የምላሽ መታወቂያ ይጠቀም ነበር፤ ስለዚህ የወኪል ማዕቀፉ እያንዳንዱን ምላሽ የቀደመው መተኪያ አድርጎ ተራዎችን ቀደም ብሎ ያበቃ ነበር። የUI ማዘመኛ ስህተት ይመስል ነበር፤ ግን አልነበረም፤ የፈተና መሳሪያው እየዋሸን ነበር። የሞዴሉን እውነተኛ የአውድ ገደብ በስክሪፕቱ ማስገደድም ነበረብን፤ ያለዚያ የማህደረ ትውስታ ቁጥሮቹ እውነታዊ አልነበሩም።

ከዚህ የወሰድነው

የስትሪሚንግ UI ትናንሽ ስህተቶችን ያባዛል። “በቸንክ” የሚላክ ማንኛውም ነገር በአስር ሺዎች ጊዜ ይላካል። ዴልታዎችን ላኩ፤ ወይም የጭነቱን መጠን ገድቡ።
በዘገየ ድንበር የሚያልፍ እያንዳንዱን ቋት ገድቡ። ሶኬቶች፣ ዳግም-ማጫወቻ ምዝግቦችና ቼክፖይንቶች ሁሉም ጣሪያ ያስፈልጋቸዋል።
ከመጠገን በፊት ማባዛት። የመጀመሪያዎቹ ሁለት ማብራሪያዎቻችን ትክክል የሚመስሉ ግን ስህተት ነበሩ።

በቅርብ ጊዜ በMythex ቻት ውስጥ ወኪሉ ሳይቆም በጣም ረዥም ፋይል ከታየ፣ ይህ ከምክንያቶቹ አንዱ ነው።