Cara self-host Dormice untuk sandbox ejen AI

Apakah itu Dormice, dan apakah ia bukan

Dormice ialah sandbox ejen yang dihoskan sendiri: satu daemon pada VPS Linux milik anda, yang dipanggil oleh kod ejen anda melalui HTTP untuk menjalankan kod yang tidak dipercayai di dalam kontena terasing. Program anda meminta sandbox mengikut nama, mendapatkan semula sandbox yang sama walau apa pun keadaannya, menjalankan arahan di dalamnya, dan membaca outputnya. Sandbox ini merupakan sumber pengaturcaraan, bukan mesin yang anda log masuk.

Ini berbeza daripada memberikan ejen sebuah komputer penuh. VM pakai buang untuk ejen pengekodan ialah kotak yang anda SSH masuk, biarkan ejen merosakkannya, kemudian memadamnya. Dormice berada satu tahap di bawah: ia adalah API pelaksanaan yang dipanggil oleh program anda apabila ia sudah mempunyai kod dan memerlukan tempat yang selamat untuk menjalankannya. Gunakan VM pakai buang apabila satu mesin penuh adalah unit kerja. Gunakan Dormice apabila satu panggilan exec adalah unit kerja, dan anda mahukan seratus daripadanya sehari tanpa perlu menyediakan seratus VM.

Projek ini menggelarkan dirinya sebagai serasi dengan E2B. E2B ialah perkhidmatan sandbox yang dihoskan yang pustaka kliennya sudah diimport oleh banyak rangka kerja ejen. Dormice menyediakan protokol yang sama di bawah awalan URL miliknya sendiri, jadi aplikasi yang ditulis menggunakan pakej e2b rasmi akan terus berfungsi apabila anda menghalakannya ke kotak anda sendiri. Kod aplikasi tidak berubah. Dua URL dan satu awalan kunci API sahaja yang berubah.

Apakah maksud "SQLite bagi sandbox ejen" dalam praktiknya

SQLite ialah pangkalan data yang anda benamkan dan bukannya servis yang anda kendalikan, dan Dormice meminjam perbandingan itu secara langsung. Satu daemon, satu fail SQLite untuk lejar, satu port TCP. Tiada Kubernetes, tiada pangkalan data berasingan, tiada penjadual. Daemon tersebut mengambil kunci di sebelah lejarnya dan enggan bermula apabila lejar serta mesin yang ditemuinya tidak sepadan, jadi situasi split brain tidak akan berlaku secara senyap. Reka bentuknya adalah untuk satu mesin. Jika anda memerlukan armada merentas banyak hos, README memberitahu anda dengan jelas untuk memilih sesuatu yang lain, dan anda harus mematuhinya.

Separuh kedua idea ini adalah mengenai kos. Sandbox yang dihoskan mengenakan bayaran bagi setiap saat ia wujud, jadi sandbox yang dihoskan direka untuk dibuang. Dormice berjalan pada perkakasan yang anda sudah bayar, jadi sandbox-nya adalah kekal dan menjadi lebih murah semakin lama ia dibiarkan. Sandbox akan menyejuk satu tahap demi satu tahap: aktif, kemudian dibekukan (frozen), kemudian dihentikan, kemudian diarkibkan. Sebarang perolehan (acquire) akan menariknya kembali ke atas daripada mana-mana tahap yang telah dicapainya.

Pembekuan adalah bahagian yang perlu difahami, kerana itulah yang menjadikan penyimpanan sandbox setiap ejen selama-lamanya mampu milik. Ini adalah angka yang diterbitkan oleh projek itu sendiri, diukur pada perkakasannya dan bukan pada perkakasan anda.

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

Sandbox terbiar yang memegang 1024 MiB memori akan turun kepada 5 MiB memori residen sebaik sahaja dibekukan, dan kembali semula dalam masa kira-kira 50 ms. Proses digantung dan disambung semula di tempatnya, jadi ejen yang tahan lama mengekalkan status shell dan kerja yang separuh siap merentas proses pembekuan tersebut. Lakukan reproduksi pada hos anda sendiri sebelum anda merancang kapasiti berdasarkan angka ini.

Keperluan hos sebelum pemasangan

