Paano Mag-self-host ng Dormice para sa Agent Sandbox

Ano ang Dormice, at ano ang hindi ito

Ang Dormice ay isang self-hosted agent sandbox: isang daemon sa Linux VPS na pagmamay-ari mo, na tinatawagan ng agent code mo sa pamamagitan ng HTTP upang magpatakbo ng untrusted code sa loob ng isang isolated container. Humihingi ang program mo ng sandbox ayon sa pangalan, ibinabalik ang parehong sandbox anuman ang dati nitong state, nagpapatakbo ng command sa loob nito, at binabasa ang output. Ang sandbox ay isang programmatic resource, hindi isang machine na nilo-loginan mo.

Iba ito sa pagbibigay sa isang agent ng buong computer. Ang isang pansamantalang VM para sa coding agent ay isang box na nilo-loginan mo gamit ang SSH, hinahayaang sirain ng agent, at pagkatapos ay dine-delete. Isang level sa ibaba ang Dormice: ito ang execution API na tinatawagan ng program mo kapag mayroon na itong code at kailangan nito ng ligtas na lugar para patakbuhin iyon. Gamitin ang throwaway VM kapag buong machine ang unit of work. Gamitin ang Dormice kapag isang exec call ang unit of work at gusto mong magpatakbo ng isang daan sa mga ito bawat araw nang hindi nangangailangan ng isang daang VM.

Tinatawag ng project ang sarili nito na E2B compatible. Ang E2B ay isang hosted sandbox service na ini-import na ng maraming agent framework sa client library ng mga ito. Ibinibigay ng Dormice ang parehong protocol gamit ang sarili nitong URL prefixes, kaya patuloy na gagana ang application na ginawa para sa opisyal na e2b package kapag itinuro mo ito sa sarili mong box. Hindi kailangang baguhin ang application code. Dalawang URL at isang API key prefix lamang ang kailangang baguhin.

Ano ang ibig sabihin sa aktuwal na paggamit ng “SQLite ng agent sandboxes”

Ang SQLite ay database na ini-embed mo sa halip na isang service na ikaw ang nagpapatakbo, at direktang ginagamit ng Dormice ang paghahambing na ito. Isang daemon, isang SQLite file para sa ledger, at isang TCP port. Walang Kubernetes, hiwalay na database, o scheduler. Nagla-lock ang daemon sa tabi ng ledger nito at tumatangging magsimula kapag hindi maaaring magkasama ang ledger at ang machine na nakita nito. Kaya hindi maaaring mangyari nang tahimik ang split brain. Isang machine ang saklaw ng design. Kung kailangan mo ng fleet sa maraming host, malinaw na sinasabi ng README na iba ang dapat mong piliin, at dapat mo itong sundin.

Tumutukoy naman ang ikalawang bahagi ng ideya sa gastos. Sinisingil ka ng hosted sandbox sa bawat segundo na umiiral ito, kaya likas na disposable ang hosted sandboxes. Tumatakbo ang Dormice sa hardware na binabayaran mo na, kaya permanente ang mga sandbox nito at mas mura habang mas matagal silang hindi ginagamit. Unti-unting nagco-cool down ang isang sandbox: active, pagkatapos ay frozen, stopped, at archived. Ibabalik ito ng anumang acquire mula sa rung na naabot nito.

Ang freezing ang bahaging kailangang maunawaan, dahil ito ang nagpapahintulot na panatilihing permanente ang sandbox ng bawat agent nang abot-kaya. Mga sariling inilathalang figure ito ng proyekto, na sinukat sa hardware nito at hindi sa iyo.

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

Ang idle sandbox na gumagamit ng 1024 MiB na memory ay bumababa sa 5 MiB resident memory kapag na-freeze, at bumabalik sa loob ng humigit-kumulang 50 ms. Sinususpinde at nire-resume ang mga process sa parehong estado, kaya napapanatili ng long-lived agent ang shell state at hindi pa tapos na trabaho nito habang naka-freeze. I-reproduce muna ito sa sarili mong host bago ka magplano ng capacity batay rito.

Mga kailangan ng host bago mag-install

