Docker RAM -suunnittelija

Mika on Docker RAM -laskin?

Docker RAM -laskin arvioi Docker-pohjaisten sovellusten kokonaismuistivaatimukset. Jokainen kontti kuluttaa muistia sovellusprosesseihinsa, ajonaikaiseen ympaeristoonsa ja mahdollisiin vaalimuisteihinsa. Tietaen konttien muistikayton kokonaismaaran auttaa sinua valitsemaan oikeankokoiset palvelimet tai pilvinstanssit.

Docker-konttien muistinkaytto koostuu sovellusmuistista (palvelimesi, tietokantasi), ajonaikamuistista (Node.js-keko, JVM-keko, Python-tulkki), kirjastoista ja riippuvuuksista sekae kayttojarjestelman valimuistista kontin sisalla. Todellinen kaytto on usein 20-50 % suurempi kuin itse sovellusprosessi.

Tyokalun kayttohje

Lisaa kukin kontti arvioidun muistinkayton kanssa. Tyokalu laskee kokonais-RAM-vaatimuksen kaikkien konttien, kayttojarjestelman ylaapuoliskulujen ja suositellun turvamarginaalin (20 %) kanssa. Se ehdottaa sopivaa palvelin- tai pilvi-instanssikokoa.

Muistirajoitukset vs. muistivaraukset

Docker antaa sinulle kaksi erillistä säädintä kontin RAM-käytön hallintaan: muistirajoitukset ja muistivaraukset. Ne sekoitetaan usein toisiinsa, mutta niillä on hyvin erilaiset tarkoitukset.

Muistirajoitus (asetettu --memory- tai mem_limit-parametrilla Compose-tiedostossa) on kova katto. Docker valvoo sitä Linuxin ohjaus­ryhmien (cgroups) alijärjestelmän kautta. Kontti ei koskaan pysty varaamaan enempää kuin tämän määrän — jos se yrittää, Linuxin ytimen OOM-tappaja puuttuu asiaan.

• --memory / mem_limit: kova yläraja. Kontti ei pysty ylittämään tätä. Käytetään isäntäkoneen suojaamiseen hallitsemattomilta prosesseilta.
• --memory-reservation / mem_reservation: pehmeä vihje ajoitukseen. Dockerin swarm-ajoitin käyttää tätä päättäessään, mihin sijoittaa palvelut. Se EI estä konttia käyttämästä enemmän — se on yksinkertaisesti minimitakuu, jota Docker pyrkii noudattamaan.
• Yleinen paras käytäntö: aseta varaus odotetulle tyhjäkäynti­jalanjäljelle ja rajoitus suurimpaan sallittuun. Esimerkiksi kontti, joka on 200 MB:n tyhjäkäynnillä mutta saattaa piikittää 600 MB:iin, voitaisiin asettaa reservation=200m ja limit=600m.

Jos jätät molemmat liput pois, kontilla ei ole rajaa ja se voi kuluttaa kaiken käytettävissä olevan isäntä-RAM:n. Yksikäyttöisellä palvelimella tämä saattaa olla hyväksyttävää, mutta monta palvelua ajavan homelabissa se on merkittävä riski.

Mitä tapahtuu, kun kontti saavuttaa muistirajoituksensa

Kun kontin muistinkäyttö saavuttaa --memory-parametrin arvon, Linuxin ytimen OOM-tappaja (Out of Memory) lopettaa muistihungrimman prosessin kontin sisällä. Docker kirjaa tämän poistu­mis­koodina 137 — standardi POSIX-signaali 9 (SIGKILL) -lopetus. Näet tämän komennolla docker ps --all tai kontin lokeissa merkintänä "Exited (137)".

Poistu­mis­koodi 137 ei tarkoita, että sovelluksesi kaatui virheen takia — se tarkoittaa, että ydin pakko­tappoi sen, koska kontti osui määrittämääsi RAM-kattoon. Jos näet toistuvia 137-poistumisia vakaassa sovelluksessa, muistirajoituksesi on liian pieni tai työmäärä on kasvanut alkuperäisen arvion yli. Suurenna rajoitusta ja seuraa uudelleen komennolla docker stats.

Suoritusaika­ympäristöjen muistihuomiot

Eri kieliajurit ja tietokanta­moottorit hallitsevat muistia hyvin eri tavoin. Kontin muistirajoituksen asettaminen ottamatta huomioon ajoympäristön käyttäytymistä on yksi yleisimmistä odottamattomien OOM-tappojen syistä.

