Limity pamäte a CPU pre kontajnery

Predvolene môže kontajner zabrať všetku pamäť a všetky jadrá na stroji. Na VDS-1 s dvoma gigabajtmi sa to skončí predvídateľne: jedna služba napuchne, kernel začne zabíjať procesy a nespadne ona, ale databáza vedľa nej.

Ako nastaviť strop

services:
  app:
    image: ghcr.io/example/app:1.5.0
    deploy:
      resources:
        limits:
          memory: 768M
          cpus: "1.0"
        reservations:
          memory: 256M

Compose aplikuje deploy.resources.limits aj pri obyčajnom docker compose up -d. Ekvivalent pre docker run:

docker run -d --memory 768m --cpus 1.0 --memory-swap 768m <image>

Nastavenie --memory-swap na rovnakú hodnotu ako --memory zakáže swapovanie: čestný pád je lepší než stroj, ktorý sa celé hodiny sotva hýbe.

Koľko prideliť

Vychádzaj zo svojho tarifu a nechaj systému nejakú rezervu.

Zvyšok potrebuje systém, vyrovnávacia pamäť súborov a samotný Docker. Súčet limitov väčší než množstvo pamäte nie je chyba v konfigurácii — je to katastrofa, ktorá len čaká, kým sa stane.

Pri CPU: cpus: "1.0" je jedno celé jadro. VDS-1 má jediné jadro, takže obmedzovať tam CPU nemá veľký zmysel, ale na VDS-4 a vyššie sa oplatí zabrániť konfigurácii servera, aby si zobrala všetkých šesť.

Čo sa skutočne spotrebúva

docker stats --no-stream
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"
free -h

Sleduj službu deň pri záťaži a nastav limit na približne jeden a pol násobok špičky. Príliš tesný limit je horší než žiadny: služba sa reštartuje práve vtedy, keď ju najviac potrebuješ.

Celoobrazovkové htop a btop fungujú len v konzole „Screen“ (VNC). Textová konzola neodovzdáva veľkosť okna, vždy je tam 80×24 a rozhranie sa rozsype. Na rýchle merania v textovej konzole použi docker stats --no-stream a free -h.

Ako zistiť, že ho zabila pamäť

docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>
sudo dmesg -T | grep -i -E "out of memory|killed process"

Návratový kód 137 spolu s OOMKilled: true je jednoznačný verdikt. Odtiaľ máš dve možnosti: zvýšiť limit, ak bol nastavený príliš nízko, alebo zistiť, prečo aplikácia stále rastie — únik pamäte sa pridaním pamäte nevylieči, len odloží.

Java a iné špeciálne prípady

Virtuálny stroj Java niekedy stále vidí pamäť hostiteľa namiesto limitu kontajnera a nastaví haldu s rezervou, ktorá tam nie je. Nastav ju explicitne:

environment:
  JAVA_TOOL_OPTIONS: "-Xmx512m -Xms256m"

To isté platí pre PostgreSQL (shared_buffers) a akúkoľvek službu s vlastným poolom.

Časté chyby

• Žiadne nastavené limity. Najčastejšia príčina „stroj zamrzol, nič neodpovedá“.
• Limit je nastavený, ale chýba health check. Kontajner bol zabitý a už sa nereštartoval. Pridaj restart: unless-stopped a healthcheck — pozri aktualizácia kontajnerov.
• Zabudol si na disk. Pamäť si obmedzil, ale zápisy narazia na strop: pozri rýchlosť disku.