Ang host ay dapat Ubuntu o Debian na tumatakbo sa x86_64, at kailangan ng installer ang root. Pinananatili ng daemon ang root sa runtime dahil nagsasagawa ito ng loop mounts at nagsusulat sa cgroups.

Tumatakbo ang mga sandbox sa Docker gamit ang gVisor (isang container runtime na naglalagay ng userspace kernel sa pagitan ng container at host kernel). Nagbibigay ito ng runsc runtime na ginagamit ng bawat sandbox. Node 22 o mas bago ang nagpapatakbo sa daemon. May sarili nang kopya ang installer, kaya hindi nito binabago ang Node ng system.

Dapat may swap, at kailangang 100 ang vm.swappiness. Hindi ito payo sa tuning; functional requirement ito. Gumagana ang freezing sa pamamagitan ng pagtulak sa memory ng idle sandbox papunta sa swap. Pinananatili ng gVisor ang memory ng sandbox bilang shared memory, at hindi isi-swap ng kernel ang shared memory kapag nasa default na swappiness. Sinukat ng project ang 0 bytes na nare-reclaim sa default na value at 99.5 percent na nare-reclaim kapag 100. Suriin ang value na aktuwal na ginagamit ng kernel, dahil may ilang cloud image na nagse-set ng vm.swappiness = 0 sa isang file na hindi mo karaniwang maiisip basahin.

sysctl vm.swappiness
swapon --show

Dapat mag-print ang sysctl vm.swappiness ng vm.swappiness = 100, at dapat maglista ang swapon --show ng isang swapfile. Kung 0 ang output ng swappiness, walang epekto ang bawat freeze at patuloy kang magbabayad ng buong memory para sa bawat idle sandbox.

Pag-install ng Dormice sa Ubuntu

Ang dokumentadong paraan ng pag-install ay isang pipe papunta sa bash:

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

Kunin muna ito at basahin bago patakbuhin. Tumatakbo ang script na ito bilang root at binabago nito ang host: nag-i-install ito ng Docker kung wala pa ito, dina-download ang gVisor at Caddy na may checksum verification, gumagawa ng swapfile, nagsusulat ng systemd units, at nagdaragdag ng firewall rules.

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

Itinatakda ng --swap-gb ang laki ng swapfile at ang default nito ay 16, na malaking bahagi ng disk para ilaan sa isang maliit na VPS. Inililipat ng --mirror cn ang mga download sa mga mirror na naaabot mula sa mainland China. Kapag muling pinatakbo ang installer, ina-upgrade nito ang code at inaayos ang mga drift, pero hindi nito kailanman nire-rotate ang iyong API token.

Napupunta ang code sa /opt/dormice, ang configuration sa /etc/dormice/env, ang sandbox data sa /var/lib/dormice, at ang mga command na dormice at dor sa /usr/local/bin. Ginagawa ng installer ang API token habang nag-i-install at isinusulat ito sa /etc/dormice/env na may mode 600.

Walang tagged release na pagbabasehan sa pag-install. Noong 4 August 2026, walang git tags at GitHub releases ang repository, kaya kino-clone ng installer ang main at makukuha mo ang anumang na-commit noong umagang iyon. Kaya ang pag-pin ng version ay nangangahulugang itala ang commit na aktuwal mong na-install.

git -C /opt/dormice rev-parse HEAD

I-save ang hash na iyon kasama ng iyong deploy notes. Kapag may nasira sa upgrade, ang commit na iyon lang ang paraan para makabalik ka, dahil walang version number na maaari mong tukuyin.

Tinatapos ng installer ang proseso sa pagpapatakbo ng dor doctor, isang read-only host check na nagbo-boot ng aktuwal na gVisor containers upang patunayang gumagana ang runtime sa halip na umasa sa package list. Patakbuhin itong muli kapag hindi maayos ang daemon.

sudo dor doctor
systemctl is-active dormice

Dapat mag-print ang systemctl is-active dormice ng active. Kung failed ang mai-print nito, nasa journalctl -u dormice -n 50 ang dahilan, at karaniwang swap o gVisor prerequisite ang sanhi ng failed start, hindi ang daemon mismo.

Inilalagay din ng installer ang Caddy sa server, kaya tingnan muna kung ano ang nakikinig bago mong sabihing tapos na ang firewall configuration.

