Batas memori dan CPU untuk container

Secara default, sebuah container dapat mengambil seluruh memori dan seluruh core pada mesin. Pada VDS-1 dengan dua gigabyte, hal ini berakhir secara terprediksi: satu layanan membengkak, kernel mulai membunuh proses, dan yang tumbang bukan layanan itu melainkan basis data di sebelahnya.

Cara menetapkan batas

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

Compose menerapkan deploy.resources.limits bahkan dengan docker compose up -d biasa. Padanan untuk docker run:

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

Menetapkan --memory-swap sama dengan --memory melarang swapping: crash yang jujur lebih baik daripada mesin yang nyaris tidak bergerak selama berjam-jam.

Berapa banyak yang harus dialokasikan

Mulailah dari tier Anda dan sisakan sedikit ruang untuk sistem.

Sisanya dibutuhkan oleh sistem, cache berkas, dan Docker itu sendiri. Jumlah batas yang melebihi jumlah memori bukanlah kesalahan konfigurasi — melainkan bencana yang menunggu terjadi.

Untuk CPU: cpus: "1.0" berarti satu core penuh. VDS-1 hanya memiliki satu core, jadi tidak ada gunanya membatasi CPU di sana, tetapi pada VDS-4 ke atas ada baiknya mencegah konfigurasi server mengambil keenam core.

Apa yang sebenarnya terpakai

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

Pantau layanan selama sehari di bawah beban dan tetapkan batas sekitar satu setengah kali puncaknya. Batas yang terlalu ketat lebih buruk daripada tidak ada sama sekali: layanan akan restart tepat saat Anda paling membutuhkannya.

htop dan btop layar penuh hanya berfungsi di konsol "Screen" (VNC). Konsol teks tidak meneruskan ukuran jendela, di sana selalu 80×24, dan antarmukanya berantakan. Untuk pengukuran cepat di konsol teks, gunakan docker stats --no-stream dan free -h.

Cara mengetahui bahwa proses dibunuh karena memori

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

Kode keluar 137 disertai OOMKilled: true adalah vonis yang tidak ambigu. Dari sana Anda punya dua pilihan: naikkan batas jika terlalu rendah, atau cari tahu mengapa aplikasi terus bertumbuh — kebocoran tidak disembuhkan dengan menambah memori, hanya ditunda.

Java dan kasus khusus lainnya

Java virtual machine terkadang masih melihat memori host alih-alih batas container, dan mengukur heap dengan ruang cadangan yang sebenarnya tidak ada. Tetapkan secara eksplisit:

environment:
  JAVA_TOOL_OPTIONS: "-Xmx512m -Xms256m"

Hal yang sama berlaku untuk PostgreSQL (shared_buffers) dan layanan apa pun yang memiliki pool sendiri.

Kesalahan umum

• Tidak menetapkan batas sama sekali. Penyebab paling umum dari "mesin membeku, tidak ada yang merespons".
• Batasnya ada, tetapi tidak ada health check. Container dibunuh dan tidak pernah dijalankan ulang. Tambahkan restart: unless-stopped dan healthcheck — lihat memperbarui container.
• Anda lupa soal disk. Anda membatasi memori, tetapi penulisan membentur batas: lihat kecepatan disk.