Att flytta till större arbetsytor utan att någon får vänta

Varje Mythex-projekt får sin egen arbetsyta: en liten molndator där agenten skriver kod och appens förhandsvisning körs. Vi hade höjt nya arbetsytor från 1 GB till 2 GB minne, men äldre arbetsytor låg kvar på 1 GB — vid tidpunkten vi kontrollerade var det ungefär en fjärdedel av dem. Vår första lösning flyttade ett projekt till en större arbetsyta när det öppnades nästa gång. Under dess första dag i produktion fick det en person att vänta i sju minuter. Vi satte en hård tidsgräns på flytten, och tog sedan bort den från att öppna ett projekt överhuvudtaget.

Varför gamla arbetsytor förblev små

Vår leverantör av sandlådor bestämmer en arbetsytas storlek när den skapas, och behåller den genom varje paus och återupptagning. Att ändra mallen — receptet nya arbetsytor byggs från — påverkar bara arbetsytor som skapas efter ändringen. Ingenting ändrar storlek på de som redan finns.

Det spelade roll. En av de små arbetsytorna slog slut på minne under en git push medan dess förhandsvisning startade, och slutade svara i 11 minuter. En publicering misslyckades på grund av det.

Första försöket: flytta projektet när det vaknar

Arbetsytor pausas när ingen använder dem och vaknar när projektet öppnas. Vakningen verkade vara rätt läge att flytta ett projekt, eftersom ingen arbetar i det ännu.

Flytten gick till så här:

1. Kontrollera storleken. Om arbetsytan är mindre än 2 GB, flytta den. Om storleken är okänd, gör ingenting.
2. Stör inte en publicering. En publicering läser arbetsytans filer, så om en pågår hoppar vi över flytten.
3. Packa projektet. Arkivera allt i projektet — inklusive dess git-historik, som är varje checkpoint projektet har, och appens egna .env-fil, som tillhör ägaren — men lämna kvar installerade beroenden (node_modules), som kan installeras om.
4. Kopiera direkt över. Strömma arkivet från den gamla arbetsytan till en ny på 2 GB, så att det aldrig behöver rymmas i vår egen servers minne.
5. Jämför innan du byter. Räkna filerna, läs den senaste checkpointen och räkna checkpointerna, i båda arbetsytorna. Byt bara om alla tre stämmer.
6. Behåll den gamla vid fel. Vid något fel eller någon avvikelse kastas den nya arbetsytan bort och projektet öppnas i den gamla, som förut.

En detalj i jämförelsen var viktigare än den verkar. Kontrollen körs som administratörskontot, och git vägrar läsa ett förråd som ägs av en annan användare. Den skrev ut ingenting på båda sidor — och ”ingenting” matchade ”ingenting”, så kontrollen godkändes utan att jämföra någon historik alls. Vi sa åt git att lita på katalogen, och lade till ett test så att det inte kan smyga sig tillbaka.

Vad som gick fel under första dagen

Under första dagen i produktion träffade packningen av ett projekt en tidsgräns på fem minuter för ett kommando — mitt i vakningen. Ägaren väntade i sju minuter innan arbetsytan öppnades. Och eftersom flytten hade misslyckats var projektet fortfarande litet, så nästa öppning skulle ha försökt igen och låtit dem vänta igen.

En migrering som får någon att vänta när de öppnar sitt eget projekt är en dålig affär. Hela poängen med att göra den vid vakning var att ingen skulle märka något.

Andra försöket: en hård budget

Samma dag ändrade vi fyra saker:

• En minut för hela flytten. Varje steg — kontrollera storleken, packa, skapa den nya arbetsytan, kopiera, packa upp, jämföra — delar på en enda budget på 60 sekunder. När den tar slut öppnas projektet i den gamla arbetsytan.
• Stoppa arbetet, inte bara väntan. Att ge upp på vår sida räcker inte om arkiveringen fortfarande körs inne i arbetsytan som ägaren snart ska använda. Varje arkiveringskommando dödas nu inne i arbetsytan strax innan budgeten tar slut. Om den nya arbetsytan kommer efter att vi gett upp kastas den bort.
• Låt inte ägaren vänta på städning. Borttagningen av det tillfälliga arkivet sker nu i bakgrunden.
• Försök inte igen vid varje öppning. Ett projekt som inte kunde flyttas lämnas ifred i 24 timmar, så att ett misslyckande kostar högst en fördröjning per dag, inte en per öppning.

Tredje försöket: ta bort den från vakningen

Det gjorde värsta fallet till en minut. Men en minut är fortfarande en minut, och vi insåg att flytten inte behövde ligga på någons väg alls.

Ingen arbetsyta skapas på 1 GB längre. Så det här är ingen pågående process; det är ett engångsjobb med en fast lista över arbetsytor. Att göra det inne i vakningen innebar att en verklig person fick betala för varje långsam flytt, och det enda sättet att få veta att en arbetsyta inte skulle flyttas var att någon just hade väntat på den.

Så vi tog bort flytten från vakningen helt. Att öppna ett projekt gör det det gjorde tidigare. De återstående små arbetsytorna hanteras i stället som en övervakad batch: ingen väntar på den, och en arbetsyta som inte kan flyttas syns i batchens rapport, där vi kan titta på den, i stället för framför ägaren.

Det vi lärde oss

• Att ändra storlek är inte alltid möjligt. När en plattform fixerar storleken vid skapandet hjälper det bara nya saker att höja standardvärdet. Planera för de gamla.
• ”Ingen använder den än” betyder fortfarande att någon väntar. Arbete som görs på vägen in i en produkt är arbete en person ser på.
• Sätt en budget på allt som ligger i en användares väg, och stoppa arbetet när budgeten tar slut. Att låta något tidsbegränsas på vår sida medan ett kommando fortsätter någon annanstans flyttar bara problemet.
• En engångsmigrering hör hemma i ett engångsjobb. Att gömma den i vardagliga handlingar gör den billigare att skriva och dyrare att köra.
• Testa dina säkerhetskontroller. En jämförelse som inte jämför något ser exakt likadan ut som en som godkändes.

Om du bygger på Mythex finns det inget att göra: målet är helt enkelt färre arbetsytor som slår slut på minne, med att öppna ett projekt lika snabbt som förut. Hur arbetsytor pausas och vaknar beskrivs i dokumentationen under privat arbetsyta. För en annan berättelse om slut på minne, se minnesläckan som gömde sig i en förloppsetikett.