بڑی ورک اسپیسز کی طرف منتقلی، بغیر کسی کو انتظار کرائے

Mythex کے ہر پروجیکٹ کو اپنی ورک اسپیس ملتی ہے: ایک چھوٹا cloud کمپیوٹر جہاں ایجنٹ کوڈ لکھتا ہے اور آپ کی ایپ کا پریویو چلتا ہے۔ ہم نے نئی ورک اسپیسز کی memory 1 GB سے 2 GB کر دی تھی، مگر پرانی ورک اسپیسز 1 GB پر ہی رہیں؛ جس دن ہم نے دیکھا، ان کا تقریباً ایک چوتھائی حصہ۔ ہماری پہلی اصلاح نے پروجیکٹ کو اگلی بار کھولنے پر بڑی ورک اسپیس میں منتقل کیا۔ production میں اس کے پہلے دن نے ایک شخص کو سات منٹ انتظار کرایا۔ ہم نے اس پر سخت وقتی حد لگائی، پھر منتقلی کو پروجیکٹ کھولنے کے عمل سے ہی نکال دیا۔

پرانی ورک اسپیسز چھوٹی کیوں رہیں

ہمارا sandbox provider ورک اسپیس کا سائز اس کے بننے کے وقت طے کرتا ہے، اور ہر pause اور resume میں اسے برقرار رکھتا ہے۔ template بدلنے سے، یعنی وہ نسخہ جس سے نئی ورک اسپیسز بنتی ہیں، صرف بعد میں بننے والی ورک اسپیسز پر اثر ہوتا ہے۔ موجودہ کو کوئی ری سائز نہیں کرتا۔

یہ اہم تھا۔ ان میں سے ایک چھوٹی ورک اسپیس git push کے دوران memory ختم کر بیٹھی جب اس کا پریویو شروع ہو رہا تھا، اور 11 منٹ تک جواب دینا بند کر دیا۔ اسی کی وجہ سے ایک پبلش ناکام ہوئی۔

پہلی کوشش: جاگتے وقت پروجیکٹ منتقل کرنا

ورک اسپیسز جب کوئی استعمال نہ کرے تو رک جاتی ہیں، اور پروجیکٹ کھلنے پر جاگتی ہیں۔ جاگنا منتقلی کے لیے درست لمحہ لگا، کیونکہ اس وقت ابھی کوئی اس پر کام نہیں کر رہا ہوتا۔

منتقلی اس طرح کام کرتی تھی:

سائز چیک کریں۔ اگر ورک اسپیس 2 GB سے چھوٹی ہو تو منتقل کریں۔ اگر سائز معلوم نہ ہو تو کچھ نہ کریں۔
پبلش کو تنگ نہ کریں۔ پبلش ورک اسپیس کی فائلیں پڑھتی ہے، تو اگر کوئی پبلش چل رہی ہو تو منتقلی چھوڑ دیں۔
پروجیکٹ پیک کریں۔ پروجیکٹ کی ہر چیز archive کریں، جس میں اس کی git تاریخ بھی شامل ہے، یعنی ہر checkpoint جو پروجیکٹ کے پاس ہے، اور ایپ کی اپنی .env فائل، جو مالک کی ہے؛ مگر installed dependencies (node_modules) چھوڑ دیں، جنہیں دوبارہ انسٹال کیا جا سکتا ہے۔
سیدھا نقل کریں۔ archive کو پرانی ورک اسپیس سے ایک نئی 2 GB ورک اسپیس میں stream کریں، تاکہ وہ ہمارے اپنے سرور کی memory میں کبھی پورا نہ آئے۔
تبدیل کرنے سے پہلے موازنہ کریں۔ دونوں ورک اسپیسز میں فائلیں گنیں، آخری checkpoint پڑھیں، اور checkpoints گنیں۔ صرف تب بدلیں جب تینوں میل کھائیں۔
کسی بھی ناکامی پر پرانی رکھیں۔ کوئی بھی خرابی یا عدم مطابقت نئی ورک اسپیس کو ضائع کر دیتی ہے، اور پروجیکٹ پہلے کی طرح پرانی ورک اسپیس میں کھل جاتا ہے۔

موازنے کی ایک تفصیل اس سے زیادہ اہم نکلی جتنی نظر آتی ہے۔ یہ چیک administrator اکاؤنٹ کے طور پر چلتا ہے، اور git کسی ایسے repository کو پڑھنے سے انکار کرتا ہے جو کسی اور user کی ملکیت ہو۔ دونوں طرف اس نے کچھ نہ چھاپا، اور "کچھ نہیں" کا "کچھ نہیں" سے میل ہو گیا، تو چیک بغیر کسی history کا موازنہ کیے پاس ہو گیا۔ ہم نے git کو اس directory پر بھروسہ کرنے کو کہا، اور ایک test شامل کیا تاکہ یہ دوبارہ نہ ہو۔

پہلے دن کیا غلط ہوا

prod پر اپنے پہلے دن، ایک پروجیکٹ کو پیک کرتے ہوئے جاگنے کے اندر پانچ منٹ کی command timeout آ گئی۔ مالک کو اپنی ورک اسپیس کھلنے کے لیے سات منٹ انتظار کرنا پڑا۔ اور چونکہ منتقلی ناکام ہوئی تھی، پروجیکٹ اب بھی چھوٹا تھا، تو اگلی بار کھولنے پر پھر کوشش ہوتی اور انہیں پھر انتظار کرنا پڑتا۔

