LXC: Ressourcenlimitierung mit cgroups

Ein Server verfügt nur über begrenzte Ressourcen: Prozessor, Festplatte, Arbeitsspeicher, Netzwerk. Das langsamste Bauteil ist immer die Festplatte. Weiterhin möchte ich nicht, dass eine Echtzeitapplikation plötzlich zu laggen anfängt, nur weil ein anderer Container Updates zieht. Oder eine andere Anwendung den ganzen RAM des Hosts belegt. Es gilt also, diese Ressourcen angemessen zu verteilen.
Chapter 3. Subsystems and Tunable Parameters aus der Doku vom Red Hat Enterprise Linux bietet schon mal einen guten Einstieg in Linux cgroups (Control Groups).

Unter /sys/fs/cgroup/ und /sys/fs/cgroup/*/lxc/testvm kann man sich ruhig mal umschauen.
In Debian 8 "Jessie" gab es bei mir zumindest keine memory cgroup in
ls -lagG /sys/fs/cgroup

Fix:

echo 'GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"' >> /etc/default/grub;
update-grub;
shutdown -r now;


Limitierungen können temporär für einen laufenden Container gesetzt werden:
lxc-cgroup -n testvm cpu.shares 128 # default = 1024
cat /sys/fs/cgroup/cpu/lxc/testvm/cpu.shares
sollte dann 128 zurück geben.
Zudem können auch ganze Kerne einem Container zugewiesen werden, nur habe ich aktuell nur einen. 😅

Um den maximal verwendbaren Speicherplatz des Containers einzuschränken, muss dieser in einem LVM-Volume erstellt worden sein.

Für permanente Limits müssen diese der jeweiligen config des Containers hinzugefügt werden, z.B.
nano /var/lib/lxc/testvm/config
Prefix ist immer lxc.cgroup.module


Arbeitsspeicher Limitierung:
lxc.cgroup.memory.limit_in_bytes = 128M


Arbeitsspeicher & Swap
lxc.cgroup.memory.memsw.limit_in_bytes = 128M

Setze ich beides auf den gleichen Wert, dann kann der Container keinen Swap-Speicher verwenden.

Zum testen, im Container
dd if=/dev/zero of=/dev/shm/test
Daraus resultiert in diesem Fall ein Kill des ganzen Containers, geloggt in dmesg, sowie /var/log/messages.
Memory cgroup stats for /lxc/testvm: cache:128372KB rss:2700KB rss_huge:0KB mapped_file:0KB writeback:0KB swap:0KB inactive_anon:26924KB active_anon:104144KB inactive_file:4KB active_file:0KB unevictable:0KB


HDD I/O
lxc.cgroup.blkio.throttle.read_iops_device = 8:0 10
lxc.cgroup.blkio.throttle.write_iops_device = 8:0 10
lxc.cgroup.blkio.throttle.read_bps_device = 8:0 10485760
lxc.cgroup.blkio.throttle.write_bps_device = 8:0 10485760

Test:
lxc-attach -n testvm -- dd if=/dev/zero of=test bs=1M count=100 conv=fdatasync


Reduziert die Lese-/Schreibgeschwindigkeit auf maximal 10 MiB/s, sowie max. 10 IOPS/sec. Hier wäre es sinnvoll, zuerst mit fio die maximalen IOPS der HDD zu ermitteln, wie oben schon erwähnt, ist das langsamste Bauteil die HDD, mit radom 4k IO sieht es auch bei SSDs ziemlich mager aus mit der Geschwindigkeit (<1/10 normal), wenn auch besser als bei gewöhnlichen HDDs (<1MB/s).