Paglipat sa Mas Malalaking Workspace Nang Walang Naghihintay

Ang bawat proyekto sa Mythex ay may sariling workspace: isang maliit na cloud computer kung saan sumusulat ng code ang agent at tumatakbo ang preview ng app mo. Itinaas na namin ang bagong workspace mula 1 GB hanggang 2 GB na memory, pero nanatili sa 1 GB ang mga luma. Sa araw na tiningnan namin, mga isang-kapat nila. Inilipat ng unang ayos namin ang isang proyekto sa mas malaking workspace pagbukas ito sa susunod na pagkakataon. Sa unang araw nito sa production, pitong minuto ang hinintay ng isang tao. Naglagay kami ng mahigpit na limitasyon sa oras, at pagkatapos ay inalis na namin ang paglipat sa pagbubukas ng proyekto nang tuluyan.

Bakit nanatiling maliit ang mga lumang workspace

Itinatakda ng sandbox provider namin ang laki ng workspace sa paglikha nito, at pinapanatili ito sa bawat pause at resume. Ang pagbabago sa template, ang recipe kung saan ginagawa ang mga bagong workspace, ay nakakaapekto lang sa mga workspace na nilikha pagkatapos ng pagbabago. Walang nagre-resize sa mga umiiral na.

Mahalaga iyon. Isa sa maliliit na workspace ang naubusan ng memory habang may git push at nagsisimula pa lang ang preview nito, at tumigil sa pagtugon nang 11 minuto. Pumalpak ang isang publish dahil dito.

Unang pagtatangka: ilipat ang proyekto kapag gumigising ito

Nag-p-pause ang mga workspace kapag walang gumagamit at gumigising kapag binuksan ang proyekto. Mukhang tamang sandali ang paggising para ilipat ang proyekto, dahil wala pang nagtatrabaho rito.

Ganito gumana ang paglipat:

Suriin ang laki. Kung mas maliit sa 2 GB ang workspace, ilipat ito. Kung hindi alam ang laki, huwag gumawa ng anuman.
Huwag istorbohin ang publish. Nagbabasa ng mga file ng workspace ang publish, kaya kung may tumatakbong publish, laktawan ang paglipat.
I-pack ang proyekto. I-archive ang lahat sa proyekto, kasama ang git history nito, na bawat checkpoint na mayroon ang proyekto, at ang .env file ng app na pag-aari ng may-ari, pero iwanan ang mga naka-install na dependency (node_modules), na maaaring i-install ulit.
Kopyahin nang diretso. I-stream ang archive mula sa lumang workspace papunta sa bagong 2 GB na workspace, para hindi na kailangang kasya sa memory ng sarili naming server.
Ihambing bago lumipat. Bilangin ang mga file, basahin ang pinakabagong checkpoint, at bilangin ang mga checkpoint, sa parehong workspace. Lumipat lang kung magkatugma ang tatlo.
Panatilihin ang luma kapag may pumalpak. Anumang error o hindi pagtutugma ay itatapon ang bagong workspace at bubuksan ang proyekto sa lumang workspace, gaya ng dati.

May isang detalye sa paghahambing na mas mahalaga kaysa sa itsura nito. Ang pagsusuri ay tumatakbo bilang administrator account, at tumatanggi ang git na basahin ang repository na pag-aari ng ibang user. Wala itong ipinakita sa magkabilang panig. At ang "walang laman" ay katugma ng "walang laman", kaya pumasa ang pagsusuri nang hindi talaga inihahambing ang anumang history. Sinabihan namin ang git na pagkatiwalaan ang directory, at nagdagdag ng test para hindi na ito muling madulas.

Ang nangyari sa unang araw

Sa unang araw nito sa production, nang i-pack ang isang proyekto, tumama ito sa limang minutong timeout ng command, sa loob mismo ng paggising. Naghintay ang may-ari nang pitong minuto bago bumukas ang workspace niya. At dahil pumalpak ang paglipat, maliit pa rin ang proyekto, kaya susubukan ulit ito sa susunod na pagbukas at pahihintayin ulit sila.

