Running KSM on linux containers

1

Recently I’ve been doing an experiment to check the effectiveness of KSM(Kernel Same-page Merging) on containers
I followed through the instructions of this tutorial
I successfully built the ksm_preload tool and enabling it in the /etc/rc.local (I’m using ubuntu container) in the container

and then I tried $ sudo ./ksm-wrapper lxc start container1 to launch multiple containers and check /sys/kernel/mm/ksm, but only full_scans has increased, the other remained unchange.

there’s a guy claimed in this thread he’s successfully done that but the result isn’t quite satisfying.

so I’m wondering if there’s any step I did wrong or missed ,
if anyone had experience doing this before please let me know

thanks for the help

1 Like
2

You’d probably need to run the LXD daemon under your ksm_wrapper rather than the client lxc tool as that client tool just talks over LXD’s network API and doesn’t spawn the container itself.

3

thanks I’ll try it.
If I’m gonna restart LXD daemon should I use /etc/init.d/lxd restart or service stop/start lxd ?
it seems the first one only stop lxd.service and I can still use lxc command(maybe via lxd.socket).
or there’s a better way to start the daemon ?

thanks

4

Probably best to stop all the systemd units and then manually run “lxd --debug --group lxd” in a terminal, you can wrap that one with your ksm script.

Trying to wrap /etc/init.d/lxd with your script won’t work because just like “lxc”, the init scripts call “systemctl” which then talks to systemd over dbus, so the script isn’t itself the one spawning the process.

5

thanks, it worked perfectly!

though I’m still a little confused:

if I wrap the /etc/init.d/lxd start, it’ll eventually talks to systemd so I’m actually wrapping systemd ?

6

/etc/init.d/lxd will talk to the systemctl command which then talks over DBUS to the systemd daemon that then spawns the processes for you.

Your wrapper uses LD_PRELOAD which means that only its children can be affected by whatever it does. As in this case, LXD will be a child of systemd (pid1) not of systemctl, the wrapper will be useless.

7

hahattan, what savings are you seeing with this approach?

8

you mean the KSM memory saving ?
I ran 4x Apache web server container and there’s roughly 1600 pages_sharing (~6M memory saving)

1 Like
9

Thanks. Yes, that was what I meant. It doesn’t seem a lot of savings then. Means it’ll take a backseat in my use case. Thanks again for responding.

10

I am the “guy” mentioned in the OP thread above. As @hahattan demonstrated above, the memory savings using KSM are not significant. From my memory of the original test, I ran a bunch of use cases and ended up saving about 150MB of RAM over 50 containers. Given the amount of work required to get KSM running and the modifications required for containers, I realized my efforts were better spent in other areas of system tuning.

My $0.02

1 Like
11

ubuntu (bionic) provides the ksmtuned package, low cost to install on the host with apt install ksmtuned

For a lxc host with low amount of RAM (2 GB) it is totally worth, in this case saving around 100 MB RAM on the host running 5 containers.

N.B. KSM does not happend with a Gentoo container, perhaps due to OpenRC as opposed to systemd