QEMU guests
QEMU marks guest RAM mergeable. The Linux host needs KSM support and a running scanner. Actual savings vary with the guest images and activity.
Memory and density
How much lab fits on your host?
Start with the images you run. Repeated nodes can share identical memory pages; the result depends on the workload, host and runtime configuration.
Capacity run / FRR fabric
931 nodes. Reported host use: 18 GB.
A fourteen-pod fat tree: 49 core, 98 aggregation and 98 edge switches, plus 686 hosts and 2,058 links. Every switch runs FRR with BGP EVPN; hosts share a VXLAN segment.
- Workload
- 245 switches + 686 hosts
- FRR-based container fabric
- Host
- 24 cores · 100 GB RAM
- Host capacity, not a minimum requirement
- Reachability
- 182 / 182 pod pairs
- 0% ping loss across the overlay
This is the existing capacity run. The 18 GB figure is the reported host usage at the time of the audit. Peak startup memory, a matched containerlab baseline and an equivalent workload using vendor NOS images have not been published. Use this result to understand the tested workload; size your own lab from its actual images.
Full run and known scaling limits →
What Labtris configures
Memory sharing, with coverage you can check.
Kernel Samepage Merging scans eligible anonymous pages and merges identical copies. Labtris configures the scan and exposes the saved memory in diagnostics.
Native container runtime
The installer sets MemoryKSM=yes on containerd and Docker when Linux is 6.4+ and systemd is 254+. Restarted runtime processes must inherit the setting; existing processes need separate verification.
Container installation
Compose alone does not configure the host scanner or opt its runtimes in. Verify KSM on the Linux host and the processes that launch nodes before expecting container savings.
KSM is available to a containerlab host too. Labtris packages configuration and diagnostics; a tuned-host comparison is needed to isolate the platform overhead. More aggressive scanning uses CPU, and changing pages can reduce savings. Watch boot-time peaks as well as settled RAM.
Repeatable benchmark protocol
Compare the same lab on the same host.
A matched comparison is pending. These are the three configurations to measure before claiming a reduction versus containerlab.
A / Baseline
containerlab
Document the host defaults. Record KSM state and actual pages saved.
Matched result: not measured
B / Host tuning
containerlab + KSM
Use the same scanner settings and runtime opt-in as the Labtris run.
Matched result: not measured
C / Full platform
Labtris + KSM
Include the API, database, browser services and runtime in host memory.
Matched result: not measured
- Pin the topology, image digests, configs, route count and traffic profile. Keep the kernel, runtime, vCPU and memory settings identical.
- Use an isolated test host. Measure the idle platform baseline, then start the lab while collecting host memory. Run each configuration separately from the same starting conditions.
- Record peak startup RAM and time to convergence. After convergence, sample for at least five minutes and report the median, range, KSM saved bytes and scanner CPU overhead.
- Verify neighbor sessions, routes and end-to-end reachability. Repeat runs and publish the raw files with the configs. Repeat for each vendor NOS you intend to use.
Collect read-only host samples
Download the Python 3 sampler and run it on the Linux host before starting the lab. It records host memory, KSM counters and scanner CPU ticks as JSON lines. It changes no settings and contains no workload or convergence checks. For a VM host, measure the outer hypervisor separately.
python3 memory-sample.py --label containerlab-default --seconds 300 > containerlab-default.jsonlUse a distinct label and file for each run. Linux page and memory counters describe different scopes: KSM saved bytes are not a percentage reduction in total RAM.