انجینئرنگ

انجینئرنگ

Mythex کیسے بنایا اور چلایا جاتا ہے، بشمول کیا خراب ہوا اور ہم نے اسے کیسے ٹھیک کیا۔

• ناکام ری پبلش کبھی کام کرنے والا بیک اینڈ نہیں مٹاتی — ایک ناکام ری پبلش کسی ایپ کی لائیو API حذف کر سکتی تھی، یا اس کا خراب نیا ورژن چلتا رہ سکتا تھا۔ Mythex کسی غلط ہونے والی پبلش کو کیسے واپس لیتا ہے، اس کی تین اصلاحات۔
• الرٹس جو ہر سرور پر نہیں، ایک بار چلیں — ایک دن میں ایک بار آنے والا الرٹ ایک دوپہر میں پانچ بار پہنچا۔ دو سرورز اور ڈپلائے کے ساتھ in-memory dedupe کیوں ٹوٹتا ہے، اور shared state نے اسے کیسے ٹھیک کیا۔
• بڑی ورک اسپیسز کی طرف منتقلی، بغیر کسی کو انتظار کرائے — 2 GB پر منتقلی کے بعد ہماری ایک چوتھائی ورک اسپیسز ابھی 1 GB پر اٹکی ہوئی تھیں۔ ہماری پہلی اصلاح نے ایک شخص کو سات منٹ انتظار کرایا۔ ہم نے کیا بدلا، اور پھر دوبارہ کیا بدلا۔
• databases کی billing ان کے اصل استعمال کے مطابق — ہم ہر ایپ کے database کی لاگت کا اندازہ لگاتے تھے، اور وہ اندازہ دونوں طرف سے غلط تھا۔ اب ہر database اصل استعمال سے billed ہوتا ہے، گھنٹہ بہ گھنٹہ۔
• پبلش کے فوراً بعد کریش ہونے والی ایپس کو پکڑنا — تین پبلشز ہمارے ہیلتھ چیک سے گزر گئے حالانکہ ان کا API ہر boot کے چند سیکنڈ بعد کریش ہو رہا تھا۔ وجہ: کریشوں کو پانچ اندراجات کی حد والی فہرست میں گننا۔
• تصویروں سے بھرے ایجنٹ turns کو memory کے اندر رکھنا — ایک ایجنٹ turn جو catalogue scans کو مسلسل دیکھ رہا تھا 952 MB پر memory ختم ہو گیا۔ تین الگ وجوہات، ہر ایک تصاویر کو زیادہ دیر تک رکھے ہوئے، اور ہم نے انہیں کیسے ٹھیک کیا۔
• طویل ایجنٹ turns کو context window کے اندر رکھنا — ہمارے sub-agents اتنے بڑھ جاتے تھے کہ model انکار کر دیتا، کمرہ بچانے کے لیے جلد رک جاتے، یا روسی میں tokens غلط گنتے۔ تین fixes جنہوں نے طویل AI کام کو مکمل ہونے دیا۔
• فون سوئے تو چیٹ کو زندہ رکھنا — فون سوتے ہیں، tabs بدلتے ہیں اور build کے دوران نیٹ ورک گراتے ہیں۔ دو bugs نے Mythex کی چیٹ کو اٹکا دیا یا بعد میں آدھا جواب دکھایا۔ ہم نے دونوں کو کیسے ڈھونڈا اور ٹھیک کیا۔
• ایک بھاری چیٹ ہمارا API بند کر سکتی تھی — 28 ستمبر کو ہمارے دونوں API سرورز ایک ساتھ memory ختم ہونے سے گر گئے۔ پہلا fix زیادہ memory تھی؛ اصل fix یہ تھا کہ چیٹ کی تاریخ سائز کے حساب سے لوڈ ہو، تعداد کے حساب سے نہیں۔
• دو بار Publish دبانے سے اب ایک بار ہی publish ہوتا ہے — ایک app کی تین publish درخواستیں 84 ملی سیکنڈ کے فرق سے پہنچیں اور ہر ایک نے مکمل deploy چلایا۔ ہم نے database کو فیصلہ کرنے دیا کہ کون publish کرے گا، اور باقیوں کو سچ بتایا۔
• اپنی سائٹ ٹھیک کرنے سے SEO کے سبق — ڈپلیکیٹ FAQ markup، Google میں غلط thumbnail، وہ template pages جن پر کوئی کلک نہیں کرتا تھا، اور ایک path جسے ہمارے edge نے رد کیا: mythex.ai پر جو ملا اور جو ٹھیک کیا۔
• Static Sites اب دوبارہ publish ہوتے وقت بھی چلتی رہتی ہیں — Static site کو دوبارہ publish کرنے سے پہلے اس کی live فائلیں خالی ہو جاتی تھیں۔ اب نئی build لگنے تک پرانی سائٹ چلتی ہے، اور تبدیلیاں چند سیکنڈ میں نظر آتی ہیں۔
• Progress Label میں چھپا ہوا Out-of-Memory کریش — ہمارا AI agent ایک بڑی فائل لکھتے وقت memory ختم ہو گیا۔ وجہ نہ model تھا نہ متوازی sub-agents، بلکہ ایک status label تھا جو 41,000 بار دوبارہ بھیجا گیا۔
• وہ غائب swap file جس نے ہمارے سرور جما دیے — ایک production سرور کریش ہوئے بغیر جواب دینا بند کر گیا، نہ out-of-memory kill، صرف swap کے بغیر مشین پر page-cache thrash۔ کیا ہوا اور ہم نے کیا بدلا۔
• Databases کو بغیر مردہ connections کے جگانا — نیند سے جاگنے والی published ایپ کا پہلا request 10 سے 12 سیکنڈ رکا رہا، کیونکہ سوتے وقت مر چکے database connections دوبارہ استعمال ہو رہے تھے۔ ہم نے اسے 2.3 سیکنڈ تک لایا۔
• ہم اپنی ہی سروسز کو rate limit کر رہے تھے — ہماری API کی فی پتہ rate limit نے ہماری اپنی سروسز کو ایک مصروف شخص سمجھا، اور production میں انہیں 429 ملنے لگے۔ ہم نے یہ کیسے پکڑا اور کیسے ٹھیک کیا۔
• ہم نے Mythex کے سرورز ARM پر کیوں منتقل کیے — بھاری کام فی project sandboxes میں منتقل ہونے کے بعد ہمارے سرورز اپنی memory کا ایک تہائی استعمال کر رہے تھے۔ چھوٹی ARM مشینوں نے لاگت تقریباً 30 فیصد کم کر دی۔ کیسے۔
• ہم نے deploys کو صفر 502 errors تک کیسے پہنچایا — ایک watchdog جو ہمارے deploys سے لڑتا تھا اور ایک load balancer جو دیر سے نوٹس کرتا تھا: ہم نے دونوں کو کیسے پکڑا، ٹھیک کیا، اور deploys کو 10 502s سے صفر تک ناپا۔