Masamang kalakalan ang migration na nagpapahintay sa tao habang binubuksan niya ang sarili niyang proyekto. Ang buong punto ng paggawa nito tuwing paggising ay para walang mapansin ang sinuman.

Pangalawang pagtatangka: mahigpit na badyet

Sa parehong araw, binago namin ang apat na bagay:

Isang minuto para sa buong paglipat. Bawat hakbang (pagsusuri ng laki, pag-pack, paggawa ng bagong workspace, pagkopya, pag-unpack, paghahambing) ay nagbabahagi ng iisang 60-segundong badyet. Kapag naubos ito, bubuksan ang proyekto sa lumang workspace.
Itigil ang trabaho, hindi lang ang paghihintay. Hindi sapat na sumuko kami sa panig namin kung tuloy-tuloy pa rin ang pag-archive sa loob ng workspace na malapit nang gamitin ng may-ari. Ngayon, pinapatay na ang bawat archive command sa loob mismo ng workspace, sandali bago matapos ang badyet. Kung dumating ang bagong workspace matapos naming sumuko, itatapon ito.
Huwag pahintayin ang may-ari sa paglilinis. Sa background na nangyayari ang pagbura ng pansamantalang archive.
Huwag subukan ulit sa bawat pagbukas. Ang proyektong hindi nailipat ay hindi gagalawin sa loob ng 24 oras, para ang isang pagkabigo ay nagkakagastos ng isang pagkaantala bawat araw, hindi isa bawat pagbukas.

Pangatlong pagtatangka: alisin ito sa paggising

Nagpababa iyon ng pinakamasamang kaso sa isang minuto. Pero isang minuto pa rin iyon, at napagtanto namin na hindi kailangang nasa daanan ng sinuman ang paglipat.

Wala nang nilalikhang workspace na 1 GB. Kaya hindi ito patuloy na proseso; isa itong one-time job na may nakapirming listahan ng mga workspace. Ang paggawa nito sa loob ng paggising ay nangangahulugang may totoong taong nagbayad para sa bawat mabagal na paglipat, at ang tanging paraan para malaman naming hindi lilipat ang isang workspace ay kapag may nagkataong naghintay dito.

Kaya inalis namin ang paglipat sa paggising nang tuluyan. Ang pagbubukas ng proyekto ay gumagana gaya ng dati. Ang natitirang maliliit na workspace ay hinahawakan na bilang isang binabantayang batch: walang naghihintay dito, at ang workspace na hindi malilipat ay lalabas sa ulat ng batch, kung saan maaari namin itong tingnan, sa halip na sa harap ng may-ari nito.

Ang natutunan namin

Hindi laging posible ang pag-resize. Kapag inayos ng platform ang laki sa paglikha, ang pagtaas ng default ay nakakatulong lang sa mga bago. Magplano para sa mga luma.
"Wala pang gumagamit nito" ay hindi ibig sabihing walang naghihintay. Ang gawaing ginagawa sa papasok sa isang produkto ay gawaing pinapanood ng tao.
Maglagay ng badyet sa anumang nasa daanan ng user, at ihinto ang trabaho kapag naubos ito. Ang timeout sa panig namin habang patuloy na tumatakbo ang command sa ibang lugar ay naglilipat lang ng problema.
Ang one-time na migration ay dapat nasa one-time na job. Ang pagtatago nito sa mga pang-araw-araw na aksyon ay ginagawang mas mura isulat, pero mas mahal patakbuhin.
Subukan ang mga safety check mo. Ang paghahambing na walang inihahambing ay mukhang eksaktong katulad ng paghahambing na pumasa.

Kung nagbu-build ka sa Mythex, wala kang kailangang gawin. Ang layunin ay mas kaunting workspace na nauubusan ng memory, at ang pagbubukas ng proyekto ay kasing-bilis pa rin ng dati. Paano nagpa-pause at gumigising ang mga workspace ay nakasaad sa docs sa ilalim ng private workspace. Para sa isa pang kuwento ng out-of-memory, tingnan ang ang out-of-memory crash na nakatago sa isang progress label.