कोणालाही न थांबवता मोठ्या वर्कस्पेसकडे स्थलांतर

प्रत्येक Mythex प्रोजेक्टला स्वतःचे वर्कस्पेस मिळते: एक छोटा क्लाउड संगणक, जिथे एजंट कोड लिहितो आणि तुमच्या ॲपचा प्रिव्ह्यू चालतो. आम्ही नवीन वर्कस्पेस 1 GB मेमरीवरून 2 GB पर्यंत वाढवले होते, पण जुने वर्कस्पेस 1 GB वरच राहिले. आम्ही तपासले त्या दिवशी, त्यापैकी सुमारे एक चतुर्थांश. आमच्या पहिल्या उपायाने पुढच्या वेळी प्रोजेक्ट उघडला जाईल तेव्हा त्याला मोठ्या वर्कस्पेसमध्ये हलवले. प्रॉडक्शनमधील पहिल्याच दिवशी त्यामुळे एका व्यक्तीला सात मिनिटे थांबावे लागले. आम्ही त्याला कठोर वेळ मर्यादा दिली, आणि मग ते हलवणे प्रोजेक्ट उघडण्याच्या प्रक्रियेपासूनच वेगळे केले.

जुने वर्कस्पेस लहान का राहिले

आमचा सँडबॉक्स प्रदाता वर्कस्पेसचा आकार ते तयार होतानाच ठरवतो, आणि प्रत्येक थांबणे आणि पुन्हा सुरू होणे यातून तो आकार कायम ठेवतो. नवीन वर्कस्पेस ज्या टेम्प्लेटवरून बनतात तो टेम्प्लेट बदलल्यास, बदलानंतर बनलेल्या वर्कस्पेसवरच परिणाम होतो. जे आधीपासून अस्तित्वात आहेत त्यांचा आकार कोणीही बदलत नाही.

ते महत्त्वाचे होते. एका लहान वर्कस्पेसची मेमरी git push दरम्यान संपली, त्याच वेळी त्याचा प्रिव्ह्यू सुरू होत होता, आणि ते 11 मिनिटे प्रतिसाद देईनासे झाले. त्यामुळे एक प्रकाशन अयशस्वी झाले.

पहिला प्रयत्न: जागे झाल्यावर प्रोजेक्ट हलवा

कोणी वापरत नसताना वर्कस्पेस थांबतात आणि प्रोजेक्ट उघडल्यावर जागे होतात. जागे होणे हा प्रोजेक्ट हलवण्याचा योग्य क्षण वाटला, कारण तेव्हा त्यावर अजून कोणी काम करत नसते.

हलवण्याची पद्धत अशी होती:

1. आकार तपासा. वर्कस्पेस 2 GB पेक्षा लहान असेल तर हलवा. आकार माहीत नसेल तर काहीही करू नका.
2. प्रकाशनात अडथळा आणू नका. प्रकाशन वर्कस्पेसच्या फाइल्स वाचते, त्यामुळे ते चालू असेल तर हलवणे वगळा.
3. प्रोजेक्ट पॅक करा. प्रोजेक्टमधील सर्व काही संग्रहित करा, त्यात git इतिहास, म्हणजे प्रोजेक्टचा प्रत्येक चेकपॉइंट, आणि ॲपची स्वतःची .env फाइल, जी मालकाची आहे. पण इन्स्टॉल केलेले डिपेंडन्सीज (node_modules) वगळा, कारण ते पुन्हा इन्स्टॉल करता येतात.
4. थेट पलीकडे कॉपी करा. जुन्या वर्कस्पेसमधून संग्रह एका नव्या 2 GB वर्कस्पेसमध्ये स्ट्रीम करा, त्यामुळे तो कधीच आमच्या स्वतःच्या सर्व्हरच्या मेमरीत बसावा लागत नाही.
5. बदलण्याआधी तुलना करा. दोन्ही वर्कस्पेसमध्ये फाइल्सची संख्या, नवीनतम चेकपॉइंट, आणि चेकपॉइंट्सची संख्या मोजा. तिन्ही जुळले तरच बदला.
6. कोणत्याही अपयशावर जुने ठेवा. कोणतीही एरर किंवा जुळत नसलेले मूल्य आले, तर नवीन वर्कस्पेस फेकून दिले जाते आणि प्रोजेक्ट पूर्वीप्रमाणे जुन्या वर्कस्पेसमध्ये उघडते.

तुलनेतील एक तपशील यापेक्षा जास्त महत्त्वाचा होता. ही तपासणी ॲडमिनिस्ट्रेटर खात्याखाली चालते, आणि git दुसऱ्या वापरकर्त्याच्या मालकीची रिपॉझिटरी वाचायला नकार देतो. दोन्ही बाजूंनी ते काहीच छापत नव्हते, आणि “काहीच नाही” हे “काहीच नाही”शी जुळले, त्यामुळे तपासणी प्रत्यक्षात कोणताही इतिहास न तपासता पास झाली. आम्ही git ला त्या डिरेक्टरीवर विश्वास ठेवायला सांगितले, आणि तो परत येऊ नये म्हणून एक चाचणी जोडली.

पहिल्या दिवशी काय चुकले

प्रॉडक्शनमधील पहिल्याच दिवशी, एका प्रोजेक्टचे पॅकिंग जागे होण्याच्या आत पाच मिनिटांच्या कमांड टाइमआउटला भिडले. मालकाला त्यांचे वर्कस्पेस उघडण्यासाठी सात मिनिटे थांबावे लागले. आणि स्थलांतर अयशस्वी झाल्यामुळे प्रोजेक्ट अजूनही लहान होता, त्यामुळे पुढची उघडणी पुन्हा प्रयत्न करून त्यांना पुन्हा थांबवली असती.