Hos mestilah Ubuntu atau Debian pada x86_64, dan pemasang memerlukan akses root. Daemon mengekalkan akses root semasa runtime kerana ia melakukan loop mounts dan menulis cgroups.

Sandbox berjalan di bawah Docker dengan gVisor (runtime kontena yang meletakkan kernel ruang pengguna antara kontena dan kernel hos), yang membekalkan runsc runtime yang digunakan oleh setiap sandbox. Node 22 atau lebih baharu menjalankan daemon, dan pemasang membawa salinannya sendiri, jadi Node sistem anda tidak akan terjejas.

Swap mesti wujud, dan vm.swappiness mestilah 100. Ini bukan nasihat penalaan, ia adalah keperluan fungsi. Proses pembekuan (freezing) berfungsi dengan menolak memori sandbox yang melahu ke dalam swap, gVisor memegang memori sandbox sebagai memori kongsi, dan kernel tidak akan melakukan swap pada memori kongsi dengan nilai swappiness lalai. Projek ini merekodkan 0 bait yang diperoleh semula pada nilai lalai dan 99.5 peratus diperoleh semula pada 100. Semak nilai yang sebenarnya digunakan oleh kernel, kerana sesetengah imej awan menghantar vm.swappiness = 0 dalam fail yang anda tidak akan terfikir untuk membacanya.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness sepatutnya memaparkan vm.swappiness = 100, dan swapon --show sepatutnya menyenaraikan fail swap. Jika swappiness memaparkan 0, setiap pembekuan tidak akan berfungsi dan menyebabkan anda membayar kos memori penuh untuk setiap sandbox yang melahu.

Memasang Dormice pada Ubuntu

Pemasangan yang didokumentasikan adalah melalui satu pipe ke bash:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

Muat turun dan baca skrip tersebut sebelum anda menjalankannya. Skrip ini berjalan sebagai root dan mengubah suai hos anda: ia memasang Docker jika tiada, memuat turun gVisor dan Caddy dengan pengesahan checksum, mencipta swapfile, menulis unit systemd, serta menambah peraturan firewall.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

--swap-gb menetapkan saiz swapfile dan nilai lalainya ialah 16, yang merupakan penggunaan ruang cakera yang besar untuk VPS kecil. --mirror cn menukar muat turun kepada mirror yang boleh dicapai dari tanah besar China. Menjalankan semula pemasang akan menaik taraf kod dan membaiki perubahan konfigurasi, dan ia tidak akan menukar API token anda.

Kod disimpan dalam /opt/dormice, konfigurasi dalam /etc/dormice/env, data sandbox dalam /var/lib/dormice, dan arahan dormice serta dor dalam /usr/local/bin. Pemasang menjana API token semasa pemasangan dan menulisnya ke /etc/dormice/env dengan mod 600.

Tiada keluaran bertag untuk pemasangan. Setakat 4 Ogos 2026, repositori tersebut tidak mempunyai git tag atau keluaran GitHub, jadi pemasang akan melakukan clone terhadap main dan anda akan mendapat kod terkini pada pagi tersebut. Oleh itu, menetapkan versi bermaksud mencatat commit yang anda pasang.

git -C /opt/dormice rev-parse HEAD

Simpan hash tersebut bersama nota penempatan anda. Apabila naik taraf menyebabkan kerosakan, commit tersebut adalah satu-satunya cara untuk kembali ke versi asal, kerana tiada nombor versi yang boleh dirujuk.

Pemasang berakhir dengan menjalankan dor doctor, iaitu pemeriksaan hos baca-sahaja yang memulakan kontena gVisor sebenar untuk membuktikan runtime berfungsi dan bukannya sekadar mempercayai senarai pakej. Jalankan arahan ini semula apabila daemon berkelakuan tidak normal.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice sepatutnya memaparkan active. Jika ia memaparkan failed, journalctl -u dormice -n 50 mengandungi sebabnya, dan kegagalan untuk bermula biasanya berpunca daripada prasyarat swap atau gVisor dan bukannya daemon itu sendiri.

Pemasang juga meletakkan Caddy pada pelayan, jadi periksa port yang sedang mendengar sebelum anda menganggap kerja firewall telah selesai.

sudo ss -lntp

