Cgroups with systemd slices: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Zeile 106: Zeile 106:
  
 
Instead of showing you the output from top, now is a good time to introduce you to systemd-cgtop. It works in a similar fashion to regular top except it gives you a breakdown per slice, and then again by services in each slice. This is very helpful in determining whether you are making good use of cgroups in general on your system. As seen below, systemd-cgtop shows both the aggregation for all services in a particular slice as part of the overall system and the resource utilization of each service in a slice:
 
Instead of showing you the output from top, now is a good time to introduce you to systemd-cgtop. It works in a similar fashion to regular top except it gives you a breakdown per slice, and then again by services in each slice. This is very helpful in determining whether you are making good use of cgroups in general on your system. As seen below, systemd-cgtop shows both the aggregation for all services in a particular slice as part of the overall system and the resource utilization of each service in a slice:
−
=Using systemctl set-property=
+
=Nutzen von systemctl set-property=
 +
Die letzte Methode, die zum Konfigurieren von cgroups verwendet werden kann, ist der Befehl systemctl set-property. Ich beginne mit einer grundlegenden Dienstdatei md5sum.service:
  
−
The last method that can be used to configure cgroups is the systemctl set-property command. I'll start with a basic service file md5sum.service:
+
[Service]
 +
Type=oneshot
 +
ExecStart=/root/generate_load3.sh
 +
TimeoutSec=0
 +
StandardOutput=tty
 +
RemainAfterExit=yes
 +
Slice=AWESOME.slice
  
−
[Service]
+
[Install]
−
Type=oneshot
+
WantedBy=multi-user.target
−
ExecStart=/root/generate_load3.sh
 
−
TimeoutSec=0
 
−
StandardOutput=tty
 
−
RemainAfterExit=yes
 
−
Slice=AWESOME.slice
 
  
−
[Install]
+
Mit dem Befehl systemctl set-property werden die Dateien in  
−
WantedBy=multi-user.target
+
/etc/systemd/system.control
−
Using the systemctl set-property command places the files in /etc/systemd/system.control. These files are not to be edited by hand. Not every property is recognized by the set-property command, so the Slice definition was put in the service file itself.
+
abgelegt. Diese Dateien dürfen nicht von Hand bearbeitet werden. Nicht jede Eigenschaft wird vom set-property-Befehl erkannt, daher wurde die Slice-Definition in die Dienstdatei selbst eingefügt.
  
−
After I have set up the unit file and reloaded the daemon, I use the systemctl command similar to the following:
+
Nachdem ich die Unit-Datei eingerichtet und den Daemon neu geladen habe, verwende ich den systemctl-Befehl ähnlich dem folgenden:
  
−
# systemctl set-property md5sum.service CPUShares=1024
+
*systemctl set-property md5sum.service CPUShares=1024
−
This creates a drop-in file for you located at /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf. Feel free to look at the files if you are curious as to their contents. As these files are not meant to be edited by hand, I won't spend any time on them.
 
  
−
You can test to see if the changes have taken effect by running:
+
Dadurch wird eine Drop-In-Datei für Sie erstellt, die sich unter
 +
/etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf
 +
befindet. Schauen Sie sich die Dateien gerne an, wenn Sie neugierig auf deren Inhalt sind. Da diese Dateien nicht dazu gedacht sind, von Hand bearbeitet zu werden, werde ich keine Zeit damit verbringen.
  
−
systemctl start md5sum.service cat.service sha256sum.service
+
Sie können testen, ob die Änderungen wirksam wurden, indem Sie Folgendes ausführen:
−
As you see in the screenshot below, the changes appear to be successful. sha256sum.service is configured for 2048 CPUShares, while md5sum.service has 1024. Finally, cat.service has 256.
 
  
−
Image
+
*systemctl start md5sum.service cat.service sha256sum.service
−
ctop displaying different CPUShare configurations for different processes
 
