Pindah ke Workspace yang Lebih Besar Tanpa Membuat Siapa Pun Menunggu

Setiap proyek Mythex mendapat workspace-nya sendiri: komputer cloud kecil tempat agen menulis kode dan pratinjau aplikasi Anda berjalan. Kami sudah menaikkan memori workspace baru dari 1 GB ke 2 GB, tetapi workspace lama tetap di 1 GB. Pada hari kami memeriksanya, sekitar seperempatnya masih begitu. Perbaikan pertama kami memindahkan proyek ke workspace yang lebih besar saat proyek itu dibuka berikutnya. Pada hari pertamanya di produksi, itu membuat satu orang menunggu tujuh menit. Kami memasang batas waktu keras untuk itu, lalu mengeluarkan pemindahan itu dari proses membuka proyek sama sekali.

Mengapa workspace lama tetap kecil

Penyedia sandbox kami menetapkan ukuran workspace saat dibuat, dan mempertahankannya melalui setiap jeda dan lanjut. Mengubah template, yaitu resep yang dipakai untuk membangun workspace baru, hanya berpengaruh pada workspace yang dibuat setelah perubahan. Tidak ada yang mengubah ukuran workspace yang sudah ada.

Itu penting. Salah satu workspace kecil kehabisan memori saat git push ketika pratinjaunya sedang dimulai, dan berhenti merespons selama 11 menit. Sebuah publish gagal karenanya.

Percobaan pertama: pindahkan proyek saat bangun

Workspace dijeda ketika tidak ada yang memakainya dan dibangunkan ketika proyek dibuka. Membangunkan tampak seperti saat yang tepat untuk memindahkan proyek, karena belum ada yang bekerja di dalamnya.

Pemindahannya bekerja seperti ini:

1. Periksa ukurannya. Jika workspace lebih kecil dari 2 GB, pindahkan. Jika ukurannya tidak diketahui, jangan lakukan apa-apa.
2. Jangan ganggu publish. Publish membaca file workspace, sehingga jika ada yang sedang berjalan, lewati pemindahan.
3. Kemas proyeknya. Arsipkan semua yang ada di proyek, termasuk riwayat git-nya, yaitu setiap checkpoint yang dimiliki proyek, dan file .env aplikasi yang menjadi milik pemilik, tetapi tinggalkan dependensi yang terinstal (node_modules), yang bisa diinstal ulang.
4. Salin langsung. Alirkan arsip dari workspace lama ke workspace 2 GB yang baru, sehingga tidak perlu muat di memori server kami sendiri.
5. Bandingkan sebelum berpindah. Hitung file, baca checkpoint terbaru, dan hitung jumlah checkpoint, di kedua workspace. Pindah hanya jika ketiganya cocok.
6. Simpan yang lama jika gagal. Error apa pun atau ketidakcocokan apa pun membuang workspace baru dan membuka proyek di workspace lama, seperti sebelumnya.

Satu detail dalam perbandingan itu lebih penting daripada kelihatannya. Pemeriksaan berjalan sebagai akun administrator, dan git menolak membaca repositori yang dimiliki pengguna lain. Di kedua sisi, pemeriksaan itu tidak mencetak apa pun, dan “tidak ada” cocok dengan “tidak ada”, sehingga pemeriksaan lolos tanpa membandingkan riwayat sama sekali. Kami memberi tahu git untuk mempercayai direktori itu, dan menambahkan tes agar hal itu tidak terulang.

Apa yang salah di hari pertama

Pada hari pertamanya di produksi, pengemasan satu proyek menabrak batas waktu perintah lima menit, di dalam proses bangun. Pemilik menunggu tujuh menit agar workspace-nya terbuka. Dan karena pemindahan gagal, proyek masih kecil, sehingga pembukaan berikutnya akan mencoba lagi dan membuat mereka menunggu lagi.