Daemon mengikat 127.0.0.1:3676 dan tiada tetapan untuk mengubahnya, mengikut reka bentuk. Mencapainya dari komputer riba anda adalah tindakan sengaja, dan cara paling mudah adalah melalui SSH tunnel.

ssh -L 3676:127.0.0.1:3676 root@your-server

Dengan tunnel dibuka, http://127.0.0.1:3676/console pada komputer riba anda ialah konsol web. Log masuk dengan token sekali dan ia akan menjadi session cookie httpOnly, jadi token itu sendiri tidak pernah disimpan di tempat yang boleh dibaca oleh halaman web. Halaman Connect di sana memaparkan snippet klien untuk disalin dan ditampal yang telah dihalakan ke endpoint anda sendiri.

Mencipta sandbox dan melaksanakan kod di dalamnya

Satu operasi mencipta sandbox: acquire. Ia bersifat idempoten, jadi kunci yang sama sentiasa mengembalikan sandbox yang sama, sama ada mencipta, mengejutkan, memulakan atau memulihkannya mengikut keperluan. Setiap kata kerja lain akan membalas 404 untuk kunci yang tidak pernah ditemuinya. CLI dor tidak mempunyai kata kerja acquire, jadi sandbox pertama anda datang daripada konsol atau pustaka klien.

Laluan konsol adalah yang terpantas. Buka /console melalui tunnel dan cipta sandbox bernama my-agent. CLI kemudiannya akan berfungsi pada sandbox tersebut.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

dor sandbox ls menyenaraikan setiap sandbox berserta status kitaran hayatnya, iaitu cara anda memantau peralihan daripada aktif kepada beku. dor sandbox exec mencetak versi Python 3.12, kerana imej stok adalah Ubuntu 24.04 dengan Python 3.12, Node 24, git dan ripgrep yang telah dipasang. Ralat pengesahan sebaliknya bermakna baris token yang anda salin menyertakan nama pemboleh ubah.

Fail dipindahkan dengan dor sandbox push my-agent ./script.py, yang mendarat di /home/user/script.py, dan dor sandbox pull my-agent notes.txt membawa fail kembali. Kata kerja fail natif dihadkan pada 16 MiB setiap fail, manakala permukaan fail E2B melakukan penstriman dan membiarkan kuota cakera sandbox menjadi satu-satunya had.

Memusnahkan (destroying) adalah satu-satunya kata kerja yang menyebabkan kehilangan data, dan ia juga merupakan contoh yang adil bagi usia projek ini: README utama dan kemahiran ejen yang disertakan kedua-duanya mendokumentasikan dor sandbox destroy <key>, manakala README pakej CLI mendokumentasikan dor sandbox release <key>. Jalankan dor sandbox --help pada binaan anda sendiri dan percayai arahan tersebut.

Halakan kod E2B sedia ada anda ke pelayan sendiri

Inilah sebab mengapa perkara ini penting. Pakej e2b rasmi daripada npm, tanpa diubah suai, berkomunikasi dengan Dormice. Jalankan arahan ini daripada komputer riba anda dengan terowong SSH dibuka, supaya tiada perkhidmatan baharu yang mendengar pada pelayan.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

Jalankan yang berjaya akan memaparkan kod keluar 0 dan 42. Kunci API ialah token Dormice anda dengan awalan e2b_ di hadapannya, iaitu format yang dijangkakan oleh lapisan keserasian.

Keserasian ini bukanlah sekadar stub. Penstriman stdout dan stderr, arahan latar belakang, PTY interaktif, URL muat naik dan muat turun yang ditandatangani, pemantauan direktori serta proksi port semuanya diuji melalui pakej rasmi terhadap daemon Docker dan gVisor sebenar oleh suite hujung-ke-hujung projek ini. Beberapa perbezaan perlu diambil perhatian sebelum anda memindahkan sebarang beban kerja sebenar:

• Binaan templat tidak dilaksanakan. Templat ialah imej Docker yang anda bina sendiri dan daftarkan dengan dor template add, dan Sandbox.create('name') akan menyelesaikannya. Nama yang tidak berdaftar akan mengembalikan ralat 404 dan bukannya berpura-pura wujud.
• Sandbox yang dicipta melalui antara muka E2B mempunyai tarikh akhir sebenar, kerana semantik E2B memerlukannya. Tarikh akhir tidak pernah dikenakan pada sandbox yang dicipta melalui API asli.
• Sandbox yang dibekukan mengekalkan prosesnya dan menyambungkannya semula di tengah jalan, jadi fungsi jeda dan sambung di sini bukanlah fungsi henti dan mula sejuk (cold start) yang mungkin biasa anda gunakan.