• JVM (Java, Kotlin, Scala): JVM varaa keon etukäteen. Ilman eksplisiittisiä lippuja se saattaa varata suuren osan käytettävissä olevasta järjestelmä-RAM:sta käynnistyksessä. Aseta aina -Xmx (maksimikeko) Docker-muistirajoitusta pienemmäksi — yleinen ohje on jättää vähintään 25% puskuria -Xmx:n yläpuolelle off-heap-muistille, roskienkeruu­ylikuormalle ja natiivi­kirjastoille.
• Node.js: V8:lla on oletusarvoinen keon raja (noin 1,5 GB 64-bittisillä järjestelmillä vanhemmissa versioissa). Jos Docker-rajoituksesi on pienempi, prosessi voidaan OOM-tappaa ennen kuin V8 edes käynnistää roskienkeruun. Käytä --max-old-space-size-parametria (MB:ssa) V8:n vanhan sukupolven keon rajoittamiseen ja aseta se alle Docker-muistirajoituksen.
• Tietokannat (PostgreSQL, MariaDB, MySQL): tietokannat käyttävät muistia aggressiivisesti suunnitelmallisesti — ne välimuistitavat kuumat sivut jaettuun puskuri­pooliin. PostgreSQL:n shared_buffers on oletuksena 128 MB, mutta se viritetään tyypillisesti 25%:iin käytettävissä olevasta RAM:sta omistettuja palvelimia varten. Kontin sisällä virittele shared_buffers muistirajoituksen sisään, tai tietokanta tapetaan odottamatta kuormituksessa.
• Mediapalvelimet (Jellyfin, Plex): transkooding on erittäin muisti-intensiivistä. Yksittäinen 4K-transkooding voi vaatia 1–3 GB tyhjäkäynti­jalanjäljen päälle. Jos otat käyttöön laitteisto­kiihdytetyn transkoodauksen, muistikuva muuttuu merkittävästi. Tarkista palvelimesi todellinen käyttö todellisessa kuormituksessa ennen rajoitusten viimeistelyä.

Yleisiaae konttien muistivaatimuksia

Alla olevat luvut ovat karkeita suunnittelun lähtöalueita — todellinen käyttö vaihtelee huomattavasti konfiguraation, datajoukon koon, käyttäjämäärän ja käytössä olevien ominaisuuksien mukaan. Mittaa aina komennolla docker stats todellisen työmäärän ajamisen jälkeen.

• PostgreSQL: 256 MB - 1 GB+ riippuen tietokannan koosta ja kyselyiden monimutkaisuudesta.
• Nginx/Caddy: 50-128 MB tyypilliseen kaeanteisvalityspalvelimen kayttoon.
• Grafana + Prometheus: 256 MB + 512 MB - 2 GB seurantapinoille.
• Home Assistant: 256-512 MB kodin automaatioon.
• Plex/Jellyfin: 1-4 GB riippuen transkoodauksesta ja kirjaston koosta.
• Kevyet käänteisproksi­palvelimet (Traefik, Caddy, Nginx): yleensä 30–150 MB tyhjäkäynnillä; nämä ovat muistitehokkaimpien palvelujen joukossa.
• Valvontakokonaisuudet (Prometheus + Grafana): Prometheus skaalautuu hakemiensa ja säilyttämiensä aikasarjojen määrän mukaan, muutamasta sadasta megasta useisiin gigatavuihin suurissa ympäristöissä. Grafana itsessään on suhteellisen kevyt, noin 100–300 MB.

Käytännön mitoitusesimerkki: tyypillinen homelabi Raspberry Pi 4 (8 GB)

Nähdäksesi, miten RAM-varaus karttuu, harkitse Raspberry Pi 4:ää, jossa on 8 GB ja joka ajaa pientä itse­isännöityä kokonaisuutta:

• Isäntä-OS (Raspberry Pi OS Lite): ~300–500 MB varattuna ytimelle, järjestelmä­prosesseille ja Docker-moottorille
• Pi-hole (DNS-mainossulkija): rajoitus 128 MB — kevyt palvelu, pieni ylikuorma
• Vaultwarden (Bitwarden-yhteensopiva salasananvälittäjä): rajoitus 128 MB — erittäin kevyt Rust-binääri
• Home Assistant: rajoitus 512 MB — Python-pohjainen, kasvaa automaatioiden ja integraatioiden myötä
• Jellyfin (mediapalvelin, ohjelmisto­transkooding pois käytöstä): rajoitus 1024 MB — skaalautuu kirjaston koon mukaan
• Portainer (konttien hallintakäyttöliittymä): rajoitus 256 MB

Näiden rajoitusten summa: 500 (isäntä) + 128 + 128 + 512 + 1024 + 256 = noin 2,5 GB varattu. 8 GB:n laitteessa jää noin 5,5 GB puskuria — mukava tila välimuistille, piikkeille ja tuleville konteille. 2 GB:n Pi 4:ssä sama kokonaisuus olisi ylikuormitettu jo ennen piikkejä. Yllä oleva laskuri tekee täsmälleen tällaisen laskutoimituksen mille tahansa valitsemallesi palvelujen yhdistelmälle.

Miksi RAM:n ylikapasiteetti on riskialtista

Ylikuormitus tarkoittaa pinon suunnittelua niin, että konttien yhdistetyt muistirajoitukset ylittävät isäntä-OS:n käytettävissä olevan fyysisen RAM:n. Docker itsessään ei estä tätä — se hyväksyy mielellään Compose-tiedoston, joka varaa 10 GB konteille 4 GB:n koneella. Riski realisoituu suoritusaikana: kun kaikkien konttien todellinen käyttö lähestyy fyysistä RAM:ia, ydin alkaa vaihtaa aggressiivisesti. Vaihto SD-korteilla ja USB-asemilla (yleiset homelabi-tallennusratkaisut) on suuruusluokkia hitaampaa kuin RAM ja voi aiheuttaa koko järjestelmän jäätymisiä.

