Belajar LXC - Performance Tuning & Large Scale

#Pendahuluan

Lima episode ke belakang kalian membangun satu host dengan beberapa container. Sekarang saatnya berpikir lebih besar: bagaimana membuat satu host melayani puluhan hingga ratusan container dengan performa tetap sehat? Di episode 18 kita menyetel storage, cgroups, dan perencanaan resource — lalu mengukur overhead-nya. Inilah episode yang memisahkan homelab santai dari infrastruktur yang terukur.

#Tuning Storage: ZFS/btrfs

#Kenapa Backend Menentukan Skala

Kembali ke episode 8: backend menentukan efisiensi snapshot dan clone. Di skala besar, ini bukan lagi kenyamanan, melainkan kelangsungan hidup. Bayangkan 100 container dan tiap snapshot penuh = ratusan GB disk. Dengan backend copy-on-write, snapshot nyaris gratis.

#ZFS sebagai Pilihan Utama

ZFS adalah pilihan populer untuk host LXC besar:

• Snapshot native & kloning — lxc-snapshot dan lxc-copy -s memakai mekanisme ZFS yang instan.
• Kompresi — compression=on menghemat disk signifikan untuk rootfs yang sebagian besar file teks.
• Checksum — mendeteksi korupsi data lebih awal.

zfs create -o compression=on -o atime=off tank/containers
zfs set mountpoint=/var/lib/lxc tank/containers

#btrfs sebagai Alternatif

btrfs punya kekuatan serupa (snapshot native, copy-on-write) dengan manajemen yang lebih sederhana. Untuk host tanpa kebutuhan fitur ZFS yang dalam, btrfs adalah pilihan ringan yang solid.

#Tuning cgroup untuk Densitas

#Komitmen Overcommit yang Realistis

Episode 7 menekankan limit. Di skala besar, kalian harus menghitung total limit ≤ kapasitas host:

Contoh perencanaan resource

Host: 16 core, 64 GB RAM
100 container web ringan: 0.1 core + 256 MB masing-masing
→ CPU: 10 core (< 16) OK
→ Memory: 25.6 GB (< 64) OK, sisanya untuk host & buffer

Rumus sederhananya: jumlahkan limit semua container, pastikan menyisakan ruang untuk host sendiri (kernel, service, I/O cache).

#Menyetel CPU dengan Bijak

Untuk workload bursty, gunakan lxc.cgroup2.cpu.weight (relatif) daripada kuota kaku:

CPU weight untuk berbagi adil

lxc.cgroup2.cpu.weight = 100

cpu.weight (1-10000) mengatur proporsi saat contention, tanpa membuang CPU saat idle — ideal untuk densitas tinggi dengan beban yang datang bergelombang. Kombinasikan dengan cpu.max hanya untuk container yang benar-benar butuh jaminan.

#Memory: Jaga Ruang untuk Page Cache

Host Linux memakai memory untuk page cache I/O. Jika limit container menyedot hampir semua RAM, cache mengecil dan performa disk anjlok. Sisakan ~10-20% RAM host untuk kernel dan cache.

#Resource Planning per Container

Standar pengukuran sebelum menentukan limit:

1. Profil workload — seberapa besar memory puncak, CPU puncak, I/O.
2. Set limit = kebutuhan puncak + buffer kecil (misal 1.25x).
3. Uji tekanan (episode 7: dd, loop CPU) — buktikan limit berlaku.
4. Pantau (episode 20) — sesuaikan limit berdasarkan data nyata, bukan perkiraan.

Contoh profil untuk container jenis tertentu:

Profil resource umum

Nginx/apache ringan : 256 MB  , 0.2 core
Database kecil      : 1 GB    , 1 core
Build CI            : 4 GB    , 4 core (bursty)

#Skala: Ratusan Container per Host

#Yang Membuat Densitas Mungkin

• Boot cepat — LXC boot dalam detik (bukan menit seperti VM), sehingga provisioning container baru terasa instan.
• Overhead hampir nol — tidak ada kernel guest; memory dipakai hanya untuk proses user space.
• Clone snapshot — 100 container bisa lahir dari satu golden image dalam beberapa menit (episode 9).

#Benchmark Boot dan Overhead

Ukur sendiri untuk basis keputusan:

time lxc-start -n c1

ps -o rss= -p $(pgrep -f "lxc-init" | head -1) 2>/dev/null || true

#Batasan Nyata yang Sering Muncul

• file descriptor dan thread limit kernel (ulimit, fs.file-max).
• Jumlah veth dan bridge pada host dengan banyak container network.
• Waktu start massal: lxc-autostart dengan lxc.start.delay (episode 10) mencegah thunder herd saat host reboot.
• Disk I/O contention — alasan utama memakai lxc.cgroup2.io.weight (episode 7).

#Penutup

Inti yang harus dibawa pulang:

• ZFS/btrfs membuat snapshot dan clone masif menjadi murah — pilih sejak awal.
• Total limit cgroup harus ≤ kapasitas host, sisakan ruang untuk host dan cache.
• cpu.weight untuk beban bursty; cpu.max untuk jaminan.
• Profil resource per jenis workload: ukur, set limit, uji, pantau.
• Skala hingga ratusan container mungkin karena boot cepat dan overhead hampir nol — kelola dengan disiplin konfigurasi.

Di episode 19 selanjutnya kita akan membahas ekosistem: LXD, Incus & Proxmox — LXD sebagai manager LXC Canonical dengan API/REST, clustering, dan VM; Incus sebagai fork komunitas (2023); serta perbandingan LXC low-level vs LXD/Incus high-level vs Docker application container.