Perkara yang dihalang oleh sandbox, dan perkara yang tidak dihalang

gVisor memintas panggilan sistem (system calls) kontena dalam ruang pengguna (userspace) dan mengendalikannya sendiri, jadi kod dalam sandbox tidak berhubung terus dengan kernel hos anda. Di dalam sandbox, segala-galanya berjalan sebagai pengguna tanpa keistimewaan, uid 1000. Gabungan ini mengendalikan kes biasa: skrip yang dijana yang menjalankan rm -rf /, memenuhi cakera, atau melakukan fork sehingga sesuatu terhenti, hanya akan merosakkan sandboxnya sendiri dan terhenti di situ.

Berikut adalah perkara yang tidak dihalang olehnya. Setiap perkara ini adalah tanggungjawab anda.

• Sandbox mempunyai rangkaian keluar yang berfungsi. Kod yang dijana boleh memuat turun apa sahaja yang ia mahu dan menghantar apa sahaja yang ia temui. Pengukuhan rangkaian (network hardening) pemasang merangkumi dua perkara khusus: ia menggugurkan (drop) trafik kontena ke perkhidmatan metadata awan pada 169.254.0.0/16, iaitu tempat awan memberikan kelayakan instans kepada sesiapa sahaja yang boleh mencapainya, dan ia mematikan trafik antara kontena dengan "icc": false dalam daemon.json Docker. Tiada perkara lain yang disekat. Baca sudo iptables -S DOCKER-USER dan tambah peraturan DROP anda sendiri untuk julat peribadi yang tidak sepatutnya dicapai oleh sandbox.
• Docker memasukkan peraturannya sendiri sebelum firewall anda, jadi port kontena yang diterbitkan boleh menjawab daripada internet walaupun ufw menyatakan ia ditutup. Baca cara Docker menerbitkan port melepasi ufw dan asas firewall ufw untuk VPS sebelum anda mendedahkan apa-apa pada hos ini.
• gVisor ialah kernel ruang pengguna, bukan hypervisor. Itu adalah pertukaran yang disengajakan, kerana pembekuan (freezing) memerlukan sandbox menjadi proses, dan mewajibkan KVM akan menghalang perkara itu daripada dipasang di mana-mana. Jika model ancaman anda menuntut virtualisasi perkakasan, gunakan pengasingan kelas Firecracker dan terima kos operasi yang datang bersamanya.
• Token API ialah keseluruhan sempadan keselamatan pada bahagian klien. Sesiapa yang memegang DORMICE_API_TOKEN boleh mencipta, membaca, dan memusnahkan setiap sandbox pada mesin tersebut. Berikan proses ejen itu pengguna dengan keistimewaan paling rendah pada VPS sendiri dan layan token tersebut seperti anda melayan kunci SSH. Tabiat daripada menjalankan Claude Code dengan selamat pada VPS boleh dipindahkan secara terus.

Daemon itu sendiri berjalan sebagai root pada hos anda. gVisor melindungi hos daripada kod di dalam sandbox, dan tiada apa yang melindungi hos daripada daemon atau daripada sesiapa yang memegang tokennya. Jadi, mesin yang menjalankan Dormice mestilah mesin yang hanya melakukan tugas itu sahaja. Jika ejen anda juga mencapai alatan melalui MCP (model context protocol), simpan pelayan MCP tersebut pada VPS yang berasingan atas sebab yang sama.

Berapakah jumlah sandbox yang boleh dimuatkan dalam 4 GB dan 8 GB?

Dua perkara menggunakan memori: garis dasar hos itu sendiri, dan set kerja bagi setiap sandbox yang sedang aktif. Peruntukkan kira-kira 1 GB untuk Ubuntu, Docker dan daemon, kemudian bahagikan baki memori dengan penggunaan sebenar satu sandbox anda. Sandbox yang menjalankan skrip Python untuk membaca beberapa fail menggunakan sekitar 200 hingga 300 MiB. Sandbox yang menjalankan pengkompil atau suite ujian penuh boleh melebihi satu gibibyte.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

