Du könntest auch als RADIKALE Maßnahme die max. mögliche Speichernutzung deines Users einschränken. Das ist durch die cgroups sehr einfach möglich.
Z.B. von den 4GB nur 3,2 oder 3,5 zur Verfügung stellen.
Auch der Anteil am Swap für deinen User kannst du reglemetieren.
Was passiert wenn diese Limits überschritten werden? Das ist dann die Stunde des OOM-Killers <g>
- Ein neuer Prozeß, der das Limit überschreiten läßt, wird gekillt
- Wenn die laufenden Prozesse dieser Gruppe das Limit überschreiten, dann werden laufende Prozesse gekillt. Das kann der verursachende sein, aber ggf. auch die neuesten oder willkührlich (da bin ich mir nicht sicher).
Du kannst das ja mit einem neuen Testuser mal ausprobieren (habe ich gerade auch, da ich mich mit den cgroups auch noch nicht intensiv beschäftigt habe, gerade bei der Memory-Geschichte).
Ein nützliches Tool dafür ist:
systemd-cgtop -m
Das zeigt aktuell - sortiert nach Speichernutzung - die Gruppen auf. Interessant sind dann in dem Fall die user.* Gruppen. Angenommen, deine UID wäre 1001, dann zeigt die Zeile /user.slice/user-1001.slice die momentan Menge an Speicher, die ab der Anmeldung deine weiteren gesamten Prozesse verbraten. Nicht durch die anderen user-1001 Zeilen irritieren lassen: Das sind nur "Unterverzeichnisse", tragen also in der Summe den Wert für /user.slice/user-1001.slice zusammen. Ebenso ist die Titelzeile "irritierend".
Ein weiteres Tool ist das gute alte:
free -h (die "benutzt" Spalte)
Durch die cgroups (und systemd + dessen Login) wird automatisch jeder User(user.slice) auch in die Gruppe/Ort Memory gepackt. Dort läßt sich on-the-fly eben max. Speichernutzung (RAM+Swap) verändern.
Der Ort im Dateisystem dafür wäre für den User mit der UID 1001:
/sys/fs/cgroup/memory/user.slice/user-1001.slice/
In diesem (virtuellen) Dateisystem-Ort finden sich nun etliche Dateien, aus denen Werte ausgelesen oder verändert werden können.
Angenommen dein Testuser hätte die UID 1002, du meldest dich mit diesem User an und nutzt den gleichen Desktop usw. wie dein Normaluser.
Um die max. Speichernutzung nun einzuschränken:
(Das geht nur als root, bitte nicht mit sudo arbeiten¹. Du kannst mit "su -" (ohne Anführungsstriche) in einem Terminal zum Root-User werden!)
echo 3200M > /sys/fs/cgroup/memory/user.slice/user-1002.slice/memory.limit_in_bytes
(Auslesen dieser Datei mit)
cat /sys/fs/cgroup/memory/user.slice/user-1002.slice/memory.limit_in_bytes
Würde jetzt die max. Kapazität, die die gesamte Gruppe nutzen darf, auf ~3,2G beschränken. Allerdings gibt es ja noch den Swap (bei dir 5GB). Auch dessen Nutzung sollte man beschränken, auf ein sinnvolles Maß, damit das System eben nicht nur mit Ein-/Auslagern von Speicherseiten beschäftigt ist.
echo 2G > /sys/fs/cgroup/memory/user.slice/user-1002.slice/memory.memsw.limit_in_bytes
Das regelt den User auf 2GB des verfügbaren Swap-Speichers. Diese Werte für "Ab wieviel Swap-Nutzung im Verhältnis zum verfügbaren RAM ist das System noch für mich nutzbar" sind/sollten austestbar sein.
Das zum Prinzip. Obige Werte kannst du beim Testuser ja auch mal recht radikal verkleinern, um das "Killen" zu produzieren. Wenn Prozesse aufgrund der eingestellten Werte gekillt werden, dann wird das im Journal vermerkt.
Sehr deutlich (Trap), lautstark und auch sehr informativ mit den Limits und was dieser Prozeß anfordern würde/wollte.
Ein journalctl --system -f sollte man in einem Terminalfenster mitlaufen lassen.
Ein weiteres nützliches Tool zum Rumtesten ist stress
pacman -Si stress
Mit stress (als User ausgeführt) kannst du sehr einfach Speicher anfordern/belegen, um eben Verbrauch zu simulieren.
stress --vm-bytes 1G --vm-keep -m 1
Hier würde stress nun 1GB Speicher dauerhaft belegen. (Abbruch mit STRG-C). Wenn der gewählte Wert nun über den bei memory.limit_in_bytes (inkl. aller bisher laufender Prozesse) geht, dann wird das Programm stress sofort vom OOM-Killer "ermordet". Damit kann man das schön simulieren.
Ebenso, in dem man z.B. mit stress nur soviel Speicher belegt, das die max. festgelegte Grenze noch nicht erreicht würde - aber knapp oder demnächst. Dann kann man mit anderen Programmen testen wie die sich beim Killen verhalten, z.B. was passiert mit dem Firefox wenn ich noch ein paar Tabs öffne? Was passiert mit meinem Libreoffice-Dokument(ungespeichert<sic!>), wenn ich noch etliche MB Text einfüge und so über die "magische" Grenze komme?
Deswegen halt auch der Testuser.
Ich selbst bin da auch nicht sehr dick drin in der Materie, aber es ist definitiv eine wirkungsvolle Maßnahme um User und deren Prozesse einzuschränken.
//Edit:
¹ sudo (außer du kennst das Problem und weißt, wie du es umgehst)