کسی کو اپنا پروجیکٹ کھولتے وقت انتظار کرانے والی منتقلی ایک بُرا سودا ہے۔ جاگنے پر منتقلی کرنے کا پورا مقصد یہ تھا کہ کسی کو محسوس نہ ہو۔

دوسری کوشش: سخت بجٹ

اسی دن ہم نے چار چیزیں بدلیں:

پوری منتقلی کے لیے ایک منٹ۔ ہر قدم، یعنی سائز چیک، پیکنگ، نئی ورک اسپیس بنانا، نقل، کھولنا اور موازنہ، ایک ہی 60 سیکنڈ کا بجٹ بانٹتے ہیں۔ جب وہ ختم ہو تو پروجیکٹ پرانی ورک اسپیس میں کھلتا ہے۔
صرف انتظار نہیں، کام بھی روکیں۔ ہماری طرف سے دینا کافی نہیں اگر archiving اب بھی اس ورک اسپیس کے اندر چل رہی ہو جسے مالک استعمال کرنے والا ہے۔ اب ہر archive command خود ورک اسپیس کے اندر بجٹ ختم ہونے سے تھوڑی دیر پہلے ختم کر دی جاتی ہے۔ اگر نئی ورک اسپیس ہمارے ہار ماننے کے بعد پہنچے تو اسے ضائع کر دیا جاتا ہے۔
مالک کو صفائی کا انتظار نہ کرائیں۔ عارضی archive کا حذف ہونا اب پس منظر میں ہوتا ہے۔
ہر کھولنے پر دوبارہ کوشش نہ کریں۔ جو پروجیکٹ منتقل نہ ہو سکا اسے 24 گھنٹے کے لیے چھوڑ دیا جاتا ہے، تاکہ ایک ناکامی پر زیادہ سے زیادہ دن میں ایک تاخیر ہو، ہر کھولنے پر ایک نہیں۔

تیسری کوشش: جاگنے کے عمل سے نکال دینا

اس سے بدترین صورت ایک منٹ تک آ گئی۔ مگر ایک منٹ بھی ایک منٹ ہے، اور ہم نے سمجھا کہ منتقلی کو کسی کے راستے میں ہونے کی ضرورت ہی نہیں۔

اب کوئی ورک اسپیس 1 GB پر نہیں بنتی۔ تو یہ کوئی جاری عمل نہیں، بلکہ طے شدہ ورک اسپیسز کی فہرست پر ایک بار کا کام ہے۔ اسے جاگنے کے اندر رکھنے کا مطلب تھا کہ ہر سست منتقلی کی قیمت ایک اصل شخص ادا کرے، اور ہمیں صرف یہی پتا چلتا کہ کوئی ورک اسپیس نہیں منتقل ہوئی جب کوئی ابھی اس کا انتظار کر رہا ہوتا۔

تو ہم نے منتقلی کو جاگنے سے مکمل طور پر ہٹا دیا۔ پروجیکٹ کھولنا پہلے کی طرح کام کرتا ہے۔ باقی چھوٹی ورک اسپیسز ایک نگرانی والے batch کے طور پر سنبھالی جاتی ہیں: کوئی انتظار نہیں کر رہا، اور جو ورک اسپیس منتقل نہ ہو وہ batch کی رپورٹ میں نظر آتی ہے، جسے ہم دیکھ سکتے ہیں، نہ کہ اس کے مالک کے سامنے۔

ہم نے اس سے کیا سیکھا

ری سائز ہمیشہ ممکن نہیں ہوتا۔ جب کوئی platform سائز بنانے کے وقت طے کر دے، تو ڈیفالٹ بڑھانے سے صرف نئی چیزوں کو فائدہ ہوتا ہے۔ پرانی چیزوں کے لیے منصوبہ بنائیں۔
"ابھی کسی نے استعمال نہیں کیا" کا مطلب پھر بھی ہے کہ کوئی انتظار کر رہا ہے۔ کسی product میں داخل ہونے کے راستے پر ہونے والا کام وہ کام ہے جسے ایک شخص دیکھ رہا ہوتا ہے۔
کسی بھی ایسی چیز پر وقتی بجٹ لگائیں جو صارف کے راستے میں ہو، اور بجٹ ختم ہونے پر کام روک دیں۔ اپنی طرف سے وقت ختم کرنا، جبکہ command کہیں اور چلتی رہے، صرف مسئلہ منتقل کرتا ہے۔
ایک بار کی منتقلی ایک بار کے job میں ہونی چاہیے۔ اسے روزمرہ کے کاموں میں چھپانا لکھنا آسان بناتا ہے، مگر چلانا مہنگا۔
اپنے safety checks کو جانچیں۔ ایک موازنہ جو کچھ موازنہ نہ کرے، بالکل اُس جیسا لگتا ہے جو پاس ہوا ہو۔

اگر آپ Mythex پر بناتے ہیں، تو کچھ کرنے کی ضرورت نہیں: مقصد صرف یہ ہے کہ کم ورک اسپیسز memory ختم ہوں، اور پروجیکٹ کھولنا پہلے جتنا تیز رہے۔ ورک اسپیسز کیسے رکتی اور جاگتی ہیں، یہ docs میں نجی ورک اسپیس کے تحت درج ہے۔ memory ختم ہونے کی ایک اور کہانی کے لیے، progress label میں چھپا out-of-memory crash دیکھیں۔