// Poradnik techniczny // Pamięć · VM vs LXC

VM vs kontener:
zużycie pamięci RAM

Ta sama dystrybucja, drastycznie różny apetyt na RAM. Kontener LXC współdzieli jądro hosta i nie dźwiga własnego kernela ani pełnego stosu startowego — dlatego czysty Debian 13 w kontenerze zajmuje ok. 16 MB RAM, podczas gdy ta sama instalacja jako maszyna wirtualna startuje od ok. 85 MB. Pokazujemy liczby i co z nich wynika dla gęstości i kosztów w Proxmox VE.

// 01 · Skąd ta różnica

Kontener nie dźwiga drugiego jądra

Maszyna wirtualna to pełny gość: własne jądro Linux, własny proces init/systemd, własne sterowniki urządzeń wirtualnych, własne bufory i page cache. To wszystko zajmuje pamięć, zanim uruchomisz cokolwiek użytecznego.

Kontener systemowy LXC działa inaczej — jego procesy wykonują się bezpośrednio na jądrze hosta. Nie ma drugiego kernela, nie ma osobnych sterowników, a page cache jest współdzielony z hostem. Zostaje praktycznie tylko to, co naprawdę uruchomiłeś (systemd gościa + usługi). Stąd narzut „pustego” systemu spada z dziesiątek megabajtów do kilkunastu.

// 02 · Liczby (Debian 13, spoczynek)

Czysty Debian 13 — ile pobiera

KonfiguracjaZużycie RAM (świeży start, idle)
Debian 13 — kontener LXC (bez GUI)~16 MB
Debian 13 — VM serwer (bez GUI)~85 MB
Debian 13 — VM z pulpitem XFCE~450 MB
Debian 13 — VM z pulpitem GNOME~1 GB

To samo jądro, ta sama dystrybucja — a różnica między kontenerem (~16 MB) a serwerową VM (~85 MB) to ponad 5×. Dodanie graficznego pulpitu zmienia skalę zupełnie: lekki XFCE to ~450 MB, a pełne GNOME w spoczynku potrafi sięgnąć ~1 GB — czyli ~60× więcej niż kontener serwerowy.

ℹ️

Wartości dotyczą świeżo uruchomionego systemu w spoczynku (mierzone m.in. przez free -m). Realne zużycie rośnie wraz z usługami — ale punkt startowy narzutu jest dokładnie tym, co decyduje o gęstości.

// 03 · Co to znaczy dla gęstości

Więcej usług na tym samym hoście

Narzut „na puste” mnoży się przez liczbę instancji. Na hoście z 256 GB RAM sam koszt uruchomienia setek lekkich usług jest nieporównywalny: kontenery zostawiają niemal całą pamięć dla aplikacji, podczas gdy farma małych VM oddaje znaczną jej część na powielony narzut systemowy.

  • Mikrousługi, strony WWW, API, reverse-proxy, cache — idealne dla kontenerów: dziesiątki/setki instancji przy minimalnym narzucie.
  • Środowiska dev/test — szybki start, znikomy koszt pamięci, łatwe klonowanie.
  • VM + KSM — jeśli musisz użyć VM, włącz KSM, by odzyskać część powielonego narzutu między identycznymi maszynami.
// 04 · Kiedy mimo to VM

Gęstość to nie wszystko — kiedy wybrać VM

Kontener współdzieli jądro hosta, więc nie nadaje się wszędzie. Wybierz pełną maszynę wirtualną, gdy:

  • Inne jądro niż host — Windows, BSD, własny/niestandardowy kernel lub moduły jądra.
  • Twarda izolacja — niezaufani najemcy, wymogi compliance, separacja na poziomie hypervisora.
  • Operacje kernel-level — własne sysctl wymagające izolacji, sterowniki, zagnieżdżona wirtualizacja.