ज्या स्थलांतरामुळे स्वतःच्या प्रोजेक्टला उघडताना कोणाला थांबावे लागते ते वाईट व्यवहार आहे. जागे होताना ते करण्याचा सगळा मुद्दा हाच होता की कोणाच्याच लक्षात येणार नाही.

दुसरा प्रयत्न: कठोर बजेट

त्याच दिवशी आम्ही चार गोष्टी बदलल्या:

• संपूर्ण स्थलांतरासाठी एक मिनिट. प्रत्येक पायरी, आकार तपासणे, पॅक करणे, नवीन वर्कस्पेस तयार करणे, कॉपी करणे, अनपॅक करणे, तुलना करणे, यांना एकच 60 सेकंदांचे बजेट आहे. ते संपले की प्रोजेक्ट जुन्या वर्कस्पेसमध्ये उघडते.
• फक्त वाट पाहणे नाही, काम थांबवा. आमच्या बाजूने देणे सोडणे पुरेसे नाही, जर मालक वापरणार असलेल्या वर्कस्पेसमध्ये संग्रहण अजूनही चालू असेल. प्रत्येक आर्काइव्ह कमांड आता बजेट संपण्याच्या थोडे आधी वर्कस्पेसच्या आतच मारली जाते. आम्ही सोडून दिल्यानंतर नवीन वर्कस्पेस आले, तर ते फेकून दिले जाते.
• मालकाला साफसफाईसाठी थांबवू नका. तात्पुरता संग्रह हटवणे आता पार्श्वभूमीत होते.
• प्रत्येक उघडणीला पुन्हा प्रयत्न करू नका. जो प्रोजेक्ट हलवता आला नाही, तो 24 तास सोडून दिला जातो, त्यामुळे अपयशामुळे दिवसाला जास्तीत जास्त एकदाच विलंब होतो, प्रत्येक उघडणीला नव्हे.

तिसरा प्रयत्न: ते जागे होण्यातून काढा

यामुळे सर्वात वाईट केस एक मिनिट झाली. पण एक मिनिटही मिनिट असतेच, आणि आम्हाला लक्षात आले की हे स्थलांतर कोणाच्याच मार्गात असण्याची गरज नाही.

आता 1 GB वर कोणतेही वर्कस्पेस तयार होत नाही. त्यामुळे ही सतत चालणारी प्रक्रिया नाही; ती निश्चित वर्कस्पेसच्या यादीसह एकवेळचे काम आहे. जागे होण्याच्या आत ते केल्याने प्रत्येक संथ स्थलांतराची किंमत एक खरी व्यक्ती देत होती, आणि एखादे वर्कस्पेस हलणार नाही हे आम्हाला फक्त तेव्हाच कळत होते जेव्हा कोणीतरी नुकतीच त्याची वाट पाहिली होती.

त्यामुळे आम्ही स्थलांतर जागे होण्यातूनच पूर्णपणे काढून टाकले. प्रोजेक्ट उघडताना पूर्वीसारखेच होते. उरलेली लहान वर्कस्पेस एका देखरेखीखालील बॅचप्रमाणे हाताळली जातात: त्यासाठी कोणीही थांबत नाही, आणि जे वर्कस्पेस हलत नाही ते बॅचच्या अहवालात दिसते, जिथे आम्ही त्याची तपासणी करू शकतो, त्याच्या मालकाच्या समोर नव्हे.

आम्ही यातून काय शिकलो

• आकार बदलणे नेहमी शक्य नसते. प्लॅटफॉर्म तयार होतानाच आकार निश्चित करत असेल, तर डिफॉल्ट वाढवल्याने फक्त नवीन गोष्टींना मदत होते. जुन्यांसाठी नियोजन करा.
• “अजून कोणी वापरत नाही” म्हणजे अजूनही कोणीतरी वाट पाहत आहे. उत्पादनात प्रवेश करताना केलेले काम म्हणजे माणूस पाहत असलेले काम.
• वापरकर्त्याच्या मार्गातील कोणत्याही कामाला बजेट द्या, आणि ते बजेट संपले की काम थांबवा. आमच्या बाजूने टाइमआउट होत असताना कमांड दुसरीकडे चालू राहिली, तर समस्या फक्त हलते.
• एकवेळच्या स्थलांतराला एकवेळच्या जॉबमध्ये ठेवा. ते रोजच्या कृतींमध्ये लपवल्याने लिहायला स्वस्त पडते, पण चालवायला महाग.
• तुमच्या सुरक्षा तपासण्यांची चाचणी करा. काहीही तुलना न करणारी तुलना, तुलना यशस्वी झालेल्या तुलनेसारखीच दिसते.

Mythex वर बिल्ड करत असाल तर काहीही करायची गरज नाही: उद्देश फक्त असा आहे की वर्कस्पेसमध्ये मेमरी संपण्याच्या घटना कमी व्हाव्यात, आणि प्रोजेक्ट उघडण्याचा वेग पूर्वीइतकाच राहावा. वर्कस्पेस कसे थांबतात आणि जागे होतात हे डॉक्समध्ये खासगी वर्कस्पेस अंतर्गत आहे. आणखी एका out-of-memory कथेसाठी, प्रोग्रेस लेबलमध्ये लपलेला out-of-memory क्रॅश पाहा.