အင်ဂျင်နီယာ

အင်ဂျင်နီယာ

Mythex ကို တည်ဆောက်ပြီး လည်ပတ်ပုံ၊ ဘာပျက်သွားပြီး မည်သို့ပြင်ခဲ့သည် အပါအဝင်။

• ပျက်ကွက်သော republish သည် အလုပ်လုပ်နေသော backend ကို ဘယ်တော့မှ မဖျက်ပါ — publish ပျက်ကွက်ရင် app ရဲ့ live API ကို ဖျက်ပစ်နိုင်သလို ပျက်စီးနေတဲ့ version ကိုလည်း run ထားနိုင်ပါတယ်။ Mythex က ပြန်ဖြုတ်ပုံကို ပြင်ဆင်ခဲ့ပုံ သုံးချက်။
• Server တစ်ခုစီအတွက် မဟုတ်ဘဲ တစ်ကြိမ်သာ ပေးပို့တဲ့ Alert များ — တစ်ရက်တစ်ကြိမ် ပို့တဲ့ alert တစ်ခု နေ့လည်တစ်နေ့မှာ ငါးကြိမ် ရောက်ခဲ့တယ်။ server နှစ်ခုနဲ့ deploy ရှိတော့ memory dedupe ဘာကြောင့် မအောင်မြင်လဲ၊ shared state နဲ့ ဘယ်လို ပြင်လဲ။
• လူတစ်ယောက်ကိုမှ မစောင့်စေဘဲ ပိုကြီးတဲ့ Workspace များသို့ ပြောင်းခြင်း — workspace လေးပုံတစ်ပုံက 2 GB သို့ ပြောင်းပြီးနောက်ပါ 1 GB မှာ ကျန်နေခဲ့တယ်။ ပထမ fix က တစ်ဦးကို မိနစ် ၇ စောင့်စေခဲ့တယ်။ ဘာပြောင်းလဲခဲ့လဲ၊ ထပ်ပြောင်းခဲ့လဲ။
• database တွေကို အမှန်တကယ် သုံးတဲ့အတိုင်း ငွေရှင်းခြင်း — app တစ်ခုစီရဲ့ database ကုန်ကျစရိတ်ကို ခန့်မှန်းခဲ့တာ မှန်မနေခဲ့ပါ။ ယခု database တစ်ခုစီကို တိုင်းတာထားတဲ့ သုံးစွဲမှုအလိုက် နာရီတိုင်း ငွေရှင်းပါတယ်။
• Publish ပြီးချင်း crash ဖြစ်တဲ့ App များကို ဖမ်းခြင်း — publish သုံးခုက health check အောင်ပေမဲ့ API က boot တိုင်း crash ဖြစ်နေခဲ့တယ်။ အကြောင်းက ငါးခုသာ ထိန်းတဲ့ list ထဲမှာ crash တွေ ရေတွက်ခဲ့တာ ဖြစ်တယ်။
• ပုံများများပါတဲ့ agent turn တွေကို memory အတွင်း ထိန်းထားခြင်း — catalogue scan တွေကို ဆက်ကြည့်နေတဲ့ agent turn တစ်ခု 952 MB မှာ memory ကုန်သွားခဲ့တယ်။ ပုံတွေကို ကြာကြာ ကိုင်ထားတဲ့ အကြောင်းရင်း သုံးခု၊ ပြင်ထားပုံ။
• ရှည်လျားတဲ့ agent turn တွေကို context window အတွင်း ထိန်းထားခြင်း — sub-agent တွေ ကြီးလာပြီး model က ငြင်းတာ၊ နေရာ ချွေတာဖို့ စောစော ရပ်တာ၊ ရုရှား token တွေ မှားရေတွက်တာ– ရှည်ကြာတဲ့ AI အလုပ် ပြီးအောင် လုပ်ပေးတဲ့ ပြင်ဆင်ချက် သုံးခု။
• ဖုန်း အိပ်သွားရင် chat ကို အသက်ရှင်နေအောင် ထိန်းခြင်း — ဖုန်း အိပ်၊ tab ပြောင်း၊ network ပြတ်တဲ့အခါ chat ရပ်သွားတာနဲ့ တစ်ဝက်တစ်ပျက် ပြန်ပြတဲ့ bug နှစ်ခုကို ဘယ်လို တွေ့ပြီး ဘယ်လို ပြင်ခဲ့လဲ။
• chat တစ်ခုက ကျွန်တော်တို့ API ကို ဘယ်လို ပိတ်နိုင်လဲ — စက်တင်ဘာ 28 မှာ API ဆာဗာနှစ်လုံးစလုံး memory ကုန်သွားခဲ့တယ်။ ပထမ ပြင်ဆင်ချက်က memory တိုးတာ၊ အမှန်တကယ် ပြင်ဆင်ချက်က chat history ကို အရွယ်အစားနဲ့ load လုပ်တာ။
• Publish ကို နှစ်ခါနှိပ်ရင် ယခု တစ်ခါပဲ Publish လုပ်ပါတယ် — Publish request သုံးခု 84ms ခြားပြီး deploy သုံးခု run ခဲ့တာကို ဘယ်သူ နိုင်မလဲ database က ဆုံးဖြတ်ပြီး၊ တခြားသူတွေကို အမှန်အတိုင်း ပြောခဲ့ပုံ။
• ကိုယ်ပိုင်ဆိုဒ်ကို SEO ပြင်ဆင်ရာမှ သင်ခန်းစာများ — FAQ markup ထပ်နေခြင်း၊ Google တွင် မှား thumbnail၊ မေးခွန်းမဖြေသော template စာမျက်နှာများ၊ staging ပိတ်ထားသော လမ်းကြောင်း — ပြင်ဆင်ခဲ့သည်များ။
• Static ဆိုဒ်များသည် ပြန် publish နေစဉ်လည်း ဆက်ရှိနေသည် — Static ဆိုဒ်ကို ပြန် publish လုပ်စဉ် ဟောင်းဆိုဒ် ဆက်ရှိနေပြီး ပြောင်းလဲမှုများ စက္ကန့်အတွင်း ပေါ်လာသည်။
• Progress Label ထဲတွင် ဝှက်ထားသော Out-of-Memory ပြဿနာ — AI agent ဖိုင်ကြီးရေးစဉ် memory ကုန်ခဲ့သည်။ အကြောင်းရင်းမှာ status label ကို ၄၁,၀၀၀ ကြိမ် ပြန်ပို့ခဲ့ခြင်း ဖြစ်သည်။
• Server များကို အေးစေခဲ့သော Swap File မရှိခြင်း — Production server သည် crash မဖြစ်ဘဲ တုံ့ပြန်မှု ရပ်သွားခဲ့သည် — swap မရှိသော စက်ပေါ်တွင် page-cache thrash ဖြစ်ခြင်း။ ပြင်ခဲ့ပုံ။
• Database ကို နိုးစေစဉ် သေနေသော Connection မရှိစေရန် — Sleep ပြီးနိုးလာသော အက်ပ်၏ ပထမ request သည် သေနေသော database connection များကြောင့် ၁၀–၁၂ စက္ကန့် ကြာခဲ့သည်။ ၂.၃ စက္ကန့်အထိ လျော့ခဲ့ပုံ။
• ကျွန်ုပ်တို့ ကိုယ်ပိုင် ဝန်ဆောင်မှုများကို ကန့်သတ်နေခဲ့သည် — API ၏ address တစ်ခုချင်းစီ rate limit သည် ကျွန်ုပ်တို့ဝန်ဆောင်မှုများကို လူတစ်ယောက်ဟု ယူဆခဲ့ပြီး production တွင် 429 ရခဲ့သည်။ ဘယ်လို ရှာတွေ့ပြီး ပြင်ခဲ့သလဲ။
• Mythex ၏ Server များကို ARM သို့ ရွှေ့ခဲ့ပုံ — Heavy work များကို sandbox သို့ ရွှေ့ပြီးနောက် server memory ၏ သုံးပုံတစ်ပုံသာ သုံးခဲ့သည်။ ARM ငယ်များက ကုန်ကျစရိတ် ~၃၀% လျှော့ခဲ့သည်။
• Deploy များကို 502 error သုညသို့ ဘယ်လိုရောက်ခဲ့သလဲ — Deploy နှင့် အပြိုင်ပြေးသော watchdog နှင့် ပိတ်ရန် နောက်ကျသော load balancer။ နှစ်ခုလုံးကို ဘယ်လိုတွေ့ပြီး ပြင်ခဲ့သလဲ၊ deploy 502 ၁၀ ခုမှ သုညအထိ ဘယ်လို တိုင်းတာခဲ့သလဲ။