Selitev na večje delovne prostore brez čakanja

Vsak projekt Mythex dobi svoj delovni prostor: majhen oblačni računalnik, na katerem agent piše kodo in teče predogled vaše aplikacije. Nove delovne prostore smo povečali z 1 GB pomnilnika na 2 GB, stari pa so ostali pri 1 GB – ob pregledu jih je bila približno četrtina. Naš prvi popravek je projekt premaknil v večji delovni prostor, ko so ga naslednjič odprli. Na prvi dan v produkciji je to enega uporabnika stalo sedem minut čakanja. Nato smo premik omejili s trdno časovno mejo, na koncu pa ga sploh odstranili iz odpiranja projekta.

Zakaj so stari delovni prostori ostali majhni

Naš ponudnik peskovnikov nastavi velikost delovnega prostora ob ustvarjanju in jo ohrani skozi vsako zaustavitev in nadaljevanje. Sprememba predloge – recepta, po katerem se gradijo novi delovni prostori – vpliva samo na delovne prostore, ustvarjene po spremembi. Obstoječih nihče ne preoblikuje.

To je bilo pomembno. Eden od majhnih delovnih prostorov je med git push zmanjkal pomnilnika, medtem ko se je predogled zaganjal, in 11 minut ni odzival. Zaradi tega objava ni uspela.

Prvi poskus: premakni projekt ob prebujanju

Delovni prostori se ustavijo, ko jih nihče ne uporablja, in prebudijo, ko se projekt odpre. Prebujanje se je zdelo pravi trenutek za premik projekta, ker v njem še nihče ne dela.

Premik je deloval tako:

1. Preveri velikost. Če je delovni prostor manjši od 2 GB, ga premakni. Če je velikost neznana, ne naredi nič.
2. Ne moti objave. Objava bere datoteke delovnega prostora, zato je premik preskočen, če teče.
3. Zapakiraj projekt. Arhiviraj vse v projektu – vključno z git zgodovino, to je vsemi kontrolnimi točkami projekta, in datoteko .env aplikacije, ki pripada lastniku – vendar izpusti nameščene odvisnosti (node_modules), ki jih je mogoče znova namestiti.
4. Prenesi neposredno. Arhiv pretoči iz starega delovnega prostora v svežega z 2 GB, tako da nikoli ne mora biti v pomnilniku našega strežnika.
5. Primerjaj pred preklopom. V obeh delovnih prostorih preštej datoteke, preberi zadnjo kontrolno točko in preštej kontrolne točke. Preklopi samo, če se vse tri ujemajo.
6. Ob kakršni koli napaki ohrani starega. Vsaka napaka ali neujemanje zavrže nov delovni prostor in projekt se odpre v starem, kot prej.

Ena podrobnost pri primerjavi je bila pomembnejša, kot se zdi. Preverjanje teče kot skrbniški račun, git pa noče brati repozitorija, ki ga je lastil drug uporabnik. Na obeh straneh ni izpisal ničesar – in „nič“ se je ujemalo z „nič“, zato je preverjanje uspelo, ne da bi sploh primerjalo zgodovino. Gitu smo nato povedali, naj zaupa imeniku, in dodali test, da se to ne ponovi.

Kaj je šlo narobe prvi dan

Na prvi dan v produkciji je pakiranje enega projekta naletelo na petminutno časovno omejitev ukaza – znotraj prebujanja. Lastnik je čakal sedem minut, da se je njegov delovni prostor odprl. Ker premik ni uspel, je bil projekt še vedno majhen, zato bi naslednje odpiranje poskusilo znova in ga ponovno prisililo v čakanje.

Selitev, ki uporabnika prisili, da čaka pri odpiranju lastnega projekta, je slaba menjava. Smisel izvajanja ob prebujanju je bil ravno v tem, da tega nihče ne bi opazil.

Drugi poskus: trda časovna meja

Isti dan smo spremenili štiri stvari:

• Ena minuta za celoten premik. Vsi koraki – preverjanje velikosti, pakiranje, ustvarjanje novega delovnega prostora, kopiranje, razpakiranje, primerjava – delijo en sam 60-sekundni proračun. Ko se ta izteče, se projekt odpre v starem delovnem prostoru.
• Ustavi delo, ne samo čakanja. Če se mi odpovemo, arhiviranje pa še vedno teče v delovnem prostoru, ki ga lastnik ravno odpira, to ne zadostuje. Vsak ukaz za arhiviranje se zdaj ubije znotraj samega delovnega prostora tik pred iztekom proračuna. Če novi delovni prostor pride, potem ko smo se že odpovedali, se zavrže.
• Ne sili lastnika k čakanju na čiščenje. Brisanje začasnega arhiva se zdaj izvaja v ozadju.
• Ne poskušaj znova ob vsakem odpiranju. Projekt, ki ga ni bilo mogoče premakniti, se 24 ur pusti pri miru, tako da napaka stane največ eno zakasnitev na dan, ne eno na vsako odpiranje.

Tretji poskus: odstrani ga iz prebujanja

S tem je najslabši primer skrajšan na eno minuto. Toda minuta je še vedno minuta, in ugotovili smo, da premik sploh ni treba postaviti na pot nikogar.

Noben delovni prostor se ne ustvari več z 1 GB. Torej to ni stalen proces; je enkratno opravilo s fiksnim seznamom delovnih prostorov. Če je bil premik znotraj prebujanja, je vsako počasno premikanje plačala resnična oseba, edini način, da bi izvedeli, da se delovni prostor ni premaknil, pa je bil, da je nekdo ravno čakal nanj.

Zato smo premik popolnoma odstranili iz prebujanja. Odpiranje projekta zdaj deluje kot prej. Preostale majhne delovne prostore obravnavamo kot nadzorovano serijo: nihče na to ne čaka, delovni prostor, ki se ne da premakniti, pa se pojavi v poročilu serije, kjer si ga lahko ogledamo, namesto pred očmi lastnika.

Kaj smo iz tega vzeli

• Povečanje ni vedno mogoče. Če platforma velikost ob ustvarjanju fiksira, dvig privzete vrednosti pomaga samo novim stvarem. Načrtuj za stare.
• „Še nihče je ne uporablja“ še vedno pomeni, da nekdo čaka. Delo, opravljeno na poti v izdelek, je delo, ki ga človek opazuje.
• Postavi proračun za vse, kar je na poti uporabnika, in ustavi delo, ko se izteče. Če se na naši strani odpovemo, ukaz pa še naprej teče drugje, samo premakneš težavo.
• Enkratna selitev sodi v enkratno opravilo. Skrivanje v vsakdanjih dejanjih jo naredi cenejšo za pisanje in dražjo za izvajanje.
• Preizkusi svoje varnostne preverbe. Primerjava, ki ne primerja ničesar, je videti natanko kot tista, ki je uspela.

Če gradite na Mythexu, ni ničesar za narediti: cilj je preprosto manj delovnih prostorov, ki zmanjkajo pomnilnika, pri čemer se projekt odpre tako hitro kot prej. Kako se delovni prostori ustavijo in prebudijo, je opisano v dokumentaciji pod zasebni delovni prostor. Za drugo zgodbo o zmanjkanju pomnilnika glejte zrušitev zaradi pomnilnika, skrito v oznaki napredka.