Tekniikka

Tekniikka

Miten Mythex rakennetaan ja miten sitä ajetaan – myös se, mikä hajosi ja miten se korjattiin.

• Epäonnistunut uudelleenjulkaisu ei koskaan poista toimivaa taustapalvelua — Epäonnistunut uudelleenjulkaisu voi poistaa sovelluksen toimivan API:n tai jättää rikkinäisen version käyntiin. Kolme korjausta julkaisun peruutukseen.
• Hälytykset, jotka laukeavat kerran, eivät kerran palvelinta kohden — Kerran päivässä lähtevä hälytys tuli meille viidesti yhden iltapäivän aikana. Miksi muistissa tapahtuva deduplikointi hajoaa kahdella palvelimella ja deployn kanssa.
• Isompiin työtiloihin siirtyminen ilman, että kukaan joutuu odottamaan — Neljännes työtiloista jäi 1 Gt:n kokoon 2 Gt:n siirtymän jälkeen. Ensimmäinen korjaus pakotti yhden ihmisen odottamaan seitsemän minuuttia. Mitä muutimme.
• Tietokantojen laskutus sen mukaan, mitä ne oikeasti käyttävät — Arvioimme aiemmin tietokantakustannukset, ja arvio oli väärä molempiin suuntiin. Nyt jokainen tietokanta laskutetaan mitatun käytön mukaan tunti kerrallaan.
• Sovellusten kaatumisten kiinni saaminen heti julkaisun jälkeen — Kolme julkaisua läpäisi terveystarkistuksen, vaikka niiden API kaatui sekunteja jokaisen käynnistyksen jälkeen. Syy: kaatumisia laskettiin viiden merkinnän listasta.
• Kuvapainotteiset agenttivuorot muistin rajoissa — Agenttivuoro, joka katseli tuotekuvastoskannauksia, loppui muistista 952 megatavussa. Kolme erillistä syytä piti kuvia liian kauan, ja näin korjasimme ne.
• Pitkät agenttivuorot konteksti-ikkunan sisällä — Aliagenttimme kasvoivat, kunnes malli kieltäytyi, pysähtyivät säästääkseen tilaa tai laskivat tokenit väärin. Kolme korjausta pitkälle työlle.
• Chatin pitäminen hengissä, kun puhelin nukkuu — Puhelimet menevät lepotilaan ja vaihtavat verkkoa. Kaksi virhettä jätti chatin jumiin tai näytti puolikkaan vastauksen. Näin korjasimme ne.
• Yksi raskas chat voisi kaataa koko API:n — Syyskuun 28. päivänä molemmat API-palvelimet loppuivat muistista samaan aikaan. Oikea korjaus: chat-historia ladataan kokorajan mukaan.
• Julkaisun painaminen kahdesti julkaisee nyt kerran — Kolme julkaisupyyntöä samalle sovellukselle käynnisti kolme täyttä julkaisua. Tietokanta päättää nyt, mikä pyyntö voittaa.
• SEO-opit oman sivustomme korjaamisesta — Kaksinkertaiset FAQ-merkinnät, väärä pikkukuva Googlessa, mallisivut ilman vastauksia ja hylätty reitti. Mitä löysimme mythex.ai-sivustolta ja korjasimme.
• Staattiset sivustot pysyvät pystyssä, kun ne julkaistaan uudelleen — Staattisen sivuston uudelleenjulkaisu tyhjensi sivuston ensin. Nyt vanha sivusto palvelee, kunnes uusi on valmis, ja muutokset näkyvät sekunneissa.
• Muistin loppumisen virhe edistymisnäytön tekstissä — Agentti loppui muistista suuren tiedoston kirjoittamisen aikana. Syy ei ollut malli eikä aliagentit, vaan tilarivi, joka lähetettiin 41 000 kertaa.
• Puuttuva swap-tiedosto, joka jäädytti palvelimemme — Tuotantopalvelin lakkasi vastaamasta kaatumatta: ei muistin loppumista, vain sivumuistin jatkuvaa vaihtoa koneessa ilman swapia. Mitä tapahtui ja mitä muutimme.
• Tietokantojen herättäminen ilman kuolleita yhteyksiä — Julkaistu sovellus, joka heräsi unesta, piti ensimmäisen pyynnön 10–12 sekuntia kuolleilla tietokantayhteyksillä. Miten saimme sen 2,3 sekuntiin.
• Rajoitimme omia palveluitamme — API:n osoitekohtainen nopeusraja kohteli omia palveluitamme kuin yhtä kiireistä ihmistä, ja tuotannossa ne alkoivat saada 429-virheitä. Miten löysimme ja korjasimme sen.
• Miksi siirsimme Mythexin palvelimet ARM-prosessoreihin — Raskaan työn siirryttyä sandboxeihin palvelimet käyttivät kolmasosan muististaan. Pienemmät ARM-instanssit leikkasivat palvelinlaskua noin 30 %.
• Miten saimme käyttöönotot nollaan 502-virhettä — Valvontakoira kilpaili käyttöönottojen kanssa, ja kuormantasaaja huomasi liian myöhään. Miten korjasimme molemmat ja saimme 502-virheet nollaan.