W skrócie: jeśli wystarcza Linux na jądrze hosta — kontener daje maksymalną gęstość. Jeśli potrzebujesz innego jądra lub twardej separacji — wybierz VM (i rozważ KSM). Najlepsze klastry Proxmox świadomie mieszają jedno i drugie.

💡

Proxmox VE zarządza VM (KVM) i kontenerami (LXC) z jednego panelu — nie musisz wybierać platformy, dobierasz właściwe narzędzie per-obciążenie.

Dobierzemy VM i kontenery pod Twoje obciążenia

Zaplanujemy podział na VM i LXC tak, by zmaksymalizować gęstość i obniżyć koszt RAM — bez kompromisów tam, gdzie potrzebujesz izolacji.

⚡ Bezpłatna konsultacja → Kontenery LXC w Proxmox
// Technical guide // Memory · VM vs LXC

VM vs container:
RAM usage

The same distribution, a drastically different appetite for RAM. An LXC container shares the host kernel and carries no kernel or full boot stack of its own — so a clean Debian 13 in a container uses about 16 MB of RAM, while the same install as a virtual machine starts from around 85 MB. Here are the numbers and what they mean for density and cost on Proxmox VE.

// 01 · Where the difference comes from

A container carries no second kernel

A virtual machine is a full guest: its own Linux kernel, its own init/systemd, its own virtual device drivers, its own buffers and page cache. All of that takes memory before you run anything useful.

An LXC system container works differently — its processes run directly on the host kernel. There is no second kernel, no separate drivers, and the page cache is shared with the host. Practically only what you actually started remains (the guest's systemd + services). That's why the overhead of an "empty" system drops from tens of megabytes to a dozen or so.

// 02 · The numbers (Debian 13, idle)

Clean Debian 13 — how much it uses

ConfigurationRAM usage (fresh boot, idle)
Debian 13 — LXC container (no GUI)~16 MB
Debian 13 — server VM (no GUI)~85 MB
Debian 13 — VM with XFCE desktop~450 MB
Debian 13 — VM with GNOME desktop~1 GB

Same kernel, same distribution — yet the gap between a container (~16 MB) and a server VM (~85 MB) is more than 5×. Adding a graphical desktop changes the scale entirely: lightweight XFCE is ~450 MB, and a full GNOME at idle can reach ~1 GB — about 60× more than the server container.

ℹ️

These figures are for a freshly booted, idle system (measured e.g. with free -m). Real usage grows with your services — but the starting overhead is exactly what drives density.

// 03 · What it means for density

More services on the same host

The "empty" overhead multiplies by the number of instances. On a host with 256 GB of RAM the mere cost of starting hundreds of lightweight services is incomparable: containers leave almost all memory for applications, while a farm of small VMs gives up a large part of it to duplicated system overhead.

  • Microservices, websites, APIs, reverse proxies, caches — ideal for containers: dozens/hundreds of instances at minimal overhead.
  • Dev/test environments — fast start, negligible memory cost, easy cloning.
  • VM + KSM — if you must use VMs, enable KSM to recover part of the duplicated overhead across identical machines.
// 04 · When a VM is still right

Density isn't everything — when to pick a VM

A container shares the host kernel, so it isn't suitable everywhere. Choose a full virtual machine when:

  • A different kernel from the host — Windows, BSD, a custom/non-standard kernel or kernel modules.
  • Hard isolation — untrusted tenants, compliance requirements, hypervisor-level separation.
  • Kernel-level operations — custom sysctl needing isolation, drivers, nested virtualisation.

In short: if Linux on the host kernel is enough — a container gives maximum density. If you need a different kernel or hard separation — choose a VM (and consider KSM). The best Proxmox clusters deliberately mix both.

💡

Proxmox VE manages VMs (KVM) and containers (LXC) from a single panel — you don't pick a platform, you pick the right tool per workload.

We'll match VMs and containers to your workloads

We'll plan the VM/LXC split to maximise density and lower RAM cost — with no compromises where you need isolation.

⚡ Free consultation → LXC containers in Proxmox