Score:1

Restricting swap usage for a systemd service in Ubuntu 18.04

ng flag
tuk

I am trying to restrict the swap usage of a process using MemorySwapMax as mentioned in the doc with Ubuntu 18.04.

Environment

ubuntu@vrni-platform:/usr/lib/systemd/system$ uname -a
Linux vrni-platform 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

ubuntu@vrni-platform:/usr/lib/systemd/system$ systemctl --version
systemd 237
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid

My systemd unit file looks like below

[Unit]
Description=My service
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=support
MemoryMax=2000M
KillMode=process
MemoryAccounting=true
OOMScoreAdjust=1000
MemorySwapMax=0
ExecStart=/usr/bin/java -cp /home/support -XX:NativeMemoryTracking=summary -Xmx10000m MemoryConsumer 100 200 1

I tried to disable swap for this process by specifying 0 for MemorySwapMax. But it seems there was some issue in systemd which is fixed in systemd 239.

So I also tried setting MemorySwapMax=1M. But that also seems to be not restricting the swap memory usage for this systemd service.

The documentation for MemorySwapMax states this

This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.

Can someone let me know how can I know if systemd is using unified control group hierarchy is being used in my setup or what else could be the problem which is not allowing MemorySwapMax to take effect?

EDIT

As mentioned in this answer I can see cgroup2 enabled

ubuntu@vrni-platform:/tmp/debraj$ sudo mount -t cgroup2 none /tmp/debraj
ubuntu@vrni-platform:/tmp/debraj$ ls -l /tmp/debraj/
total 0
-r--r--r--  1 root root 0 Jul  2 17:13 cgroup.controllers
-rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.max.depth
-rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.max.descendants
-rw-r--r--  1 root root 0 Jun 30 14:42 cgroup.procs
-r--r--r--  1 root root 0 Jul  2 17:13 cgroup.stat
-rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.subtree_control
-rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.threads
drwxr-xr-x  2 root root 0 Jun 30 14:42 init.scope
drwxr-xr-x 87 root root 0 Jul  2 15:05 system.slice
drwxr-xr-x  7 root root 0 Jun 30 15:22 user.slice
ubuntu@vrni-platform:/tmp/debraj$ sudo umount /tmp/debraj
Michael Hampton avatar
cz flag
The last time I checked, Ubuntu explicitly disabled support for the unified control group hierarchy aka cgroup v2. You may wish to find a different distro. See [here](https://unix.stackexchange.com/q/471476/20805) to check if it is available on any given system.
ng flag
tuk
Thanks for replying. I have updated my question it seems to be enabled on my setup. But I am still not sure why `MemorySwapMax` is not working in my setup.
Score:2
ng flag
tuk

This has been answered in systemd mailing list.

Link1

Re-posting relevant parts.

Looks like your Ubuntu version is using the "hybrid" cgroup mode by default. Cgroup v2 is indeed enabled in your kernel, but not necessarily in use – in the hybrid mode, systemd still mounts all resource controllers (cpu, memory, etc.) in v1 mode and only sets up its own process tracking in the v2 tree. See findmnt.

You could boot with the systemd.unified_cgroup_hierarchy=1 kernel option to switch everything to cgroups v2, but if you're using container software (docker, podman) make sure those are cgroups v2-compatible.

Link2

Hello Debraj.

On Thu, Jul 08, 2021 at 05:10:44PM +0530, Debraj Manna wrote:

Linux vrni-platform 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [...] GRUB_CMDLINE_LINUX="audit=1 rootdelay=180 nousb net.ifnames=0 biosdevname=0 fsck.mode=force fsck.repair=yes ipv6.disable=1 systemd.unified_cgroup_hierarchy=1"

Even after making these changes MemorySwapMax not taking into effect.

You need to add also swapaccount=1, swap accounting is enabled by default only since kernel v5.8.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.