Docker RAM-planlegger

Hva er en Docker RAM-kalkulator?

En Docker RAM-kalkulator hjelper deg å estimere total minnebruk for en Docker-installasjon basert på antall containere, deres individuelle minnegrenser og systemoverhead. Docker-containere deler vertens kjerneressurser, men hver container har sine egne minneallokering. Riktig dimensjonering av minne er kritisk for stabil drift og for å unngå OOM (Out of Memory) kills.

Totalbehovet inkluderer: summen av alle containeres minnegrenser, Docker-daemonens egen overhead (typisk 200–500 MB), operativsystemets behov (1–2 GB for Linux) og en buffer for minnetopper og caching. Verktøyet beregner disse komponentene og anbefaler total RAM for serveren din.

Slik bruker du dette verktøyet

Legg til containere med navn og minnegrense (MB). Verktøyet summerer minnebehovet, legger til system-overhead og anbefaler total RAM. Du kan importere fra en docker-compose.yml-fil eller legge til containere manuelt. Vanlige tjenester (Nginx, PostgreSQL, Redis) har forhåndsdefinerte standardverdier.

Minnegrenser versus minnereservasjoner

Docker gir deg to separate innstillinger for å kontrollere hvor mye RAM en container kan bruke: minnegrenser og minnereservasjoner. De forveksles ofte, men tjener svært forskjellige formål.

En minnegrense (satt med --memory eller mem_limit i en Compose-fil) er et hardt tak. Docker håndhever dette via Linuxs kontrollgrupper (cgroups). Containeren kan aldri allokere mer enn dette – forsøker den det, griper Linuxkjernens OOM-killer inn.

• --memory / mem_limit: den harde øvre grensen. Containeren kan ikke overstige dette. Brukes til å beskytte verten mot ukontrollerte prosesser.
• --memory-reservation / mem_reservation: et mykt hint til scheduleren. Dockers swarm-scheduler bruker dette når den bestemmer hvor tjenester skal plasseres. Det forhindrer IKKE containeren fra å bruke mer – det er kun en minimumsgaranti som Docker forsøker å overholde.
• En vanlig beste praksis: sett reservasjon til forventet tomgangsbruk og grense til det maksimale du er komfortabel med å tillate. For eksempel kan en container som er på tomgang ved 200 MB men kan stige til 600 MB, settes med reservation=200m og limit=600m.

Utelater du begge flaggene, har containeren ingen grense og kan forbruke all tilgjengelig RAM på verten. På en dedikert server kan dette være akseptabelt, men på et homelab med mange tjenester er dette en betydelig risiko.

Hva som skjer når en container treffer minnegrensen

Når en containers minnebruk når verdien satt av --memory, avslutter Linuxkjernens OOM (Out of Memory) killer den mest minnekrevende prosessen inne i containeren. Docker registrerer dette som avslutningskode 137 – et standard POSIX-signal 9 (SIGKILL). Du vil se dette i docker ps --all eller containerloggene som «Exited (137)».

Avslutningskode 137 betyr ikke at applikasjonen krasjet på grunn av en feil – det betyr at kjernen tvangsdrepte den fordi containeren traff RAM-taket du konfigurerte. Ser du gjentatte 137-avslutninger i en stabil applikasjon, er minnegrensen for lav, eller arbeidsbelastningen har vokst utover den opprinnelige estimaten. Øk grensen og overvåk på nytt med docker stats.

Minnehensyn for ulike kjøretidsmiljøer

Ulike programmeringsspråk og databasemotorer håndterer minne svært forskjellig. Å sette en containerminnegrense uten å ta hensyn til kjøretidsadferd er en av de vanligste kildene til uventede OOM-avslutninger.