Isäntä-OS tarvitsee myös omaa hengitystilaa konttien käyttämän lisäksi. Linuxin sivu­välimuisti, ytimen puskurit ja järjestelmä­daemonit kilpailevat kaikki RAM:sta. Nyrkkisääntönä: älä koskaan suunnittele pinoa, joka jättää vähemmän kuin 10–15% koko RAM:sta vapaaksi isännälle konttirajoitusten summaamisen jälkeen. 4 GB:n laitteessa se tarkoittaa vähintään 400–600 MB varaamatta jättämistä.

Docker-muistin optimointivinkkeja

Aseta muistirajat kaikille konteille (docker run --memory=512m) estamaan yksittaista konttia kuluttamasta kaikkea kaytettavissa olevaa RAM-muistia. Kayta Alpine-pohjaisia kuvia muistinkulutuksen minimoimiseksi.

Yleisiä virheitä Docker RAM:n mitoittamisessa

• Rajoitusten asettamatta jättäminen: ilman --memory-rajoituksia mikä tahansa kontti voi kuluttaa kaiken isäntä-RAM:n, kaataa jokaisen muun koneen palvelun.
• Varauksen sekoittaminen rajoitukseen: suuren mem_reservation-arvon asettaminen ei rajoita käyttöä — kontti, jolla on suuri varaus eikä rajoitusta, voi silti tyhjentää isäntä-RAM:n.
• Isäntä-OS:n ylikuorman sivuuttaminen: 100% fyysisen RAM:n varaaminen konteille ei jätä mitään ytimelle, Docker-moottorille ja tausta­prosesseille.
• Mitoittaminen kuvan dokumentaation eikä todellisen käytön mukaan: viralliset kuva­dokumentit mainitsevat usein minimivaatimukset. Todellinen RSS todellisessa työmäärässäsi voi olla 2–5 kertaa suurempi. Tarkista aina komennolla docker stats.
• Ajoympäristön keon asetusten unohtaminen: konteilla JVM- tai Node-sovelluksille, joissa ei ole keon rajaa, yritetään käyttää niin paljon muistia kuin kontin rajoitus sallii — tai ylittää se ja laukaista OOM-tappo.

Usein kysytyt kysymykset

Miten seuraan Docker-konttien muistinkayttoa?

Kaynnissa olevien konttien kokonaismuistinkaytto: docker stats --no-stream --format 'table .Name .MemUsage'. Tarkempaan seurantaan kayta cAdvisoria, Prometheusia + Grafanaa tai Docker Desktopin sisaanrakennettua resurssiseurantaa. Linux-jarjestelmissa jokaisen kontin muistiraja ja kaytto nakyy hakemistossa /sys/fs/cgroup/.

Jakavatko Docker-kontit muistia?

Docker-kuvat ja -kontit jakavat kerroksittaisen tiedostojarjestelman — identtiset peruskuvat ja kerrokset tallennetaan vain kerran. Viisi konttia, jotka perustuvat samaan Node.js-kuvaan, tallentavat peruskuvan vain kerran levylle. Muistissa kukin kontti saa kuitenkin oman muistialueensa — jaetut kirjastot voidaan valimuistittaa kayttojarjestelman tasolla, mutta jokaisella prosessilla on oma muistiallokaationsa.

Tulisiko minun konfiguroida vaihto Docker-konteille?

Docker antaa sinun asettaa vaihtorajoituksen erikseen parametrilla --memory-swap. Jos asetat --memory=512m ja --memory-swap=1g, kontti saa 512 MB RAM:ia plus 512 MB vaihtoa. Vaihto tarjoaa turvaverkon, joka estää välittömät OOM-tapot, mutta normaaliin toimintaan turvautuminen vaihtoon heikentää suorituskykyä merkittävästi — erityisesti flash-tallennuksessa. Käytä vaihtoa viimeisenä puskurina, älä riittävän RAM:n korvikkeena. Järjestelmissä ilman eksplisiittistä --memory-swap-lippua Docker käyttää oletusarvoisesti kaksinkertaista muistirajoitusta vaihdossa.

Kuinka selvitän, kuinka paljon RAM:ia käynnissä olevat kontit todella käyttävät?

Suorita docker stats nähdäksesi reaaliaikaisen näkymän CPU:sta, muistinkäytöstä ja muistirajoituksista kaikille käynnissä oleville konteille. MEM USAGE -sarake näyttää kontin nykyisen RSS:n (resident set size). Vertaa tätä asettamiisi rajoituksiin nähdäksesi, kuinka paljon puskuria jokaisella kontilla on. Kertakuvausta varten käytä docker stats --no-stream. Voit myös tarkastaa yksittäisen kontin komennolla docker inspect <nimi> ja etsiä MemoryStats-kenttää.