பொறியியல்

பொறியியல்

Mythex எப்படி உருவாக்கப்பட்டு இயக்கப்படுகிறது — எது உடைந்தது, எப்படிச் சரிசெய்தோம் என்பது உட்பட.

• தோல்வியடைந்த மறுவெளியீடு வேலை செய்யும் பின்தளத்தை ஒருபோதும் நீக்காது — தோல்வியடைந்த மறுவெளியீடு ஆப்பின் நேரடி API-ஐ நீக்கலாம். Mythex தவறான வெளியீட்டைத் திரும்பப் பெறும் விதத்தில் மூன்று திருத்தங்கள்.
• ஒவ்வொரு சர்வருக்கும் ஒருமுறை அல்ல, ஒருமுறை மட்டுமே ஒலிக்கும் எச்சரிக்கைகள் — ஒரு நாளுக்கு ஒருமுறை வர வேண்டிய எச்சரிக்கை ஐந்து முறை வந்தது. இரண்டு சர்வர்களும் deploy-உம் இருந்தபோது நினைவக dedupe ஏன் தோல்வியடைந்தது.
• யாரையும் காத்திருக்க வைக்காமல் பெரிய பணியிடங்களுக்கு மாறுதல் — 2 GB-க்கு மாறிய பிறகு பணியிடங்களில் கால் பகுதி 1 GB-இலேயே இருந்தது. எங்கள் முதல் திருத்தம் ஒருவரை ஏழு நிமிடம் காத்திருக்க வைத்தது.
• உண்மையில் பயன்படுத்துவதன் அடிப்படையில் டேட்டாபேஸ்களுக்கு பில்லிங் — டேட்டாபேஸ் செலவை நாங்கள் மதிப்பிட்டு வந்தோம்; அது தவறாக இருந்தது. இப்போது அளக்கப்பட்ட பயன்பாட்டின் அடிப்படையில், மணி நேரம் மணி நேரமாக பில் செய்யப்படுகிறது.
• வெளியிட்ட உடனே செயலிழக்கும் ஆப்புகளைப் பிடித்தல் — மூன்று வெளியீடுகள் ஆரோக்கியச் சோதனையைக் கடந்தன, ஆனால் ஒவ்வொரு துவக்கத்திலும் API செயலிழந்தது. காரணம்: ஐந்து உள்ளீடுகள் மட்டுமே கொண்ட பட்டியலில் எண்ணிக்கை.
• படங்கள் நிறைந்த agent turns நினைவகத்துக்குள் வைத்திருத்தல் — Catalogue scans பார்த்த agent turn 952 MB-இல் memory தீர்ந்தது. மூன்று தனித்தனி காரணங்கள், அவற்றை எப்படிச் சரிசெய்தோம்.
• நீண்ட agent turns-ஐ context window-க்குள் வைத்திருத்தல் — Sub-agents மாதிரி மறுக்கும் அளவுக்கு வளர்ந்தன, ரஷ்ய tokens தவறாக எண்ணப்பட்டன. நீண்ட AI வேலை முடிய உதவிய மூன்று திருத்தங்கள்.
• தொலைபேசி தூங்கும்போது chat-ஐ உயிருடன் வைத்திருத்தல் — தொலைபேசி தூங்கும்போதும் tab மாறும்போதும் chat தேங்காமலும் பாதி பதிலைக் காட்டாமலும் இருக்க இரண்டு பிழைகளைச் சரிசெய்தோம்.
• ஒரு கனமான chat எங்கள் API-ஐ எப்படி செயலிழக்கச் செய்திருக்கக்கூடும் — செப்டம்பர் 28 அன்று இரண்டு API சேவையகங்களும் ஒரே நேரத்தில் memory தீர்ந்தன. உண்மையான சரிசெய்தல்: chat வரலாற்றை அளவால் ஏற்றுவது.
• Publish-ஐ இருமுறை அழுத்தினால் இப்போது ஒருமுறை மட்டுமே publish ஆகும் — ஒரே app-க்கான மூன்று publish கோரிக்கைகள் 84 ms-இல் வந்து மூன்று deploy-களைத் தொடங்கின. இப்போது database ஒன்றை மட்டுமே அனுமதிக்கிறது.
• எங்கள் சொந்த தளத்தை சரிசெய்தபோது கற்ற SEO பாடங்கள் — நகல் FAQ markup, Google-இல் தவறான thumbnail, யாரும் கிளிக் செய்யாத template பக்கங்கள், எங்கள் edge மறுத்த ஒரு பாதை: mythex.ai-இல் நாங்கள் கண்டு சரிசெய்தவை.
• Static தளங்கள் மறுவெளியிடும்போதும் இயங்கிக் கொண்டிருக்கும் — Static தளத்தை மறுவெளியிடுவது முன்பு தளத்தைக் காலியாக்கியது. இப்போது புதிய பதிப்பு தயாராகும் வரை பழையது வழங்கப்படும். மாற்றங்கள் சில நொடிகளில் தெரியும்.
• ஒரு progress label-இல் மறைந்திருந்த நினைவகப் பற்றாக்குறை செயலிழப்பு — எங்கள் AI ஏஜென்ட் ஒரு பெரிய கோப்பை எழுதும்போது நினைவகம் தீர்ந்தது. காரணம் மாடலோ இணையான துணை ஏஜென்ட்களோ அல்ல. 41,000 முறை மீண்டும் அனுப்பப்பட்ட ஒரு status label.
• எங்கள் சர்வர்களை உறையச் செய்த காணாமல் போன swap கோப்பு — ஒரு production சர்வர் செயலிழக்காமலேயே பதில் சொல்வதை நிறுத்தியது. swap இல்லாத பெட்டியில் page-cache thrash. என்ன நடந்தது, நாங்கள் என்ன மாற்றினோம்.
• இறந்த இணைப்புகள் இல்லாமல் தரவுத்தளங்களை எழுப்புதல் — தூக்கத்திலிருந்து எழுந்த ஆப் இறந்த தரவுத்தள இணைப்புகளில் முதல் கோரிக்கையை 10–12 வினாடிகள் வைத்திருந்தது. அதை 2.3 வினாடிகளுக்குக் குறைத்தது எப்படி.
• நாங்களே எங்கள் சொந்த சேவைகளை rate-limit செய்துகொண்டிருந்தோம் — எங்கள் API-இன் ஒவ்வொரு முகவரிக்குமான rate limit, எங்கள் சொந்த சேவைகளை ஒரு பிஸியான நபரைப் போல நடத்தியது. production-இல் அவை 429 பெறத் தொடங்கின. அதைக் கண்டு சரிசெய்தது எப்படி.
• Mythex-இன் சர்வர்களை ARM-க்கு மாற்றியது ஏன் — கனமான வேலை sandbox-களுக்கு மாறியதும், எங்கள் சர்வர்கள் நினைவகத்தில் மூன்றில் ஒரு பங்கை மட்டுமே பயன்படுத்தின. சிறிய ARM instances செலவை சுமார் 30% குறைத்தன.
• எங்கள் deploy-களை பூஜ்ஜிய 502 பிழைகளுக்குக் கொண்டுவந்தது எப்படி — எங்கள் deploy-களுடன் போட்டியிட்ட ஒரு watchdog, தாமதமாகக் கவனித்த ஒரு load balancer. இரண்டையும் சரிசெய்து deploy-களை 10 502 பிழைகளிலிருந்து பூஜ்ஜியத்துக்குக் குறைத்தோம்.