Jądro deduplikuje pamięć
Wirtualizacja KVM oznacza pamięć maszyn wirtualnych jako „scalalną” (madvise(MADV_MERGEABLE)). Wątek jądra ksmd w tle skanuje te obszary, liczy sumy kontrolne stron 4 KB i gdy znajdzie identyczne strony należące do różnych VM — zostawia jedną fizyczną kopię, a pozostałe odwzorowania kieruje na nią w trybie kopiowania przy zapisie (COW).
Dopóki żadna VM nie zmodyfikuje takiej strony, wszystkie współdzielą jeden egzemplarz w RAM. Gdy któraś zapisze — jądro natychmiast tworzy jej prywatną kopię. Z punktu widzenia gościa nic się nie zmienia; oszczędność dzieje się wyłącznie po stronie hosta.
KSM scala tylko anonimową pamięć oznaczoną jako mergeable. Nie obejmuje hugepages ani pamięci współdzielonej przez plik — to ważne przy bazach danych korzystających z dużych stron.
Najwięcej zyskują jednorodne środowiska
KSM działa tym lepiej, im więcej maszyn ma te same dane w pamięci: ten sam system, te same biblioteki, te same binaria. Klasyczny przypadek to dziesiątki VM z jednym obrazem bazowym (np. 40× Debian albo farma identycznych Windows Server) — wspólne strony kodu jądra gościa, bibliotek glibc/.NET czy zerowane strony scalają się masowo.
- Duży zysk: wiele VM z tym samym OS i podobnym stosem aplikacji (VDI, hosting, farmy aplikacyjne).
- Średni zysk: mieszane Linuksy tej samej rodziny — część bibliotek i tak jest wspólna.
- Mały zysk: kilka bardzo różnych, dużych VM (różne OS, bazy na hugepages) — mało stron się powtarza.
W praktyce na jednorodnych klastrach KSM pozwala odzyskać realnie kilkanaście do kilkudziesięciu procent RAM — czyli zmieścić więcej VM na tym samym sprzęcie, bez dokupowania pamięci.
Włączony automatycznie — pod kontrolą
Proxmox uruchamia usługę ksmtuned, która włącza KSM dopiero pod presją pamięci — domyślnie gdy wykorzystanie RAM hosta przekroczy próg (ok. 80% pamięci fizycznej). Dzięki temu na luźno obciążonym hoście KSM nie marnuje CPU na skanowanie, a uruchamia się wtedy, gdy faktycznie pomaga.
| Co sprawdzić | Gdzie / polecenie |
|---|---|
| Współdzielona pamięć (panel) | Node → Summary → KSM sharing |
| Ile stron współdzielonych | cat /sys/kernel/mm/ksm/pages_sharing |
| Ile stron-wzorców | cat /sys/kernel/mm/ksm/pages_shared |
| Czy KSM aktywny | cat /sys/kernel/mm/ksm/run (1 = działa) |
Zaoszczędzony RAM to w przybliżeniu (pages_sharing − pages_shared) × 4 KB. Na zdrowym, jednorodnym hoście potrafią to być gigabajty.
Próg i agresywność skanowania dostroisz w /etc/ksmtuned.conf (m.in. KSM_THRES_COEF). Domyślne ustawienia są rozsądne dla większości wdrożeń.
Czego być świadomym
- Koszt CPU: skanowanie pamięci zużywa cykle procesora. Pod dużą presją RAM to opłacalny kompromis, ale na hostach o krytycznej latencji warto go mierzyć.
- NUMA: domyślnie KSM może scalać strony między węzłami NUMA, co bywa szkodliwe dla latencji pamięci. Na dużych serwerach rozważ
merge_across_nodes=0. - Bezpieczeństwo (multi-tenant): deduplikacja jest znanym wektorem ataków side-channel (czas dostępu zdradza, że strona jest współdzielona). W środowiskach wielu niezaufanych najemców rozważ wyłączenie KSM lub ograniczenie go do zaufanych grup VM.
KSM to narzędzie do gęstości, nie do izolacji. Tam, gdzie liczy się twarda separacja sąsiadów, świadomie zrezygnuj z części oszczędności na rzecz bezpieczeństwa.
Wycisniemy maksimum z Twojego RAM-u
Zaprojektujemy klaster Proxmox pod realną gęstość — KSM, overcommit, NUMA i dobór hostów dopasowane do Twoich obciążeń, bezpiecznie.
⚡ Bezpłatna konsultacja → VM vs kontener: zużycie RAM