sudo ss -lntp

Nagbi-bind ang daemon sa 127.0.0.1:3676 at wala itong setting para baguhin iyon, ayon sa disenyo. Ang pag-abot dito mula sa iyong laptop ay sinadyang hakbang, at ang pinakasimpleng paraan ay SSH tunnel.

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

Kapag bukas na ang tunnel, ang http://127.0.0.1:3676/console sa iyong laptop ang web console. Mag-sign in gamit ang token nang isang beses at magiging httpOnly session cookie ito, kaya hindi kailanman naiimbak ang token mismo sa lugar na mababasa ng page. Sa Connect page, makikita ang mga client snippet na maaaring i-copy at i-paste at nakaturo na sa sarili mong endpoint.

Gumawa ng sandbox at magpatakbo ng code dito

Isang operation ang gumagawa ng sandbox: acquire. Idempotent ito, kaya palaging ibinabalik ng parehong key ang parehong sandbox. Gagawa ito ng sandbox, gigisingin ito, sisimulan, o ire-restore kung kinakailangan. Ang lahat ng iba pang verb ay nagbabalik ng 404 para sa key na hindi pa nito nakikita. Walang acquire verb ang dor CLI, kaya ang unang sandbox mo ay dapat manggaling sa console o sa isang client library.

Pinakamabilis gamitin ang console route. Buksan ang /console sa pamamagitan ng tunnel at gumawa ng sandbox na may pangalang my-agent. Pagkatapos, magagamit na ito ng CLI.

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'

Inililista ng dor sandbox ls ang bawat sandbox kasama ang lifecycle state nito. Sa ganitong paraan, mamomonitor mo kapag bumaba ang isang sandbox mula active patungong frozen. Nagpi-print ang dor sandbox exec ng Python 3.12 version, dahil ang stock image ay Ubuntu 24.04 na may naka-install nang Python 3.12, Node 24, git, at ripgrep. Ang authentication error ay nangangahulugang naisama sa kinopya mong token line ang variable name.

Inililipat ang mga file gamit ang dor sandbox push my-agent ./script.py, na naglalagay sa mga ito sa /home/user/script.py, at ibinabalik naman ng dor sandbox pull my-agent notes.txt ang isang file. Ang native file verbs ay may limitasyong 16 MiB bawat file. Samantala, nag-i-stream ang E2B file surface, kaya ang disk quota lamang ng sandbox ang nagiging limitasyon.

Ang destroy ang tanging verb na nagbubura ng data. Magandang halimbawa rin ito ng edad ng project: parehong nagdo-document ang pangunahing README at ang bundled agent skill ng dor sandbox destroy <key>, habang dor sandbox release <key> naman ang nasa README ng CLI package. Patakbuhin ang dor sandbox --help sa sarili mong build at iyon ang sundin.

Ituro ang dati mong E2B code sa sarili mong server

Ito ang dahilan kung bakit ito mahalaga. Ang opisyal na e2b package mula sa npm, na walang binago, ay kumokonekta sa Dormice. Patakbuhin ito mula sa iyong laptop habang bukas ang SSH tunnel, upang walang bagong proseso na makinig sa server.

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

Sa matagumpay na pagtakbo, lalabas ang exit code 0 at 42. Ang API key ay ang iyong Dormice token na may e2b_ prefix sa unahan nito. Ito ang format na inaasahan ng compatibility layer.

Hindi stub ang compatibility. Sinusubukan ng end-to-end suite ng proyekto ang streaming ng stdout at stderr, background commands, interactive PTY, signed upload at download URLs, directory watching, at port proxy sa pamamagitan ng opisyal na package laban sa aktuwal na Docker at gVisor daemon. May ilang pagkakaiba na dapat isaalang-alang bago ka mag-migrate ng anumang aktuwal na workload:

