Přechod na větší pracovní prostory bez čekání pro kohokoli

Každý projekt Mythexu dostane vlastní pracovní prostor: malý cloudový počítač, kde agent píše kód a běží náhled vaší aplikace. Nové pracovní prostory jsme zvedli z 1 GB paměti na 2 GB, ale starší zůstaly na 1 GB – v den, kdy jsme to kontrolovali, to byla zhruba čtvrtina z nich. Naše první oprava přesunula projekt do většího pracovního prostoru, až se příště otevře. V prvním dni v produkci to jednoho člověka stálo sedm minut čekání. Nastavili jsme tvrdý časový limit a potom přesun vyjmuli z otevírání projektu úplně.

Proč staré pracovní prostory zůstaly malé

Náš poskytovatel sandboxů nastavuje velikost pracovního prostoru při vytvoření a zachovává ji přes každé pozastavení a obnovení. Změna šablony – receptu, podle kterého se nové pracovní prostory staví – ovlivní jen pracovní prostory vytvořené po změně. Nic nezmění velikost těm, které už existují.

Na tom záleželo. Jeden z malých pracovních prostorů došel paměti během git push, zatímco se jeho náhled spouštěl, a 11 minut nereagoval. Kvůli tomu selhalo jedno publikování.

První pokus: přesunout projekt při probuzení

Pracovní prostory se pozastaví, když je nikdo nepoužívá, a probudí se, když se projekt otevře. Probuzení se zdálo být správným okamžikem k přesunu projektu, protože v něm zatím nikdo nepracuje.

Přesun fungoval takto:

Zkontrolujte velikost. Pokud je pracovní prostor menší než 2 GB, přesuňte ho. Pokud není velikost známa, nedělejte nic.
Nerušte publikování. Publikování čte soubory pracovního prostoru, takže pokud běží, přesun přeskočte.
Zabalte projekt. Zarchivujte celý projekt – včetně jeho git historie, tedy každého checkpointu, který projekt má, a .env souboru aplikace, který patří vlastníkovi – ale vynechejte nainstalované závislosti (node_modules), které lze znovu nainstalovat.
Zkopírujte rovnou. Archiv proudí ze starého pracovního prostoru do čerstvého 2GB, takže se nikdy nemusí vejít do paměti našeho vlastního serveru.
Porovnejte před přepnutím. V obou pracovních prostorech spočítejte soubory, přečtěte poslední checkpoint a spočítejte checkpointy. Přepněte, jen pokud se všechny tři shodují.
Při jakékoli chybě si ponechte starý. Jakákoli chyba nebo neshoda zahodí nový pracovní prostor a projekt se otevře ve starém, jako dřív.

Jeden detail v porovnání byl důležitější, než vypadá. Kontrola běží pod administrátorským účtem a git odmítá číst repozitář, který vlastní jiný uživatel. Na obou stranách nic nevypsala – a „nic“ se shodovalo s „nic“, takže kontrola prošla, aniž by porovnala jedinou historii. Řekli jsme gitu, aby adresáři důvěřoval, a přidali test, aby se to nemohlo vrátit.

Co se pokazilo v prvním dni

V prvním dni v produkci zabalení jednoho projektu narazilo na pětiminutový časový limit příkazu – uvnitř probouzení. Vlastník čekal sedm minut, než se jeho pracovní prostor otevřel. A protože přesun selhal, projekt zůstal malý, takže by se při příštím otevření pokus zopakoval a vlastník by znovu čekal.

Migrace, která nutí člověka čekat na otevření vlastního projektu, je špatný obchod. Celý smysl dělat ji při probuzení byl v tom, že si toho nikdo nevšimne.

Druhý pokus: pevný rozpočet

Tentýž den jsme změnili čtyři věci:

Minuta na celý přesun. Každý krok – kontrola velikosti, balení, vytvoření nového pracovního prostoru, kopírování, rozbalení, porovnání – sdílí jeden rozpočet 60 sekund. Když dojde, projekt se otevře ve starém pracovním prostoru.
Zastavit práci, ne jen čekání. Vzdát se na naší straně nestačí, pokud archivace stále běží uvnitř pracovního prostoru, který vlastník právě bude používat. Každý archivační příkaz se nyní zabíjí přímo uvnitř pracovního prostoru krátce před koncem rozpočtu. Pokud nový pracovní prostor dorazí, až jsme se vzdali, zahodí se.
Nenechat vlastníka čekat na úklid. Mazání dočasného archivu probíhá na pozadí.
Nezkoušet to znovu při každém otevření. Projekt, který se nepodařilo přesunout, se na 24 hodin nechá být, takže selhání stojí nejvýš jedno zpoždění denně, ne jedno při každém otevření.

Třetí pokus: vyjmout to z probouzení

To zkrátilo nejhorší případ na minutu. Minuta je ale pořád minuta a uvědomili jsme si, že přesun nemusí být na cestě nikoho.

Nový pracovní prostor se už nevytváří na 1 GB. Nejde tedy o průběžný proces, ale o jednorázovou úlohu s pevným seznamem pracovních prostorů. Když to bylo uvnitř probouzení, člověk platil za každý pomalý přesun a jediný způsob, jak jsme se dozvěděli, že pracovní prostor se nepřesune, bylo, že na to právě někdo čekal.

Proto jsme přesun z probouzení úplně odstranili. Otevření projektu dělá, co dělalo předtím. Zbývající malé pracovní prostory se řeší jako dávka pod dohledem: na nikoho se nečeká a pracovní prostor, který se nepřesune, se objeví v reportu dávky, kde se na něj můžeme podívat, místo abychom ho ukázali vlastníkovi.

Co si z toho bereme

Změna velikosti není vždy možná. Když platforma velikost při vytvoření pevně nastaví, zvýšení výchozí hodnoty pomůže jen novým věcem. Počítejte se starými.
„Nikdo to zatím nepoužívá“ pořád znamená, že na to někdo čeká. Práce, která se dělá na cestě do produktu, je práce, kterou člověk sleduje.
Na cokoli na cestě uživatele dejte rozpočet a při jeho vyčerpání práci zastavte. Vzdát se na naší straně, zatímco příkaz běží dál jinde, problém jen přesouvá.
Jednorázová migrace patří do jednorázové úlohy. Schovat ji do běžných akcí ji zlevní na napsání a zdraží na provoz.
Testujte své bezpečnostní kontroly. Porovnání, které nic neporovnává, vypadá přesně jako to, které prošlo.

Pokud na Mythexu stavíte, nemusíte dělat nic. Cílem je jen méně pracovních prostorů, které dojdou paměti, a otevírání projektu stejně rychlé jako dřív. Jak se pracovní prostory pozastavují a probouzejí, popisuje dokumentace v části soukromý pracovní prostor. Pro další příběh o nedostatku paměti se podívejte na únik paměti skrytý v popisku průběhu.