• JVM (Java, Kotlin, Scala): JVM allokerer en heap på forhånd. Uten eksplisitte flagg kan den kreve en stor andel av tilgjengelig system-RAM ved oppstart. Sett alltid -Xmx (maksimal heap) til en verdi under Docker-minnegrensen – en vanlig tommelfingerregel er å la minst 25% hodeplass over -Xmx for off-heap-minne, søppelsamlingsoverhead og native biblioteker.
• Node.js: V8 har en standard heap-grense (rundt 1,5 GB på 64-biters systemer i eldre versjoner). Er Docker-grensen lavere, kan prosessen bli OOM-drept før V8 i det hele tatt utløser søppelsamling. Bruk --max-old-space-size (i MB) for å begrense V8s gamle generasjons heap og sett den under Docker-minnegrensen.
• Databaser (PostgreSQL, MariaDB, MySQL): databaser er aggressivt minnekrevende av design – de bufrer varme sider i sin delte bufferpool. PostgreSQLs shared_buffers er som standard 128 MB, men tilpasses vanligvis til 25% av tilgjengelig RAM for dedikerte servere. I en container, tilpass shared_buffers til å passe innenfor minnegrensen, ellers vil databasen bli avsluttet uventet under belastning.
• Medieservere (Jellyfin, Plex): transkoding er svært minnekrevende. En enkelt 4K-transkoding kan kreve 1–3 GB utover tomgangsbruk. Aktiverer du maskinvareakselerert transkoding, endres minnebildet betydelig. Sjekk serverens faktiske bruk under reell belastning før du fastslår grenser.

Vanlige minnekrav for containere

Tallene nedenfor er grove startintervaller kun for planleggingsformål – faktisk bruk varierer betydelig med konfigurasjon, datasettsstørrelse, antall brukere og aktiverte funksjoner. Mål alltid med docker stats etter å ha kjørt din faktiske arbeidsbelastning.

• PostgreSQL: 256MB-1GB+ avhengig av databasestørrelse og spørringskompleksitet.
• Nginx/Caddy: 50–128MB for typisk reverse proxy-bruk.
• Grafana + Prometheus: 256MB + 512MB-2GB for overvåkningsstabeler.
• Home Assistant: 256MB-512MB for hjemmeautomasjon.
• Plex/Jellyfin: 1–4GB avhengig av transkoding og bibliotekstørrelse.
• Lette omvendte proxyer (Traefik, Caddy, Nginx): generelt 30–150 MB på tomgang; disse er blant de mest minneeffektive tjenestene du kan kjøre.
• Overvåkingsstakker (Prometheus + Grafana): Prometheus skalerer med antall tidsserier det skraper og beholder, fra noen hundre MB til flere GB for store miljøer. Grafana selv er relativt lett på rundt 100–300 MB.

Gjennomarbeidet dimensjoneringseksempel: et typisk homelab Raspberry Pi 4 (8 GB)

For å se hvordan RAM-allokering summerer seg, se på en Raspberry Pi 4 med 8 GB som kjører en liten selv-hostet stakk:

• Vertens OS (Raspberry Pi OS Lite): ~300–500 MB reservert for kjernen, systemprosesser og Docker-motoren selv
• Pi-hole (DNS-reklameblokkerer): grense 128 MB – lettvektstjeneste med lav overhead
• Vaultwarden (Bitwarden-kompatibel passordbehandler): grense 128 MB – svært lett Rust-binær
• Home Assistant: grense 512 MB – Python-basert, vokser med automatiseringer og integrasjoner
• Jellyfin (medieserver, programvaretranskodig deaktivert): grense 1024 MB – skalerer med biblioteksstørrelse
• Portainer (containeradministrasjons-UI): grense 256 MB

Summen av disse grensene: 500 (vert) + 128 + 128 + 512 + 1024 + 256 = omtrent 2,5 GB allokert. På en enhet med 8 GB gir det omtrent 5,5 GB hodeplass – en komfortabel buffer for bufring, topper og fremtidige containere. På en Pi 4 med 2 GB ville den samme stakken vært overkomittert allerede før toppene tas i betraktning. Kalkulatoren over utfører nøyaktig denne typen aritmetikk for enhver kombinasjon av tjenester du velger.

Hvorfor overforpliktelse av RAM er risikabelt

Overforpliktelse betyr at du planlegger en stakk der de kombinerte minnegrensene overstiger den fysiske RAM-en som er tilgjengelig for vertens OS. Docker selv forhindrer ikke dette – det godtar gjerne en Compose-fil som allokerer 10 GB på tvers av containere på en maskin med 4 GB. Risikoen materialiserer seg under kjøring: når faktisk bruk på tvers av alle containere nærmer seg fysisk RAM, begynner kjernen å bytte aggressivt. Bytte på SD-kort og USB-stasjoner (vanlig homelab-lagring) er størrelsesordener saktere enn RAM og kan forårsake systemomfattende frysing.

