Teknik

Teknik

Hur Mythex byggs och drivs, inklusive vad som gick sönder och hur vi lagade det.

• En misslyckad publicering raderar aldrig en fungerande backend — En misslyckad omdeploy kunde radera en apps live-API eller lämna en trasig ny version igång. Tre rättelser i hur Mythex ångrar en publicering som går fel.
• Larm som går av en gång, inte en gång per server — Ett dagligt larm nådde oss fem gånger en eftermiddag. Varför dedupe i minnet bryter med två servrar och en deploy, och hur delat tillstånd löste det.
• Att flytta till större arbetsytor utan att någon får vänta — En fjärdedel av våra arbetsytor fastnade på 1 GB efter att vi gick över till 2 GB. Vår första lösning fick en person att vänta i sju minuter. Vad vi ändrade, och ändrade igen.
• Fakturera databaser efter vad de faktiskt använder — Vi brukade uppskatta varje apps databaskostnad, och uppskattningen var fel åt båda hållen. Nu faktureras varje databas utifrån uppmätt användning, timme för timme.
• Att fånga appar som kraschar direkt efter publicering — Tre publiceringar klarade vår hälsokontroll trots att deras API kraschade några sekunder in i varje start. Orsaken: vi räknade krascher i en lista med högst fem poster.
• Håll bildtunga agentturer inom minnesgränsen — En agenttur som hela tiden tittade på katalogskanningar slog i minnestaket vid 952 MB. Tre separata orsaker höll bilder för länge, och så fixade vi dem.
• Håll långa agentturer inom kontextfönstret — Underagenter kunde växa tills modellen vägrade dem, stanna för att spara plats eller felräkna ryska tokens. Tre fixar som låter långt AI-arbete bli klart.
• Håll chatten igång när en telefon somnar — Telefoner somnar, byter flik och tappar nätet mitt i ett bygge. Två buggar fick chatten att fastna eller visa halva svaret. Så hittade och fixade vi dem.
• Hur en tung chatt kunde ha slagit ut vårt API — Den 28 september tog minnet slut på båda våra API-servrar samtidigt. Första åtgärden var mer minne; den riktiga var att läsa in chatthistoriken efter storlek, inte antal.
• Att trycka på Publish två gånger publicerar nu bara en gång — Tre publiceringar av samma app kom 84 ms från varandra och startade tre deployer. Databasen avgör nu vem som publicerar, och de andra får veta sanningen.
• SEO-lärdomar från när vi fixade vår egen webbplats — Dubbel FAQ-markering, fel miniatyrbild i Google, mallsidor ingen klickade på och en sökväg vår edge nekade: vad vi hittade på mythex.ai och fixade.
• Statiska webbplatser förblir uppe under ompublicering — Ompublicering av en statisk webbplats tömde sidan innan uppladdningen. Nu visas den gamla versionen tills den nya är klar, och ändringar syns på sekunder.
• Krashen av slut på minne som gömde sig i en förloppsetikett — Vår AI-agent fick slut på minne vid en stor fil. Orsaken var varken modellen eller underagenter, utan en statusetikett som skickades 41 000 gånger.
• Swap-filen som saknades och fick våra servrar att frysa — En produktionsserver slutade svara utan att krascha: ingen out-of-memory-död, bara page cache-trashing på en maskin utan swap. Vad som hände och vad vi ändrade.
• Att väcka databaser utan döda anslutningar — En publicerad app som vaknade från viloläge höll sin första förfrågan i 10–12 sekunder på databasanslutningar som dog medan den sov. Så fick vi ner det till 2,3 sekunder.
• Vi begränsade våra egna tjänster — Vårt API:s gräns per nätverksadress behandlade våra egna tjänster som en enda upptagen person, och i produktion började de få 429:or. Så hittade vi felet och löste det.
• Varför vi flyttade Mythex servrar till ARM — Efter att tung arbetsbelastning flyttade till sandlådor låg våra servrar på en tredjedel av minnet. Mindre ARM-instanser sänkte kostnaden med cirka 30 %.
• Så fick vi deployerna ner till noll 502-fel — En watchdog som kolliderade med deployer och en lastbalanserare som reagerade för sent. Vi åtgärdade båda och fick ner 502:or från tio till noll.