Prelazak na veće radne prostore bez čekanja nikoga

Svaki Mythex projekt dobiva vlastiti radni prostor: malo cloud računalo na kojem agent piše kod i na kojem radi pregled vaše aplikacije. Novim radnim prostorima povećali smo memoriju s 1 GB na 2 GB, ali stariji su ostali na 1 GB. Na dan kad smo provjerili, bilo je to otprilike četvrtina. Prvi popravak premjestio je projekt u veći radni prostor kad se sljedeći put otvorio. Prvog dana u produkciji to je jednu osobu natjeralo da čeka sedam minuta. Stavili smo tvrdi vremenski limit, a onda smo premještanje uklonili iz otvaranja projekta.

Zašto su stari radni prostori ostali mali

Naš pružatelj sandboxa određuje veličinu radnog prostora pri stvaranju i zadržava je kroz svaku pauzu i nastavak. Promjena predloška, recepta iz koje se grade novi radni prostori, utječe samo na radne prostore stvorene 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 tijekom git push-a dok se pregled pokretao i 11 minuta nije odgovarao. Objava je zbog toga pukla.

Prvi pokušaj: premjesti projekt pri buđenju

Radni prostori pauziraju kad ih nitko ne koristi, a bude se kad se projekt otvori. Buđenje se činilo kao pravi trenutak za premještanje projekta, jer u njemu još nitko ne radi.

Premještanje je radilo 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 datoteke radnog prostora, pa ako je jedna u tijeku, preskoči premještanje.
3. Spakiraj projekt. Arhiviraj sve u projektu, uključujući njegovu git povijest, koja je svaka točka spremanja koju projekt ima, i .env datoteku aplikacije, koja pripada vlasniku, ali izostavi instalirane ovisnosti (node_modules), koje se mogu ponovno instalirati.
4. Prebaci izravno. Prenesi arhivu iz starog radnog prostora u novi, 2 GB, tako da nikad ne mora stati u memoriju našeg vlastitog servera.
5. Usporedi prije prebacivanja. Prebroj datoteke, pročitaj zadnju točku spremanja i prebroj točke spremanja u oba radna prostora. Prebaci samo ako se sva tri podudaraju.
6. Zadrži stari radni prostor pri svakoj grešci. Svaka greška ili nepodudaranje odbacuje novi radni prostor i projekt se otvara u starome, kao i prije.

Jedan detalj u usporedbi bio je važniji nego što izgleda. Provjera se izvršava kao administratorski račun, a git odbija čitati repozitorij u vlasništvu drugog korisnika. Na obje strane nije ispisao ništa, a “ništa” se podudaralo s “ništa”, pa je provjera prošla bez ikakve usporedbe povijesti. Rekli smo gitu da vjeruje tom direktoriju i dodali test da se to ne vrati.

Što je pošlo po zlu prvog dana

Prvog dana u produkciji pakiranje jednog projekta udarilo je u vremenski limit naredbe od pet minuta, unutar buđenja. Vlasnik je čekao sedam minuta da se njegov radni prostor otvori. A budući da premještanje nije uspjelo, projekt je ostao mali, pa bi sljedeće otvaranje pokušalo ponovno i ponovno ga natjeralo da čeka.

Premještanje koje nekoga tjera da čeka dok otvara vlastiti projekt loša je zamjena. Cijela ideja da se to radi pri buđenju bila je u tome da nitko neće primijetiti.

Drugi pokušaj: čvrst vremenski proračun

Istog dana promijenili smo četiri stvari:

• Jedna minuta za cijelo premještanje. Svaki korak (provjera veličine, pakiranje, stvaranje novog radnog prostora, kopiranje, raspakiravanje, usporedba) dijeli jedan proračun od 60 sekundi. Kad se on potroši, projekt se otvara u starom radnom prostoru.
• Zaustavi posao, a ne samo čekanje. Odustajanje s naše strane nije dovoljno ako se arhiviranje i dalje izvršava u radnom prostoru koji vlasnik upravo treba koristiti. Svaka naredba za arhiviranje sada se ubija unutar samog radnog prostora kratko prije kraja proračuna. Ako novi radni prostor stigne nakon što smo odustali, odbacuje se.
• Ne čekaj vlasnika na čišćenje. Brisanje privremene arhive sada se događa u pozadini.
• Ne pokušavaj ponovno pri svakom otvaranju. Projekt koji se nije mogao premjestiti ostavlja se na miru 24 sata, pa neuspjeh košta najviše jedno kašnjenje dnevno, a ne jedno po otvaranju.

Treći pokušaj: izvadi to iz buđenja

To je najgori slučaj sveo na jednu minutu. Ali minuta je i dalje minuta, a shvatili smo da premještanje uopće ne mora biti na ničijem putu.

Nijedan radni prostor se više ne stvara na 1 GB. Dakle, ovo nije stalni proces, nego jednokratan posao s fiksnim popisom radnih prostora. Kad je bio unutar buđenja, svako sporo premještanje platio je stvarni čovjek, a jedini način da saznamo da se radni prostor neće premjestiti bio je da je netko upravo čekao na njega.

Zato smo premještanje uklonili iz buđenja potpuno. Otvaranje projekta radi isto kao i prije. Preostale male radne prostore obrađujemo kao nadzirani skup: nitko na njih ne čeka, a radni prostor koji se ne može premjestiti pojavi se u izvještaju skupa, gdje ga možemo pogledati, a ne pred osobom čiji je.

Što smo iz ovoga naučili

• Promjena veličine nije uvijek moguća. Kad platforma fiksira veličinu pri stvaranju, povećanje zadane vrijednosti pomaže samo novima. Planirajte za stare.
• “Nitko je još ne koristi” i dalje znači da netko čeka. Posao koji se radi na putu u proizvod je posao koji čovjek gleda.
• Stavite proračun na sve što je na putu korisnika i zaustavite posao kad se potroši. Odustajanje na našoj strani dok naredba i dalje radi negdje drugdje samo pomiče problem.
• Jednokratna migracija pripada jednokratnom poslu. Skrivanje u svakodnevnim radnjama čini je jeftinijom za pisanje, a skupljom za izvođenje.
• Testirajte svoje sigurnosne provjere. Usporedba koja ništa ne uspoređuje izgleda točno kao ona koja je prošla.

Ako gradite na Mythexu, nema što raditi: cilj je jednostavno manje radnih prostora koji ostaju bez memorije, uz jednako brzo otvaranje projekta. Kako se radni prostori pauziraju i bude opisano je u dokumentaciji pod privatni radni prostor. Za drugu priču o ispadu zbog memorije pogledajte pad zbog memorije skriven u oznaci napretka.