Migrasi yang membuat seseorang menunggu saat membuka proyeknya sendiri adalah pertukaran yang buruk. Seluruh tujuan melakukannya saat bangun adalah agar tidak ada yang menyadarinya.

Percobaan kedua: anggaran keras

Pada hari yang sama, kami mengubah empat hal:

• Satu menit untuk seluruh pemindahan. Setiap langkah, yaitu memeriksa ukuran, mengemas, membuat workspace baru, menyalin, membongkar, dan membandingkan, berbagi satu anggaran 60 detik. Ketika anggaran habis, proyek dibuka di workspace lama.
• Hentikan pekerjaannya, bukan hanya menunggunya. Berhenti menunggu di sisi kami tidak cukup jika pengarsipan masih berjalan di dalam workspace yang akan digunakan pemilik. Setiap perintah arsip sekarang dihentikan di dalam workspace itu sendiri sesaat sebelum anggaran berakhir. Jika workspace baru tiba setelah kami menyerah, workspace itu dibuang.
• Jangan membuat pemilik menunggu pembersihan. Penghapusan arsip sementara sekarang dilakukan di latar belakang.
• Jangan mencoba lagi di setiap pembukaan. Proyek yang gagal dipindahkan dibiarkan selama 24 jam, sehingga satu kegagalan paling banyak menimbulkan satu penundaan per hari, bukan satu per pembukaan.

Percobaan ketiga: keluarkan dari proses bangun

Itu membuat kasus terburuknya menjadi satu menit. Tetapi satu menit tetaplah satu menit, dan kami menyadari bahwa pemindahan itu tidak perlu berada di jalur siapa pun.

Tidak ada workspace yang dibuat dengan 1 GB lagi. Jadi ini bukan proses yang berkelanjutan; ini pekerjaan satu kali dengan daftar workspace yang tetap. Menjalankannya di dalam proses bangun berarti ada orang sungguhan yang membayar setiap pemindahan yang lambat, dan satu-satunya cara kami tahu bahwa sebuah workspace tidak bisa dipindahkan adalah ketika seseorang baru saja menunggunya.

Maka kami mengeluarkan pemindahan dari proses bangun sepenuhnya. Membuka proyek berjalan seperti sebelumnya. Workspace kecil yang tersisa ditangani sebagai batch yang diawasi: tidak ada yang menunggunya, dan workspace yang tidak bisa dipindahkan muncul di laporan batch, tempat kami bisa memeriksanya, bukan di depan orang yang memilikinya.

Yang kami pelajari

• Mengubah ukuran tidak selalu mungkin. Ketika platform menetapkan ukuran saat pembuatan, menaikkan default hanya membantu hal-hal baru. Rencanakan untuk yang lama.
• “Belum ada yang memakainya” tetap berarti ada orang yang menunggu. Pekerjaan yang dilakukan di jalan masuk ke sebuah produk adalah pekerjaan yang dilihat oleh seseorang.
• Pasang anggaran pada apa pun yang ada di jalur pengguna, dan hentikan pekerjaannya ketika anggaran habis. Menyerah di sisi kami sementara perintah tetap berjalan di tempat lain hanya memindahkan masalahnya.
• Migrasi satu kali termasuk dalam pekerjaan satu kali. Menyembunyikannya di dalam tindakan sehari-hari membuatnya lebih murah untuk ditulis dan lebih mahal untuk dijalankan.
• Uji pemeriksaan keselamatan Anda. Perbandingan yang tidak membandingkan apa pun terlihat persis seperti perbandingan yang lolos.

Jika Anda membangun di Mythex, tidak ada yang perlu dilakukan: tujuannya hanya agar lebih sedikit workspace kehabisan memori, dengan membuka proyek secepat sebelumnya. Cara workspace dijeda dan dibangunkan dibahas di dokumentasi pada bagian workspace pribadi. Untuk kisah kehabisan memori lainnya, lihat crash out-of-memory yang tersembunyi di label progres