• Hindi implemented ang template builds. Ang template ay docker image na ikaw mismo ang nagbu-build at nagrerehistro gamit ang dor template add, at nire-resolve ito ng Sandbox.create('name'). Ang hindi rehistradong pangalan ay nagbabalik ng 404 sa halip na magpanggap na umiiral.
• Ang mga sandbox na ginawa sa pamamagitan ng E2B surface ay nagkakaroon ng aktuwal na deadline dahil kinakailangan ito ng E2B semantics. Hindi kailanman ipinapataw ang deadline sa mga sandbox na ginawa sa pamamagitan ng native API.
• Pinananatili ng frozen sandbox ang mga proseso nito at ipinagpapatuloy ang mga ito mula sa kalagitnaan ng kanilang pagtakbo. Kaya ang pause at resume dito ay hindi katulad ng stop at cold start na maaaring nakasanayan mo.

Ano ang hinaharang ng sandbox at ano ang hindi nito hinaharang

Ini-intercept ng gVisor ang system calls ng container sa userspace at ito mismo ang nagseserbisyo sa mga ito. Dahil dito, hindi direktang nakikipag-ugnayan sa host kernel ang code sa sandbox. Sa loob ng sandbox, tumatakbo ang lahat bilang unprivileged user na may uid 1000. Sapat ang kombinasyong ito para sa karaniwang sitwasyon: kapag nagpatakbo ang generated script ng rm -rf /, pinuno ang disk, o paulit-ulit na nag-fork hanggang may mag-crash, ang sarili nitong sandbox ang masisira at doon ito titigil.

Narito ang mga bagay na hindi nito hinaharang. Ikaw ang kailangang humawak sa bawat isa.

• May gumaganang outbound network ang sandbox. Maaaring mag-download ang generated code ng kahit ano at i-post ang anumang makita nito. Dalawang partikular na bagay lang ang saklaw ng network hardening ng installer: hinaharangan nito ang container traffic papunta sa cloud metadata service sa 169.254.0.0/16, kung saan ipinapasa ng cloud ang instance credentials sa anumang makakaabot dito, at isinasara nito ang container-to-container traffic gamit ang "icc": false sa daemon.json ng Docker. Wala nang iba pang hina-block. Basahin ang sudo iptables -S DOCKER-USER at magdagdag ng sarili mong DROP rules para sa mga private range na walang dahilan para maabot ng sandbox.
• Inuuna ng Docker ang sarili nitong rules bago ang firewall mo. Dahil dito, maaaring sumagot mula sa internet ang isang published container port kahit sinasabi ng ufw na sarado ito. Basahin ang kung paano nagpa-publish ang Docker ng ports lampas sa ufw at ang mga batayan ng ufw firewall para sa isang VPS bago ka mag-expose ng anuman sa host na ito.
• Ang gVisor ay userspace kernel, hindi hypervisor. Sadyang ganito ang trade-off dahil kailangang mga process ang mga sandbox para magawa ang freezing, at mapipigilan ng pag-require ng KVM ang pag-install nito kahit saan. Kung nangangailangan ang threat model mo ng hardware virtualisation, gumamit ng Firecracker-class isolation at tanggapin ang operational cost na kasama nito.
• Ang API token ang buong security boundary sa client side. Ang anumang may hawak ng DORMICE_API_TOKEN ay maaaring gumawa, magbasa, at mag-delete ng bawat sandbox sa machine. Bigyan ang agent process ng sarili nitong least privilege user sa VPS at ituring ang token tulad ng pagtrato mo sa SSH key. Direktang naaangkop dito ang mga kasanayan mula sa ligtas na pagpapatakbo ng Claude Code sa isang VPS.

Tumatakbo bilang root sa host mo ang daemon mismo. Pinoprotektahan ng gVisor ang host mula sa code sa loob ng sandbox, ngunit walang nagpoprotekta sa host mula sa daemon o sa sinumang may hawak ng token nito. Kaya ang machine na nagpapatakbo ng Dormice ay dapat isang machine na ito lang ang ginagawa. Kung ina-access din ng agent mo ang mga tool sa pamamagitan ng MCP (model context protocol), panatilihin ang mga iyon sa hiwalay na VPS para sa MCP servers sa parehong dahilan.

Ilang sandbox ang kasya sa 4 GB at 8 GB?