−
[ Thinking about security? Check out this free guide to boosting hybrid cloud security and protecting your business. ]
 
  
−
Wrap up
+
Wie Sie im Screenshot unten sehen, scheinen die Änderungen erfolgreich zu sein. sha256sum.service ist für 2048 CPUShares konfiguriert, während md5sum.service 1024 hat. Schließlich hat cat.service 256.
−
Hopefully, you learned something new throughout our journey together. There was a lot to tackle, and we barely even scratched the surface on what is possible with cgroups. Aside from the role that cgroups play in keeping your system healthy, they also play a part in a "defense-in-depth" strategy. Additionally, cgroups are a critical component for modern Kubernetes workloads, where they aid in the proper running of containerized processes. Cgroups are responsible for so many things, including:
 
  
−
Limiting resources of processes.
+
=Quellen=
−
Deciding priorities when contentions do arise.
+
*https://www.redhat.com/sysadmin/cgroups-part-four
−
Controlling access to read/write and mknod devices.
 
−
Providing a high level of accounting for processes that are running on a system.
 
−
One could argue that containerization, Kubernetes, and a host of other business-critical implementations would not be possible without leveraging cgroups.
 
−
 
 
−
If you have any questions or comments or perhaps other article ideas, feel free to reach out to me on Twitter. I look forward to hearing all your feedback.
 
  
 
=Links=
 
=Links=
 
*https://www.redhat.com/sysadmin/cgroups-part-four
 
*https://www.redhat.com/sysadmin/cgroups-part-four

Version vom 15. Januar 2023, 08:51 Uhr

Prinzip

  • Standardmäßig erstellt systemd eine neue cgroup unter system.slice für jeden Dienst, den es überwacht.
  • Das ausführen von systemd-cgls zeigt die folgenden Dienste unter system.slice (die Ausgabe ist der Kürze halber abgeschnitten):
  • Sie können dieses Verhalten ändern, indem Sie die systemd-Dienstdatei bearbeiten.
  • Es gibt drei Optionen in Bezug auf die cgroup-Verwaltung mit systemd:
    • Bearbeiten der Servicedatei selbst.
    • Verwendung von Drop-in-Dateien.
    • Verwenden von systemctl set-property-Befehlen, die mit dem manuellen Bearbeiten der Dateien identisch sind, aber systemctl erstellt die erforderlichen Einträge für Sie.

Auf diese gehe ich weiter unten näher ein.

Servicedateien bearbeiten

  • Lassen Sie uns die Unit-Datei selbst bearbeiten.
  • Dazu habe ich eine sehr einfache Unit-Datei erstellt, die ein Skript ausführt:

Unit Datei

  • /etc/systemd/system/generate-load.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/generate_load.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Das Skript

  • cat /usr/local/bin/generate_load.sh
#!/bin/bash
/usr/bin/cat /dev/urandom > /dev/null &

Starten des Dienstes

  • systemcl start generate-load.service
  • systemd-cgls
Control group /:
...
└─system.slice 
  ├─prog.service 
  │ └─47462 netcat -lp 99 -s 127.0.0.1
  ├─systemd-udevd.service 
  │ └─212 /lib/systemd/systemd-udevd
  ├─cron.service 
  │ └─296 /usr/sbin/cron -f
  ├─systemd-journald.service 
  │ └─192 /lib/systemd/systemd-journald
  ├─ssh.service 
  │ └─410 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─rsyslog.service 
  │ └─303 /usr/sbin/rsyslogd -n -iNONE
  ├─generate-load.service 
  │ └─50387 /usr/bin/cat /dev/urandom
...

Eigener Slice

  • Was passiert, wenn ich der systemd-Dienstdatei die folgende Zeile hinzufüge?
Slice=my-beautiful.slice
  • Die Ausgabe von systemd-cgls zeigt etwas Merkwürdiges. Der generate-load.service ist nun tief verschachtelt:
  • systemd-cgls
Control group /:
-.slice
├─my.slice 
│ └─my-beautiful.slice 
│   └─my-beautiful.slice 
│     └─generate-load.service 
│       └─53737 /usr/bin/cat /dev/urandom
  • Warum ist das? Die Antwort hat damit zu tun, wie systemd verschachtelte cgroups interpretiert.
  • Kinder werden folgendermaßen deklariert: -.slice. Da systemd versucht, hilfreich zu sein, wenn ein übergeordnetes Element nicht existiert, erstellt systemd es für Sie.
  • Wenn ich Unterstriche _ anstelle von Bindestrichen verwendet hätte, wäre das Ergebnis so gewesen, wie Sie es erwartet hätten:

Verwendung von Drop-in-Dateien

  • Drop-in-Dateien für systemd sind ziemlich einfach einzurichten.
  • Erstellen Sie zunächst ein geeignetes Verzeichnis basierend auf dem Namen Ihres Dienstes in /etc/systemd/system.
  • Führen Sie im cat-Beispiel den folgenden Befehl aus:
  • mkdir -p /etc/systemd/system/generate-load.service.d/
  • Diese Dateien können beliebig organisiert werden.
  • Sie werden basierend auf der numerischen Reihenfolge ausgeführt, daher sollten Sie Ihre Konfigurationsdateien etwa 10-CPUSettings.conf benennen.
  • Alle Dateien in diesem Verzeichnis sollten die Dateierweiterung .conf haben und erfordern, dass Sie jedes Mal, wenn Sie eine dieser Dateien anpassen, systemctl daemon-reload ausführen.
  • Ich habe zwei Drop-In-Dateien erstellt, um zu zeigen, wie Sie verschiedene Konfigurationen aufteilen können.
  • Die erste ist 00-slice.conf. Wie unten zu sehen ist, richtet es die Standardoptionen für ein separates Slice für den cat-Dienst ein:
[Service]
Slice=AWESOME.slice
MemoryAccounting=yes
CPUAccounting=yes
  • The other file sets the number of CPUShares, and it's called 10-CPUSettings.conf.
[Service]
CPUShares=256

To show that this method works, I create a second service in the same slice. To make it easier to tell the processes apart, the second script is slightly different:

  1. !/bin/bash

/usr/bin/sha256sum /dev/urandom > /dev/null & I then simply created copies of the cat files, replacing the script and changing the CPUShares value:

  1. sed 's/load\.sh/load2\.sh/g' cat.service > sha256sum.service
  2. cp -r cat.service.d sha256sum.service.d
  3. sed -i 's/256/2048/g' sha256sum.service.d/10-CPUSettings.conf

Finally, reload the daemon and start the services:

  1. systemctl daemon-reload
  2. systemctl start cat.service
  3. systemctl start sha256sum.service

Instead of showing you the output from top, now is a good time to introduce you to systemd-cgtop. It works in a similar fashion to regular top except it gives you a breakdown per slice, and then again by services in each slice. This is very helpful in determining whether you are making good use of cgroups in general on your system. As seen below, systemd-cgtop shows both the aggregation for all services in a particular slice as part of the overall system and the resource utilization of each service in a slice:

Nutzen von systemctl set-property

Die letzte Methode, die zum Konfigurieren von cgroups verwendet werden kann, ist der Befehl systemctl set-property. Ich beginne mit einer grundlegenden Dienstdatei md5sum.service: 

[Service]
Type=oneshot
ExecStart=/root/generate_load3.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
Slice=AWESOME.slice

[Install]
WantedBy=multi-user.target

Mit dem Befehl systemctl set-property werden die Dateien in 

/etc/systemd/system.control

abgelegt. Diese Dateien dürfen nicht von Hand bearbeitet werden. Nicht jede Eigenschaft wird vom set-property-Befehl erkannt, daher wurde die Slice-Definition in die Dienstdatei selbst eingefügt.

Nachdem ich die Unit-Datei eingerichtet und den Daemon neu geladen habe, verwende ich den systemctl-Befehl ähnlich dem folgenden:

  • systemctl set-property md5sum.service CPUShares=1024

Dadurch wird eine Drop-In-Datei für Sie erstellt, die sich unter 

/etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf

befindet. Schauen Sie sich die Dateien gerne an, wenn Sie neugierig auf deren Inhalt sind. Da diese Dateien nicht dazu gedacht sind, von Hand bearbeitet zu werden, werde ich keine Zeit damit verbringen.

Sie können testen, ob die Änderungen wirksam wurden, indem Sie Folgendes ausführen:

  • systemctl start md5sum.service cat.service sha256sum.service

Wie Sie im Screenshot unten sehen, scheinen die Änderungen erfolgreich zu sein. sha256sum.service ist für 2048 CPUShares konfiguriert, während md5sum.service 1024 hat. Schließlich hat cat.service 256.

Quellen

Links

Abgerufen von „http://wiki.ixheim.de/index.php?title=Cgroups_with_systemd_slices&oldid=39887“