इंजिनिअरिंग

इंजिनिअरिंग

Mythex कसे बनवले आणि चालवले जाते, काय बिघडले आणि ते कसे दुरुस्त केले त्यासह.

• अयशस्वी रीपब्लिशमुळे कार्यरत बॅकएंड कधीच हटवला जात नाही — अयशस्वी रीपब्लिशमुळे ॲपचा लाइव्ह API हटवला जाऊ शकत होता, किंवा चुकीची नवीन आवृत्ती चालू राहू शकत होती. प्रकाशन चुकल्यावर Mythex ते कसे परत करते त्यातील तीन सुधारणा.
• प्रत्येक सर्व्हरसाठी नव्हे, एकदाच वाजणारे अलर्ट — दिवसातून एकदा येणारा अलर्ट एका दुपारी पाच वेळा आला. दोन सर्व्हर आणि डिप्लॉयसह मेमरीमधील डिडुप्लिकेशन का तुटते, आणि शेअर्ड स्टेटने ते कसे दुरुस्त केले.
• कोणालाही न थांबवता मोठ्या वर्कस्पेसकडे स्थलांतर — 2 GB कडे गेल्यानंतरही सुमारे एक चतुर्थांश वर्कस्पेस 1 GB वरच होते. पहिल्या उपायाने एका व्यक्तीला सात मिनिटे थांबवले. आम्ही काय बदलले ते.
• डेटाबेस बिलिंग त्यांच्या खऱ्या वापरानुसार — पूर्वी आम्ही प्रत्येक ॲपच्या डेटाबेस खर्चाचा अंदाज बांधत होतो, आणि तो दोन्ही बाजूंनी चुकीचा होता. आता प्रत्येक डेटाबेसचे बिल मोजलेल्या वापरावरून, तास-तासाने होते.
• प्रकाशनानंतर लगेच क्रॅश होणारे ॲप्स पकडणे — तीन प्रकाशने आमच्या हेल्थ चेकमधून गेली, तरी त्यांचा API प्रत्येक बूटच्या काही सेकंदांत क्रॅश होत होता. कारण: पाच नोंदींच्या यादीत क्रॅश मोजणे.
• इमेज-भरलेल्या एजंट टर्न्स मेमरीमध्ये राखणे — कॅटलॉग स्कॅन पाहत राहिलेल्या एजंट टर्नची मेमरी 952 MB वर संपली. तीन वेगळी कारणे, प्रत्येकाने इमेजेस खूप वेळ धरून ठेवल्या, आणि आम्ही ती कशी दुरुस्त केली.
• लांब एजंट टर्न्स context window मध्ये ठेवणे — आमचे sub-agents इतके वाढू शकत होते की मॉडेल त्यांना नाकारायचे, खोली वाचवायला लवकर थांबायचे, किंवा रशियनमधील tokens चुकीचे मोजायचे. लांब AI काम पूर्ण होण्यासाठी तीन दुरुस्त्या.
• फोन झोपल्यावरही चॅट जिवंत ठेवणे — फोन झोपतात, tab बदलतात आणि build मध्येच नेटवर्क गमावतात. दोन bugs मुळे चॅट अडकायचे किंवा नंतर अर्धे उत्तर दाखवायचे. ते कसे सापडले आणि कसे दुरुस्त झाले.
• एक जड चॅट आमचा API कसा खाली पाडू शकत होता — 28 सप्टेंबरला आमचे दोन्ही API सर्व्हर एकाच वेळी मेमरीबाहेर गेले. पहिली दुरुस्ती अधिक मेमरी होती; खरी दुरुस्ती संख्येऐवजी आकारावरून चॅट इतिहास लोड करणे ही होती.
• Publish दोनदा दाबल्यास आता एकदाच publish होते — एकाच अ‍ॅपसाठी तीन publish requests 84ms अंतराने आल्या आणि प्रत्येकाने पूर्ण deploy चालवला. Database ने कोण publish करेल हे कसे ठरवले, आणि इतरांना सत्य कसे सांगितले.
• स्वतःची साइट दुरुस्त करताना मिळालेले SEO धडे — डुप्लिकेट FAQ markup, Google मधील चुकीचा थंबनेल, न क्लिक झालेली टेम्प्लेट पाने आणि edge ने नाकारलेला मार्ग: mythex.ai वर आम्हाला काय सापडले ते.
• स्टॅटिक साइट्स पुन्हा प्रकाशित होत असतानाही सुरू राहतात — स्टॅटिक साइट पुन्हा प्रकाशित करताना आधी जुन्या फाइल्स हटवल्या जात होत्या. आता नवा build येईपर्यंत जुनी साइट चालू राहते आणि बदल काही सेकंदात दिसतात.
• प्रोग्रेस लेबलमध्ये लपलेला Out-of-Memory क्रॅश — आमचा AI agent एक मोठी फाइल लिहिताना out-of-memory ने क्रॅश झाला. कारण model किंवा sub-agents नव्हते, तर एक status लेबल 41,000 वेळा पुन्हा पाठवले जात होते.
• गायब झालेली swap फाइल ज्यामुळे आमचे सर्व्हर गोठले — swap नसल्यामुळे production सर्व्हर crash न होता उत्तर देणे थांबवत होता. काय झाले आणि आम्ही काय बदलले ते.
• मृत कनेक्शनशिवाय जागे होणारे डेटाबेस — झोपेतून जागा होणारा ॲप पहिली विनंती 10–12 सेकंद धरत होता, कारण झोपेत मृत झालेले database कनेक्शन वापरले जात होते. ते 2.3 सेकंदांवर कसे आणले.
• आम्ही स्वतःच्या सेवांवर rate limit लावत होतो — API ची प्रति-पत्ता rate limit स्वतःच्या सेवांनाही एका व्यस्त व्यक्तीसारखे वागवत होती आणि production मध्ये त्यांना 429 मिळत होते. आम्ही ते कसे दुरुस्त केले.
• आम्ही Mythex चे सर्व्हर ARM वर का हलवले — heavy काम sandboxes मध्ये गेल्यावर सर्व्हरची मेमरी एक तृतीयांश वापरली जात होती. लहान ARM इन्स्टन्सेसमुळे खर्चात सुमारे 30% बचत झाली. ते कसे.
• डिप्लॉय दरम्यान शून्य 502 errors कसे मिळवले — Watchdog deploys शी भांडत होता आणि load balancer ने उशिरा लक्षात घेतले. दोन्ही समस्या कशा दुरुस्त केल्या आणि deploys 10 502s वरून शून्यावर कसे आणले.