VPS 4 GB boleh memuatkan kira-kira 6 sandbox yang aktif serentak jika setiap satunya menggunakan 512 MiB, atau 3 jika setiap satunya menggunakan satu gibibyte penuh. VPS 8 GB meningkatkan jumlah tersebut kepada 14 dan 7. Ini adalah had maksimum untuk kerja serentak, dan ia merupakan pengiraan aritmetik bukannya penanda aras, jadi pantau free -m semasa beban kerja anda berjalan.

Sandbox yang dibekukan (frozen) dihadkan oleh swap dan bukannya RAM, yang merupakan tujuan utama reka bentuk ini. Sandbox beku yang asalnya menggunakan satu gibibyte akan mengekalkan jumlah tersebut dalam swap dan hampir tiada data dalam memori residen, jadi fail swap lalai 16 GB pemasang boleh menampung kira-kira 16 sandbox. Melebihi jumlah itu, ia perlu mencapai tahap dihentikan (stopped), di mana ia hanya menggunakan ruang cakera. Cakera adalah had sebenar dalam jangka masa panjang: setiap sandbox mengekalkan sistem failnya sendiri, dan beberapa dozen ejen yang masing-masing membawa direktori node_modules akan memenuhi volum kecil jauh lebih awal sebelum memori menjadi isu utama.

Bekukan, hentikan, arkibkan: kawalan kitaran hayat

Nilai lalai adalah membeku selepas 10 minit melahu, berhenti selepas 3 hari, dan mengarkib selepas 7 hari apabila pengarkiban dikonfigurasikan. Menetapkan stopAfterSeconds kepada null memberikan anda ejen residen: ia mungkin membeku apabila melahu, dan ia tidak akan melakukan cold start.

Pengarkiban adalah pilihan, dan daemon akan melaporkannya dengan telus. Tetapkan empat pemboleh ubah DORMICE_S3_* dan cakera sandbox yang dihentikan akan dimampatkan dengan tar dan zstd, dihantar ke mana-mana bucket yang serasi dengan S3, dan dibebaskan secara setempat. Bucket tersebut boleh menjadi bucket MinIO yang anda hoskan sendiri pada mesin anda yang lain. Biarkan pemboleh ubah tidak ditetapkan dan sandbox akan kekal dalam keadaan berhenti selama-lamanya, dan polisi yang meminta untuk mengarkib akan ditolak dan bukannya diabaikan secara senyap. Pemulihan dapat dilihat dan bukannya senyap: acquire seterusnya akan menjawab serta-merta dengan status pemulihan dan nilai kemajuan, kemudian bertukar kepada sedia sebaik sahaja cakera kembali tersedia.

Patutkah anda bergantung padanya sekarang?

Jawapan terus terang: jangan gunakannya untuk apa-apa yang anda tidak boleh bina semula. Komit pertama dalam repositori bertarikh 8 Julai 2026. Setakat 4 Ogos 2026, ia menunjukkan 446 bintang, 37 fork, lesen Apache-2.0, dan tiada keluaran (release) yang ditanda langsung. Baris status dalam README sendiri menyatakan tiada apa-apa di situ yang sedia untuk pengeluaran (production).

Gabungan itu membawa bentuk risiko yang khusus. Kod tersebut berubah di bawah anda kerana pemasang menjejaki main. Antara muka masih belum stabil, itulah sebabnya kata kerja delete mempunyai dua nama berbeza dalam dua fail dalam repositori yang sama. Dan projek yang berusia empat minggu boleh berhenti begitu sahaja, memandangkan tiada klausa lesen yang mewajibkan sesiapa untuk meneruskannya.

Apa yang menjadikan risiko ini boleh ditanggung ialah keserasian E2B. Aplikasi anda berhubung dengan protokol yang mempunyai pelaksanaan (implementation) dihoskan di belakangnya, jadi jika Dormice terhenti, anda hanya perlu menukar dua URL dan terus bekerja. Tulis ejen anda berdasarkan permukaan E2B dan bukannya API asli, supaya anda mengekalkan jalan keluar tersebut. Pakej @dormice/sdk asli juga belum ada di npm, jadi menggunakannya bermakna anda perlu membina daripada repositori, yang merupakan sebab kedua untuk bermula dengan laluan yang serasi.

