ఇంజనీరింగ్

ఇంజనీరింగ్

Mythex ఎలా రూపొందించబడింది, ఎలా నడుస్తుంది — ఏం విఫలమైంది, ఎలా సరిచేశాం అనే దానితో సహా.

• విఫలమైన రీపబ్లిష్ ఎప్పుడూ పనిచేస్తున్న బ్యాకెండ్‌ను తొలగించదు — విఫలమైన రీపబ్లిష్ లైవ్ API ను తొలగించవచ్చు, లేదా తప్పు వెర్షన్‌ను నడుస్తూ ఉంచవచ్చు. పబ్లిష్ తప్పినప్పుడు Mythex దాన్ని ఎలా వెనక్కి తీసుకుంటుందో మూడు మార్పులు.
• ప్రతి సర్వర్‌కు కాకుండా ఒక్కసారే వెళ్లే అలర్ట్‌లు — రోజుకు ఒకసారి వెళ్లాల్సిన అలర్ట్ ఒక మధ్యాహ్నం ఐదుసార్లు వచ్చింది. మెమరీ డిడూప్ రెండు సర్వర్లతో ఎందుకు విఫలమైందో, షేర్డ్ స్టోర్ దాన్ని ఎలా సరిచేసిందో.
• ఎవరినీ వేచి ఉంచకుండా పెద్ద వర్క్‌స్పేస్‌లకు మారడం — 2 GB కి మారిన తర్వాత వర్క్‌స్పేస్‌లలో నాలుగో వంతు 1 GB వద్దనే ఉన్నాయి. మొదటి పరిష్కారం ఒకరిని ఏడు నిమిషాలు వేచి ఉంచింది. ఏమి మార్చామో.
• డేటాబేస్‌లకు వాటు నిజంగా వాడేదాని ఆధారంగా బిల్లింగ్ — ప్రతి డేటాబేస్ ఇప్పుడు కొలిచిన వినియోగం ఆధారంగా, గంట గంటకూ బిల్ చేయబడుతుంది. పాత అంచనా రెండు విధాలుగా తప్పు; ఎందుకు మార్చామో.
• పబ్లిష్ అయిన వెంటనే క్రాష్ అయ్యే యాప్‌లను పట్టుకోవడం — మూడు పబ్లిష్‌లు మా హెల్త్ చెక్‌ను దాటాయి, వాటి API ప్రతి బూట్‌లోనూ సెకన్ల తర్వాత క్రాష్ అయింది. కారణం: ఐదు ఎంట్రీల జాబితాలో క్రాష్‌లను లెక్కించడం.
• చిత్రాలతో నిండిన ఏజెంట్ టర్న్‌లను మెమరీలో ఉంచడం — కేటలాగ్ స్కాన్‌లను చూస్తూ ఉన్న ఏజెంట్ టర్న్ 952 MB వద్ద మెమరీ అయిపోయింది. మూడు వేర్వేరు కారణాలు, ప్రతిదీ చిత్రాలను ఎక్కువ సేపు పట్టుకుంది, మరియు వాటిని ఎలా సరిచేశామో.
• సుదీర్ఘ ఏజెంట్ టర్న్‌లను కాంటెక్స్ట్ విండో లోపల ఉంచడం — మా సబ్-ఏజెంట్లు మోడల్ తిరస్కరించే వరకు పెరిగిపోయాయి, గది కోసం ముందే ఆగిపోయాయి, లేదా రష్యన్ టోకెన్లను తప్పుగా లెక్కించాయి. దీర్ఘ AI పని పూర్తవడానికి మూడు పరిష్కారాలు.
• ఫోన్ నిద్రపోయినప్పుడు చాట్‌ను సజీవంగా ఉంచడం — ఫోన్లు నిద్రపోతాయి, ట్యాబ్‌లు మారుస్తాయి, బిల్డ్ మధ్యలో నెట్‌వర్క్ పోతుంది. రెండు బగ్‌లు చాట్‌ను ఆగిపోయేలా లేదా తర్వాత సగం సమాధానం చూపేలా చేశాయి. వాటిని ఎలా కనుగొని సరిచేశామో.
• ఒక భారీ చాట్ మా API ను ఎలా కిందకు తీసుకెళ్లగలదు — సెప్టెంబర్ 28న మా రెండు API సర్వర్లు ఒకేసారి మెమరీ అయిపోయాయి. మొదటి పరిష్కారం ఎక్కువ మెమరీ; అసలైనది చాట్ చరిత్రను పరిమాణం బట్టి లోడ్ చేయడం.
• Publish రెండుసార్లు నొక్కితే ఇప్పుడు ఒక్కసారే పబ్లిష్ అవుతుంది — ఒకే యాప్ కోసం మూడు పబ్లిష్ అభ్యర్థనలు 84ms తేడాతో వచ్చి ప్రతిదీ పూర్తి డిప్లాయ్ నడిపింది. డేటాబేస్ ఎవరు పబ్లిష్ చేయాలో ఎలా నిర్ణయిస్తుందో, మిగతావారికి నిజం ఎలా చెబుతుందో.
• మా స్వంత సైట్‌ను సరిచేసినప్పుడు నేర్చుకున్న SEO పాఠాలు — ప్రతి పేజీలో డూప్లికేట్ FAQ మార్కప్, Google లో తప్పు థంబ్‌నెయిల్, ఎవరూ క్లిక్ చేయని టెంప్లేట్ పేజీలు, మా ఎడ్జ్ తిరస్కరించిన ఒక మార్గం: mythex.ai లో మేము కనుగొని సరిచేసినవి.
• స్టాటిక్ సైట్‌లు మళ్లీ ప్రచురిస్తున్నప్పుడు కూడా అందుబాటులో ఉంటాయి — స్టాటిక్ సైట్ మళ్లీ ప్రచురించినప్పుడు ఇప్పుడు కొత్త బిల్డ్ వచ్చే వరకు పాత సైట్ సేవ చేస్తుంది. మార్పులు సెకన్లలో కనిపిస్తాయి.
• ప్రోగ్రెస్ లేబుల్‌లో దాగి ఉన్న Out-of-Memory క్రాష్ — మా AI ఏజెంట్ ఒక పెద్ద ఫైల్ రాస్తున్నప్పుడు మెమరీ అయిపోయింది. కారణం మోడల్ కాదు, సమాంతర సబ్-ఏజెంట్లూ కాదు — ఒక స్టేటస్ లేబుల్ 41,000 సార్లు మళ్లీ పంపబడింది.
• మా సర్వర్లను స్తంభింపజేసిన తప్పిపోయిన స్వాప్ ఫైల్ — ఒక ప్రొడక్షన్ సర్వర్ క్రాష్ అవ్వకుండానే స్పందించడం ఆగిపోయింది — out-of-memory కిల్ లేకుండా, స్వాప్ లేని బాక్స్‌పై కేవలం page-cache థ్రాష్. ఏమి జరిగింది, మేము ఏమి మార్చాము.
• డెడ్ కనెక్షన్లు లేకుండా డేటాబేస్‌లను మేల్కొలపడం — నిద్ర నుంచి మేల్కొంటున్న ప్రచురించిన యాప్ మొదటి రిక్వెస్ట్‌ను 10–12 సెకన్లు పట్టుకుంది — అది నిద్రలో చనిపోయిన డేటాబేస్ కనెక్షన్లపై. దాన్ని 2.3 సెకన్లకు ఎలా తగ్గించామో.
• మేము మా స్వంత సర్వీస్‌లను రేట్-లిమిట్ చేస్తున్నాము — మా API యొక్క ప్రతి-చిరునామా రేట్ లిమిట్ మా స్వంత సర్వీస్‌లను ఒక బిజీ వ్యక్తిలా చూసింది, ప్రొడక్షన్‌లో అవి 429లు పొందడం మొదలుపెట్టాయి. మేము దానిని ఎలా కనుగొని సరిచేశాము.
• మేము Mythex సర్వర్లను ARMకు ఎందుకు మార్చాము — భారీ పని ప్రతి ప్రాజెక్ట్ sandbox లోకి తరలిన తర్వాత, మా సర్వర్లు మూడో వంతు మెమరీ మాత్రమే వాడాయి. చిన్న ARM ఇన్‌స్టాన్స్‌లు ఖర్చును సుమారు 30% తగ్గించాయి. ఎలాగో.
• డిప్లాయ్‌లను జీరో 502 ఎర్రర్‌లకు ఎలా తీసుకొచ్చాము — మా డిప్లాయ్‌లతో పోటీపడిన వాచ్‌డాగ్, చాలా ఆలస్యంగా గమనించిన లోడ్ బ్యాలెన్సర్: రెండింటినీ ఎలా కనుగొని సరిచేశామో, డిప్లాయ్‌లు 10 502లు నుంచి సున్నాకు ఎలా చేరాయో.