Prelazak na veće radne prostore bez čekanja za bilo koga

Svaki Mythex projekat dobija svoj radni prostor: mali cloud računar na kojem agent piše kod i na kojem radi pregled vaše aplikacije. Nove radne prostore podigli smo sa 1 GB memorije na 2 GB, ali stariji su ostali na 1 GB — onog dana kada smo provjeravali, otprilike četvrtina njih. Naša prva ispravka premještala je projekat na veći radni prostor kada se sljedeći put otvori. Prvog dana u produkciji, to je jednog korisnika natjeralo da čeka sedam minuta. Stavili smo tvrdi vremenski limit, a zatim premještanje uklonili iz otvaranja projekta uopšte.

Zašto su stari radni prostori ostali mali

Naš sandbox provider postavlja veličinu radnog prostora kada se on kreira, i zadržava je kroz svaku pauzu i nastavak. Promjena šablona — recepta od kojeg se grade novi radni prostori — utiče samo na radne prostore kreirane nakon promjene. Ništa ne mijenja veličinu onih koji već postoje.

To je bilo važno. Jedan od malih radnih prostora ostao je bez memorije tokom git push-a dok se pregled pokretao, i 11 minuta nije odgovarao. Objava je pukla zbog toga.

Prvi pokušaj: premjesti projekat pri buđenju

Radni prostori se pauziraju kada ih niko ne koristi i bude se kada se projekat otvori. Buđenje se činilo kao pravi trenutak za premještanje projekta, jer u njemu još niko ne radi.

Premještanje je funkcionisalo ovako:

1. Provjeri veličinu. Ako je radni prostor manji od 2 GB, premjesti ga. Ako je veličina nepoznata, ne radi ništa.
2. Ne ometaj objavu. Objava čita fajlove radnog prostora, pa ako je jedna u toku, preskoči premještanje.
3. Spakuj projekat. Arhiviraj sve u projektu — uključujući njegovu git istoriju, odnosno svaki checkpoint koji projekat ima, i .env fajl aplikacije, koji pripada vlasniku — ali izostavi instalirane zavisnosti (node_modules), koje se mogu ponovo instalirati.
4. Prebaci ga direktno. Strimuj arhivu sa starog radnog prostora u novi, 2 GB, tako da nikada ne mora da stane u memoriju našeg vlastitog servera.
5. Uporedi prije prebacivanja. Prebroj fajlove, pročitaj posljednji checkpoint i prebroj checkpoint-e, u oba radna prostora. Prebaci samo ako se sva tri poklapaju.
6. Zadrži stari pri svakoj grešci. Svaka greška ili neslaganje baca novi radni prostor i otvara projekat u starom, kao i prije.

Jedan detalj u poređenju bio je važniji nego što izgleda. Provjera se izvršava kao administratorski nalog, a git odbija da čita repozitorijum čiji vlasnik je drugi korisnik. Na obje strane nije ispisao ništa — a „ništa” se poklopilo sa „ništa”, pa je provjera prošla bez ikakvog poređenja istorije. Rekli smo gitu da vjeruje direktorijumu i dodali test da se to ne vrati.

Šta je pošlo po zlu prvog dana

Prvog dana u produkciji, pakovanje jednog projekta udarilo je na timeout komande od pet minuta — unutar buđenja. Vlasnik je čekao sedam minuta da se njegov radni prostor otvori. A pošto premještanje nije uspjelo, projekat je i dalje bio mali, pa bi sljedeće otvaranje ponovo pokušalo i opet ga natjeralo da čeka.

Migracija koja nekoga natjera da čeka dok otvara sopstveni projekat je loša trgovina. Cijela ideja da se radi pri buđenju bila je da niko to neće primijetiti.

Drugi pokušaj: tvrdi budžet

Istog dana promijenili smo četiri stvari:

• Jedan minut za cijelo premještanje. Svaki korak — provjera veličine, pakovanje, kreiranje novog radnog prostora, kopiranje, raspakivanje, poređenje — dijeli jedan budžet od 60 sekundi. Kada se on potroši, projekat se otvara u starom radnom prostoru.
• Zaustavi rad, ne samo čekanje. Odustajanje sa naše strane nije dovoljno ako se arhiviranje još izvršava unutar radnog prostora koji vlasnik sprema da koristi. Svaka komanda za arhiviranje sada se ubija unutar samog radnog prostora neposredno prije isteka budžeta. Ako novi radni prostor stigne nakon što smo odustali, baca se.
• Ne tjeraj vlasnika da čeka čišćenje. Brisanje privremene arhive sada se dešava u pozadini.
• Ne pokušavaj ponovo pri svakom otvaranju. Projekat koji nije mogao biti premješten ostavlja se na miru 24 sata, tako da greška košta najviše jedno kašnjenje dnevno, a ne jedno po otvaranju.

Treći pokušaj: izvuci ga iz buđenja

To je najgori slučaj učinilo jednim minutom. Ali minut je i dalje minut, i shvatili smo da premještanje uopšte ne mora biti na ničijem putu.

Nijedan radni prostor se više ne kreira na 1 GB. Dakle, ovo nije tekući proces; to je jednokratni posao sa fiksnom listom radnih prostora. Raditi to unutar buđenja značilo je da stvarna osoba plaća svako sporo premještanje, a jedini način da saznamo da se radni prostor ne može premjestiti bio je da je neko upravo čekao na njega.

Zato smo premještanje u potpunosti uklonili iz buđenja. Otvaranje projekta radi kao i prije. Preostali mali radni prostori obrađuju se kao nadgledana serija: niko na njih ne čeka, a radni prostor koji se ne može premjestiti pojavi se u izvještaju serije, gdje ga možemo pogledati, umjesto pred očima vlasnika.

Šta smo iz toga naučili

• Promjena veličine nije uvijek moguća. Kada platforma fiksira veličinu pri kreiranju, povećanje podrazumijevane vrijednosti pomaže samo novim stvarima. Planirajte za stare.
• „Niko je još ne koristi” i dalje znači da neko čeka. Posao koji se obavlja na putu do proizvoda je posao koji neko posmatra.
• Stavite budžet na sve što je na putu korisnika i zaustavite rad kada se potroši. Istek timeouta na našoj strani dok komanda nastavlja da radi negdje drugo samo pomjera problem.
• Jednokratna migracija pripada jednokratnom poslu. Skrivanje u svakodnevnim radnjama čini je jeftinijom za pisanje, a skupljom za izvršavanje.
• Testirajte sigurnosne provjere. Poređenje koje ništa ne poredi izgleda potpuno kao ono koje je prošlo.

Ako gradite na Mythexu, nema šta da se uradi: cilj je jednostavno manje radnih prostora koji ostanu bez memorije, uz otvaranje projekta jednako brzo kao prije. Kako se radni prostori pauziraju i bude, objašnjeno je u dokumentaciji pod privatni radni prostor. Za još jednu priču o ponestajanju memorije, pogledajte crash zbog ponestajanja memorije skriven u oznaci napretka.