Selve vertens OS trenger også pusterom utover det noen container bruker. Linuxs sidevekslingsbuffer, kjernebuffere og systemtjenester konkurrerer alle om RAM. Som tommelfingerregel: planlegg aldri en stakk som etterlater mindre enn 10–15% av total RAM fri for verten etter summering av containergrenser. På en enhet med 4 GB betyr det å holde minst 400–600 MB uallokert.

Tips for minnehåndtering i Docker

Sett minnegrenser på alle containere (docker run --memory=512m) for å forhindre at en enkelt container bruker all tilgjengelig RAM. Bruk Alpine-baserte images som er mindre og bruker mindre minne. Overvåk faktisk bruk med 'docker stats' før du tar endelige dimensjoneringsbeslutninger. La minst 1–2GB være ledig for verts-OS, filcaching og Docker-overhead. Swap-plass kan gi et sikkerhetsnett, men bør ikke stoles på for normal drift.

Vanlige feil ved dimensjonering av Docker-RAM

• Ingen grenser i det hele tatt: uten --memory-grenser kan enhver container forbruke all RAM på verten og ta ned alle andre tjenester på maskinen.
• Forveksling av reservasjon med grense: å sette en høy mem_reservation begrenser ikke bruken – en container med stor reservasjon og ingen grense kan fortsatt tømme vertens RAM.
• Ignorere vertens OS-overhead: å allokere 100% av fysisk RAM på tvers av containere etterlater ingenting til kjernen, Docker-motoren og bakgrunnsprosesser.
• Dimensjonering fra imagedokumentasjon i stedet for faktisk bruk: offisielle imager oppgir ofte minimumskrav. Faktisk RSS under din reelle arbeidsbelastning kan være 2–5 ganger høyere. Verifiser alltid med docker stats.
• Glemme innstillinger for kjøretidsheap: containere for JVM- eller Node-applikasjoner uten heap-begrensning vil forsøke å bruke så mye minne som containergrensen tillater – eller overstige den og utløse OOM-avslutning.

Ofte stilte spørsmål

Hva skjer når en container overskrider minnegrensen?

Docker (via cgroups) dreper containeren med en OOM (Out of Memory) kill. Containeren stoppes umiddelbart uten graceful shutdown. Med --restart=always starter Docker den på nytt, men gjentatte OOM kills indikerer at minnegrensen er for lav. Sjekk docker inspect for OOM-historikk og øk grensen eller optimaliser applikasjonen.

Hvor mye RAM trenger en typisk homelab-server?

For en grunnleggende homelab med 5–10 lette containere (reverse proxy, Pi-hole, Portainer, noen små tjenester) er 4 GB RAM tilstrekkelig. For mellomstore oppsett med databaser, medieseserver (Plex/Jellyfin) og 15–20 containere, anbefales 16 GB. For kraftige oppsett med mange tjenester, overvåking (Grafana, Prometheus) og CI/CD trenger du 32 GB+.

Bør jeg konfigurere bytte (swap) for Docker-containere?

Docker lar deg sette en bytte-grense separat med --memory-swap. Setter du --memory=512m og --memory-swap=1g, får containeren 512 MB RAM pluss 512 MB bytte. Bytte gir et sikkerhetsnett som forhindrer umiddelbare OOM-avslutninger, men å stole på bytte for normal drift reduserer ytelsen betydelig – særlig på flashlagring. Bruk bytte som en siste utvei-buffer, ikke som erstatning for tilstrekkelig RAM. På systemer uten eksplisitt --memory-swap-flagg er Docker-standarden det doble av minnegrensen i bytte.

Hvordan finner jeg ut hvor mye RAM de kjørende containerne faktisk bruker?

Kjør docker stats for å se en sanntidsvisning av CPU, minnebruk og minnegrenser for alle kjørende containere. Kolonnen MEM USAGE viser containerens gjeldende RSS (resident set size). Sammenlign dette med konfigurerte grenser for å se hvor mye hodeplass hver container har. For et øyeblikksopptak bruk docker stats --no-stream. Du kan også inspisere en bestemt container med docker inspect <navn> og se etter MemoryStats-feltet.