Dalawang bagay ang kumokonsumo ng memory: ang baseline ng host mismo at ang working set ng bawat sandbox na kasalukuyang aktibo. Maglaan ng humigit-kumulang 1 GB para sa Ubuntu, Docker, at daemon, pagkatapos ay hatiin ang natitirang memory sa aktuwal na gamit ng isang sandbox. Ang sandbox na nagpapatakbo ng Python script na nagbabasa ng ilang file ay karaniwang nasa 200 hanggang 300 MiB. Ang sandbox na nagpapatakbo ng compiler o buong test suite ay maaaring lumampas sa isang 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
  }
]

Ang 4 GB VPS ay kayang magpatakbo ng humigit-kumulang 6 sandbox nang sabay-sabay kung 512 MiB ang gamit ng bawat isa, o 3 kung isang buong gibibyte ang gamit ng bawat isa. Sa 8 GB VPS, magiging 14 at 7 ang mga bilang. Mga ceiling ito para sa concurrent work. Arithmetic ang mga ito, hindi benchmark, kaya i-monitor ang free -m habang tumatakbo ang sarili mong load.

Swap, sa halip na RAM, ang naglilimita sa mga frozen sandbox. Ito ang pangunahing layunin ng disenyo. Ang frozen sandbox na gumagamit ng isang gibibyte ay mananatiling gumagamit ng humigit-kumulang ganoon karaming swap at halos walang resident memory. Kaya ng default na 16 GB swapfile ng installer na mag-park ng humigit-kumulang 16 sandbox. Pag lampas doon, kailangan nilang mapunta sa stopped rung, kung saan disk lang ang ginagamit nila. Ang disk ang tunay na pangmatagalang limitasyon dito: pinananatili ng bawat sandbox ang filesystem nito, at mapupuno ng ilang dosenang agent na may sariling node_modules directory ang maliit na volume bago pa maging mahalaga ang memory.

Freeze, stop, archive: mga setting para sa lifecycle

Ang default ay mag-freeze pagkalipas ng 10 minutong idle, mag-stop pagkalipas ng 3 araw, at mag-archive pagkalipas ng 7 araw kapag naka-configure ang archiving. Kapag itinakda ang stopAfterSeconds sa null, magkakaroon ka ng resident agent: maaari itong mag-freeze kapag idle, pero hindi ito kailanman gagawa ng cold start.

Opsyonal ang archiving, at malinaw itong ipinapaalam ng daemon. Itakda ang apat na DORMICE_S3_* variable, at ang disk ng isang stopped sandbox ay ipa-package gamit ang tar at zstd, ipapadala sa anumang S3-compatible bucket, at aalisin sa lokal na storage. Ang bucket na iyon ay maaaring isang MinIO bucket na ikaw mismo ang nagho-host sa isa mo pang machine. Kapag hindi itinakda ang mga variable, mananatiling stopped ang mga sandbox, at tatanggihan ang policy na humihiling ng archiving sa halip na tahimik itong balewalain. Nakikita ang proseso ng restore sa halip na mangyari nang tahimik: sasagot agad ang susunod na acquire na may restoring status at progress value, pagkatapos ay magiging ready kapag naibalik na ang disk.

Dapat na ba ninyo itong pagkatiwalaan?

Diretsong sagot: hindi pa para sa anumang hindi ninyo kayang i-rebuild. Ang unang commit sa repository ay may petsang 8 July 2026. Noong 4 August 2026, mayroon itong 446 stars, 37 forks, Apache-2.0 licence, at wala pa itong anumang tagged release. Ayon mismo sa status line ng README, wala pa roon ang handa para sa production.

May partikular na anyo ang panganib na dulot ng kombinasyong ito. Nagbabago ang code habang ginagamit ninyo ito dahil sinusubaybayan ng installer ang main. Hindi pa stable ang interface. Ito mismo ang dahilan kung bakit dalawang magkaibang pangalan ang delete verb sa dalawang file ng iisang repository. Maaari ring basta huminto ang isang apat na linggong project, dahil walang clause sa licence na nag-oobliga sa sinuman na ipagpatuloy ito.

