Ich habe zwei 32 vCPU-Instanzen auf AWS/GCP. Ich versuche, die CPU-Abschirmung so einzurichten, dass die CPUs 0 und 1 vom System verwendet werden und die CPUs 2-31 abgeschirmt und nur explizit von Userspace-Threads verwendet werden.
Systeminformationen:
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
$ cat /proc/filesystems | grep cpuset
nodev cpuset
Beim Versuch, es auszuführen cset shield, wird mir jedoch eine Fehlermeldung bezüglich der Mounts angezeigt:
mount: /cpusets: none already mounted on /run/credentials/systemd-sysusers.service.
cset: **> mount of cpuset filesystem failed, do you have permission?
Ich habe mich ein bisschen mit dem cset-Code befasst und es scheint, als wäre der fehlgeschlagene Aufruf einer von
$ sudo mount -t cpuset cpuset /cpusets
mount: /cpusets: cpuset already mounted or mount point busy.
/cpusetsist ein neu erstellter Ordner und $ cat /proc/mounts | grep cpusetleer – daher scheint CPU-Set nicht woanders gemountet zu sein.
Vielleicht relevant:
$ cat /proc/mounts | grep cgroup
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
Ich vermute, dass AWS/GCP für den Hypervisor CPU-Set oder etwas Ähnliches verwenden. Ist es möglich, CPUs auf AWS/GCP zu isolieren? Wie kann ich dabei vorgehen?
Antwort1
Sie verwenden systemd, das bereits v2 ("vereinheitlichte") Kontrollgruppen gemountet hat, also verwalten nicht Sie die Kontrollgruppen, sondern systemd. Weisen Sie es an, dies über denCPUAffinity= und verwandte Optionen im [Manager]Abschnitt einer /etc/systemd/system.conf.d/50-my-cpuset-options.confDatei. Sie können dann CPUAffinity=(leer zum Zurücksetzen, nicht leer zum Hinzufügen) für die spezifischen unit.service-Dateien verwenden, die Sie vom globalen Standard ausnehmen möchten.
Sie können sogar systemd-APIs verwenden, um Ressourcenoptionen für bereits laufende Dienste vorübergehend (bis zum Neustart) über den systemctl --runtime set-property example.service ExampleOption=ValueBefehl zu ändern. Verwenden Sie dies, um die resultierenden Cgroup-Einstellungen zu bestätigen und zu messen, wie sich diese auf Ihre Systemleistung auswirken. Ich stelle mir vor, dass Sie anstelle globaler Standardeinstellungen eine messbar bessere Systemzuverlässigkeit bei Überlastung feststellen werden, wenn Sie die Fähigkeit des Schedulers, 100 % der CPU zu nutzen, nicht beeinträchtigen, sondern seine vollen Fähigkeiten verbessern. Passen Sie Ihre Prioritäten mithilfe von Nice=und IOSchedulingClass=bei den spezifischen asynchronen Hintergrundaufgaben mit niedriger Priorität, die Sie ausführen möchten, die sich aber nicht auf den Rest des Systems auswirken sollen, genauer an – lassen Sie den Affinitätshammer jedoch ungenutzt.
Theoretisch können Versorgungsunternehmen wiecSatzkönnte aktualisiert werden, um stattdessen mit solchen cgroup2-Systemmanagern zu kommunizieren und effektiv identische Abstraktionen wie zuvor anzubieten, während im Hintergrund Systemds system.sliceund Unit-Standards geändert werden, aberdiese Diskussion klingtals ob das bisher noch niemand gemacht hätte. Und da dieallumfassender Riesenbrocken Cbietet eine viel umfangreichere, gut dokumentierte und wohl vielseitigere Kontrolle über alle tollen Dinge, die der Kernel gelernt hat, es besteht dafür möglicherweise keine Notwendigkeit mehr.
Antwort2
Wie erwähnt erstellt systemd seine eigenen cgroup2-Hierarchien, die meinen Anforderungen zufolge nicht gut mit cset zusammenarbeiten.
Um dieses Verhalten unter Ubuntu 22.10 zu deaktivieren, habe ich dem Wert GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub Folgendes vorangestellt.
Wenn Sie fertig sind, sieht die Zeile ungefähr so aus:
GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=false <your_other_params>"
Wenn Sie fertig sind, müssen Sie Folgendes als Root ausführen:
update-grub
grub-install
und dann neu starten. Nach dem Neustart konnte ich die CCXs auf meiner Ryzen-CPU erfolgreich mit CSET abschirmen und alle Userland- und Systemaufgaben migrieren
Hier sind weitere Hinweise zu diesem Problem, die ich gefunden habe, falls Sie weitere Hintergrundinformationen wünschen: https://github.com/systemd/systemd/issues/13477#issuecomment-528113009 https://github.com/lxc/lxd/issues/10441