Jalankan ia di tempat yang anda mampu untuk kehilangannya. Bina semula hos daripada skrip, simpan token di luar setiap prompt dan setiap komit, serta tarik apa-apa yang berharga keluar daripada sandbox mengikut jadual sandaran anda sendiri.

FAQ

Adakah Dormice sedia untuk pengeluaran?

Tidak, dan projek ini sendiri menyatakan perkara tersebut. Baris status dalam README menyatakan bahawa tiada apa-apa di situ yang sedia untuk pengeluaran lagi, dan setakat 4 Ogos 2026 repositori tersebut baru berusia kira-kira empat minggu tanpa tag git dan tanpa sebarang releases, jadi tiada nombor versi untuk disematkan. Pemasang akan mengklon cawangan main, yang bermaksud setiap pelaksanaan memberikan anda commit terkini. Rekodkan git -C /opt/dormice rev-parse HEAD selepas setiap pemasangan, dan simpan sebarang data berharga di luar sandbox.

Bagaimanakah Dormice berbeza daripada memberikan ejen saya VM pakai buang?

VM pakai buang ialah mesin dengan SSH yang anda cipta untuk satu sesi dan dipadamkan selepas itu. Dormice ialah API pelaksanaan: program anda memanggil acquire, kemudian exec, dan mendapatkan stdout serta kod keluar kembali, tanpa sesi shell di tengah-tengahnya. VM sesuai untuk manusia atau ejen yang mahukan sebuah komputer sepenuhnya untuk tempoh tertentu. Dormice sesuai untuk aplikasi yang menjalankan kod yang dijana berkali-kali sehari dan tidak mahu proses penyediaan serta pembersihan mesin bagi setiap pelaksanaan.

Adakah SDK E2B rasmi benar-benar berfungsi tanpa perubahan kod?

Ya, dengan perubahan konfigurasi. Halakan apiUrl dan sandboxUrl kepada /e2b/api dan /e2b/envd pada daemon anda, dan berikan token Dormice anda dengan awalan e2b_ sebagai kunci API. Pelaksanaan arahan, sesi PTY, pemindahan fail, URL yang ditandatangani dan proksi port semuanya dilindungi oleh suite hujung-ke-hujung projek yang berjalan melalui pakej rasmi. Pembinaan templat merupakan jurang yang ketara: e2b template build tidak dilaksanakan, jadi templat ialah imej docker yang anda bina dan daftarkan dengan dor template add.

Berapa banyak sandbox yang muat pada VPS 4 GB?

Kira-kira 6 yang aktif pada masa yang sama jika setiap sandbox menggunakan 512 MiB, atau 3 jika setiap satu menggunakan satu gibibyte penuh, selepas menempah kira-kira 1 GB untuk sistem pengendalian, Docker dan daemon. Sandbox yang dibekukan (frozen) dihadkan oleh swap sebaliknya, jadi fail swap lalai 16 GB oleh pemasang boleh menampung sekitar 16 sandbox yang masing-masing memegang satu gibibyte. Ukur kapasiti anda sendiri dengan free -m di bawah beban sebenar, kerana sandbox yang menjalankan suite ujian menggunakan beberapa kali ganda memori berbanding sandbox yang menjalankan skrip kecil.

Mengapa Dormice memerlukan vm.swappiness ditetapkan kepada 100?

Membekukan sandbox bermaksud menolak memori terbiarnya ke dalam swap. gVisor memegang memori sandbox sebagai memori kongsi, dan kernel Linux tidak akan melakukan swap pada memori kongsi pada nilai swappiness lalai, jadi pada nilai lalai, pembekuan tidak menuntut semula apa-apa dan sandbox tersebut terus menggunakan memori penuh. Projek ini mengukur 0 bait dituntut semula pada nilai lalai dan 99.5 peratus dituntut semula pada 100. Semak nilai berkesan dengan sysctl vm.swappiness dan bukannya membaca fail konfigurasi, kerana sesetengah imej awan menghantar nilai 0.