Mas kayang pamahalaan ang panganib dahil compatible ito sa E2B. Nakikipag-usap ang application ninyo sa isang protocol na may hosted implementation, kaya kung huminto ang Dormice, dalawang URL lang ang babaguhin ninyo upang magpatuloy. I-develop ang agent ninyo batay sa E2B surface sa halip na sa native API para mapanatili ninyo ang opsyong ito. Wala pa rin sa npm ang native @dormice/sdk package, kaya kailangan itong i-build mula sa repository. Isa pa itong dahilan para magsimula sa compatible path.

Patakbuhin ito sa environment na kaya ninyong mawala. I-rebuild ang host mula sa isang script, huwag ilagay ang token sa anumang prompt o commit, at ilabas ang anumang mahalaga mula sa mga sandbox ayon sa sarili ninyong backup schedule.

FAQ

Handa na ba ang Dormice para sa production?

Hindi, at malinaw itong sinasabi mismo ng project. Nakasaad sa status line ng README na wala pang handa para sa production, at noong 4 August 2026, humigit-kumulang apat na linggo pa lamang ang repository, walang git tags, at walang releases. Dahil dito, walang version number na maaaring i-pin. Kino-clone ng installer ang main branch, kaya bawat run ay kumukuha ng pinakabagong commit. Itala ang git -C /opt/dormice rev-parse HEAD pagkatapos ng bawat install, at panatilihin sa labas ng sandboxes ang anumang mahalagang data.

Paano naiiba ang Dormice sa pagbibigay sa agent ko ng disposable VM?

Ang disposable VM ay isang machine na may SSH na ginagawa mo para sa isang session at dine-delete pagkatapos. Ang Dormice ay isang execution API: tinatawag ng program mo ang acquire, pagkatapos ay exec, at ibinabalik nito ang stdout at exit code nang walang shell session sa pagitan. Ang VM ay angkop para sa human o agent na nangangailangan ng buong computer sa loob ng isang panahon. Ang Dormice ay angkop para sa application na nagpapatakbo ng generated code nang maraming beses bawat araw at ayaw ng setup at teardown na katumbas ng isang buong machine sa bawat run.

Talaga bang gumagana ang official E2B SDK nang walang pagbabago sa code?

Oo, pero kailangan ng mga pagbabago sa configuration. Ituro ang apiUrl at sandboxUrl sa /e2b/api at /e2b/envd sa daemon mo, at ipasa ang Dormice token na may e2b_ prefix bilang API key. Saklaw ng project’s end-to-end suite na tumatakbo sa official package ang command execution, PTY sessions, file transfer, signed URLs, at port proxy. Ang template building ang pangunahing hindi pa saklaw: hindi pa implemented ang e2b template build, kaya ang template ay isang docker image na bina-build at nirerehistro mo gamit ang dor template add.

Ilang sandbox ang kasya sa isang 4 GB VPS?

Humigit-kumulang 6 ang maaaring manatiling gising nang sabay-sabay kung 512 MiB ang gamit ng bawat sandbox, o 3 kung buong gibibyte ang gamit ng bawat isa, matapos maglaan ng humigit-kumulang 1 GB para sa operating system, Docker, at daemon. Swap ang naglilimita sa frozen sandboxes, kaya sa default na 16 GB swapfile ng installer, nasa paligid ng 16 sandboxes ang maaaring ma-park kung tig-iisang gibibyte ang hawak ng bawat isa. Sukatin ang sarili mong setup gamit ang free -m habang may totoong load, dahil ang sandbox na nagpapatakbo ng test suite ay maaaring gumamit ng ilang ulit na memory kumpara sa sandbox na nagpapatakbo ng maliit na script.

Bakit kailangang itakda ang vm.swappiness sa 100 para sa Dormice?

Ang pag-freeze ng sandbox ay nangangahulugang inililipat sa swap ang idle memory nito. Hinahawakan ng gVisor ang sandbox memory bilang shared memory, at hindi nag-swap ang Linux kernel ng shared memory kapag default ang swappiness. Kaya sa default na value, walang nare-reclaim sa pag-freeze at patuloy na kumokonsumo ang sandbox ng buong memory. Sinukat ng project ang 0 bytes na na-reclaim sa default at 99.5 percent na na-reclaim sa 100. Suriin ang effective value gamit ang sysctl vm.swappiness sa halip na basahin ang config files, dahil may ilang cloud image na may value na 0.