Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Begrenzung der Nutzung von Prozessressourcen in AL2 023 mithilfe von systemd
Für Amazon Linux 2023 (AL2023) empfehlen wir die Verwendung, `systemd` um zu kontrollieren, welche Ressourcen von Prozessen oder Prozessgruppen verwendet werden können. Using `systemd` ist ein leistungsfähiger und benutzerfreundlicher Ersatz für `cgroups` manuelles Bearbeiten oder für die Verwendung von Hilfsprogrammen wie[`cpulimit`](epel.md#cpulimit), die bisher nur für Amazon Linux im [EPEL](epel.md) Drittanbieter-Repository verfügbar waren.
Umfassende Informationen finden Sie in der `systemd` Upstream-Dokumentation für [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) oder im man Seite für auf einer `systemd.resource-control` 023-Instanz. AL2
In den folgenden Beispielen wird der `stress-ng` CPU-Stresstest (aus dem `stress-ng` Paket) verwendet, um eine CPU-intensive Anwendung und eine speicherintensive Anwendung `memcached` zu simulieren.
Die folgenden Beispiele behandeln die Festlegung eines CPU-Limits für einen einmaligen Befehl und eines Speicherlimits für einen Dienst. Die meisten der angebotenen `systemd` Ressourcenbeschränkungen können an jedem Ort verwendet `systemd` werden, an dem ein Prozess ausgeführt wird, und es können mehrere gleichzeitig verwendet werden. Die folgenden Beispiele beschränken sich zur Veranschaulichung auf eine einzige Einschränkung.
## Ressourcensteuerung mit `systemd-run` zum Ausführen einmaliger Befehle
Wird häufig mit Systemdiensten in Verbindung gebracht, `systemd` kann aber auch von Benutzern ohne Root-Rechte verwendet werden, um Dienste auszuführen, Timer zu planen oder einmalige Prozesse auszuführen. Im folgenden Beispiel verwenden wir es `stress-ng` als Beispielanwendung. Im ersten Beispiel werden wir es mit `systemd-run` dem `ec2-user` Standardkonto ausführen, und im zweiten Beispiel werden wir die CPU-Auslastung einschränken.
**Example Verwenden Sie `systemd-run` es in der Befehlszeile, um einen Prozess auszuführen, ohne die Ressourcennutzung einzuschränken**
1. Stellen Sie sicher, dass das `stress-ng` Paket installiert ist, da wir es für unser Beispiel verwenden werden.
```
[ec2-user ~]$ sudo dnf install -y {{stress-ng}}
```
1. Wird verwendet`systemd-run`, um einen 10-Sekunden-CPU-Stresstest durchzuführen, ohne die CPU-Auslastung einzuschränken.
```
[ec2-user ~]$ systemd-run --user --tty --wait --property=CPUAccounting=1 {{stress-ng --cpu 1 --timeout 10}}
Running as unit: run-u6.service
Press ^] three times within 1s to disconnect TTY.
stress-ng: info: [339368] setting to a 10 second run per stressor
stress-ng: info: [339368] dispatching hogs: 1 cpu
stress-ng: info: [339368] successful run completed in 10.00s
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 10.068s
CPU time consumed: 9.060s
```
Die `--user` Option weist `systemd-run` an, den Befehl als der Benutzer auszuführen, als der wir angemeldet sind. Die `--tty` Option bedeutet TTY ist angehängt, `--wait` bedeutet, dass gewartet wird, bis der Dienst beendet ist, und die `--property=CPUAccounting=1` Option weist an, `systemd-run` aufzuzeichnen, wie viel CPU-Zeit für die Ausführung des Prozesses verwendet wurde. Die `--property` Befehlszeilenoption kann verwendet werden, um `systemd-run` Einstellungen zu übergeben, die in einer `systemd.unit` Konfigurationsdatei konfiguriert werden könnten.
Wenn Sie angewiesen werden, die CPU zu belasten, verwendet das `stress-ng` Programm die gesamte verfügbare CPU-Zeit, um seinen Test für die Dauer durchzuführen, für die Sie es ausführen möchten. Für eine reale Anwendung kann es wünschenswert sein, die Gesamtlaufzeit eines Prozesses zu begrenzen. Im folgenden Beispiel bitten wir darum, dass `stress-ng` die Ausführung länger dauert als die maximale Dauer, die wir für den Vorgang festlegen. `systemd-run`
**Example Verwenden Sie `systemd-run` es in der Befehlszeile, um einen Prozess auszuführen, wobei die CPU-Auslastung auf 1 Sekunde begrenzt wird**
1. Stellen Sie sicher, dass der installiert `stress-ng` ist, um dieses Beispiel auszuführen.
1. `LimitCPU`Diese Eigenschaft entspricht dem Wert`ulimit -t`, der die maximale Zeit auf der CPU begrenzt, die dieser Prozess verwenden darf. In diesem Fall empfängt der Befehl ein `SIGXCPU` Signal und schlägt fehl, da wir einen 10-sekündigen Stresslauf anfordern und die CPU-Auslastung auf 1 Sekunde begrenzen.
```
[ec2-user ~]$ systemd-run --user --tty --wait --property=CPUAccounting=1 --property=LimitCPU=1 {{stress-ng --cpu 1 --timeout 10}}
Running as unit: run-u12.service
Press ^] three times within 1s to disconnect TTY.
stress-ng: info: [340349] setting to a 10 second run per stressor
stress-ng: info: [340349] dispatching hogs: 1 cpu
stress-ng: fail: [340349] cpu instance 0 corrupted bogo-ops counter, 1370 vs 0
stress-ng: fail: [340349] cpu instance 0 hash error in bogo-ops counter and run flag, 3250129726 vs 0
stress-ng: fail: [340349] metrics-check: stressor metrics corrupted, data is compromised
stress-ng: info: [340349] unsuccessful run completed in 1.14s
Finished with result: exit-code
Main processes terminated with: code=exited/status=2
Service runtime: 1.201s
CPU time consumed: 1.008s
```
In der Regel möchten Sie möglicherweise den Prozentsatz der CPU-Zeit einschränken, der von einem bestimmten Prozess verbraucht werden kann. Im folgenden Beispiel beschränken wir den Prozentsatz der CPU-Zeit, der verbraucht werden kann`stress-ng`. Für einen echten Dienst kann es wünschenswert sein, den maximalen Prozentsatz an CPU-Zeit zu begrenzen, den ein Hintergrundprozess verbrauchen kann, um Ressourcen für den Prozess freizugeben, der Benutzeranfragen bearbeitet.
**Example Wird verwendet`systemd-run`, um einen Prozess auf 10% der CPU-Zeit auf einer CPU zu beschränken**
1. Stellen Sie sicher, dass der installiert `stress-ng` ist, um dieses Beispiel ausführen zu können.
1. Wir werden die `CPUQuota` Eigenschaft verwenden, um anzugeben, dass `systemd-run` die CPU-Auslastung für den Befehl, den wir ausführen werden, eingeschränkt werden soll. Wir begrenzen nicht die Zeit, für die der Prozess ausgeführt werden kann, sondern nur, wie viel CPU er verwenden kann.
```
[ec2-user ~]$ systemd-run --user --tty --wait --property=CPUAccounting=1 --property=CPUQuota=10% {{stress-ng --cpu 1 --timeout 10}}
Running as unit: run-u13.service
Press ^] three times within 1s to disconnect TTY.
stress-ng: info: [340664] setting to a 10 second run per stressor
stress-ng: info: [340664] dispatching hogs: 1 cpu
stress-ng: info: [340664] successful run completed in 10.08s
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 10.140s
CPU time consumed: 1.014s
```
Beachten Sie, wie CPU Aus der Buchhaltung geht hervor, dass der Dienst zwar 10 Sekunden lang lief, aber nur 1 Sekunde der tatsächlichen CPU-Zeit beanspruchte.
Es gibt viele Konfigurationsmöglichkeiten, `systemd` um die Ressourcennutzung für CPU, Arbeitsspeicher, Netzwerk und I/O zu begrenzen. Weitere Informationen finden Sie in der `systemd` Upstream-Dokumentation für [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) oder im man Eine umfassende Dokumentation finden Sie `systemd.resource-control` auf der Seite für eine AL2 023-Instanz.
Hinter den Kulissen werden Funktionen des Linux-Kernels verwendet`cgroups`, um beispielsweise diese Grenzwerte zu implementieren, ohne dass Sie sie manuell konfigurieren müssen. `systemd` Die [Linux-Kernel-Dokumentation für `cgroup-v2`](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html) enthält ausführliche Informationen zur `cgroups` Arbeit.
## Ressourcenkontrolle in einem `systemd` Dienst
Es gibt mehrere Parameter, die dem `[Service]` Abschnitt `systemd` Dienste hinzugefügt werden können, um die Nutzung der Systemressourcen zu steuern. Dazu gehören sowohl harte als auch weiche Grenzwerte. Das genaue Verhalten der einzelnen Optionen finden Sie in der `systemd` Upstream-Dokumentation für [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) oder in man Seite für auf einer `systemd.resource-control` 023-Instanz. AL2
Häufig verwendete Grenzwerte sind `MemoryHigh` die Angabe einer Drosselungsgrenze für die Speichernutzung, `MemoryMax` die Festlegung einer festen Obergrenze (bei deren Erreichen der OOM-Killer aufgerufen wird) und `CPUQuota` (wie im vorherigen Abschnitt dargestellt). Es ist auch möglich, Gewichte und Prioritäten anstelle von festen Zahlen zu konfigurieren.
**Example Wird verwendet`systemd`, um Speichernutzungslimits für Dienste festzulegen**
In diesem Beispiel legen wir ein Limit für die Festplattennutzung für `memcached` einen einfachen Schlüsselwertcache fest und zeigen, wie der OOM-Killer für diesen Dienst und nicht für das gesamte System aufgerufen wird.
1. Zuerst müssen wir die für dieses Beispiel benötigten Pakete installieren.
```
[ec2-user ~]$ sudo dnf install -y {{memcached libmemcached-awesome-tools}}
```
1. Aktivieren Sie den `memcached.service` und starten Sie dann den Dienst, damit er `memcached` läuft.
```
[ec2-user ~]$ sudo systemctl enable {{memcached.service}}
Created symlink /etc/systemd/system/multi-user.target.wants/memcached.service → /usr/lib/systemd/system/memcached.service.
[ec2-user ~]$ sudo systemctl start {{memcached.service}}
```
1. Prüfen Sie, ob das `memcached.service` läuft.
```
[ec2-user ~]$ sudo systemctl status {{memcached.service}}
● memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
Active: active (running) since Fri 2025-01-31 22:36:42 UTC; 1s ago
Main PID: 356294 (memcached)
Tasks: 10 (limit: 18907)
Memory: 1.8M
CPU: 20ms
CGroup: /system.slice/memcached.service
└─356294 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l 127.0.0.1,::1
Jan 31 22:35:36 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: Started memcached.service - memcached daemon.
```
1. Jetzt, wo es installiert `memcached` ist und läuft, können wir beobachten, dass es funktioniert, indem wir einige zufällige Daten in den Cache einfügen
In `/etc/sysconfig/memcached` der `CACHESIZE` Variablen ist standardmäßig 64 gesetzt, was 64 Megabyte bedeutet. Wenn wir mehr Daten in den Cache einfügen als die maximale Cachegröße, können wir sehen, dass wir den Cache füllen und einige Elemente gelöscht werden`memcached-tool`, und dass der etwa 64 MB Speicher `memcached.service` beansprucht.
```
[ec2-user ~]$ for i in $(seq 1 150); do dd if=/dev/random of=$i bs=512k count=1; memcp -s localhost $i; done
[ec2-user ~]$ memcached-tool localhost display
# Item_Size Max_age Pages Count Full? Evicted Evict_Time OOM
2 120B 0s 1 0 no 0 0 0
39 512.0K 4s 63 126 yes 24 2 0
[ec2-user ~]$ sudo systemctl status {{memcached.service}}
● memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
Active: active (running) since Fri 2025-01-31 22:36:42 UTC; 7min ago
Main PID: 356294 (memcached)
Tasks: 10 (limit: 18907)
Memory: 66.7M
CPU: 203ms
CGroup: /system.slice/memcached.service
└─356294 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l 127.0.0.1,::1
Jan 31 22:36:42 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: Started memcached.service - memcached daemon.
```
1. Verwenden Sie die `MemoryMax` Eigenschaft, um ein festes Limit dafür festzulegen, `memcached.service` wo der OOM-Killer aufgerufen wird, wenn er erreicht wird. Zusätzliche Optionen können für den Dienst festgelegt werden, indem sie zu einer Override-Datei hinzugefügt werden. Dies kann entweder durch direktes Bearbeiten der `/etc/systemd/system/memcached.service.d/override.conf` Datei oder interaktiv mit dem `edit` Befehl von `systemctl` geschehen.
```
[ec2-user ~]$ sudo systemctl edit {{memcached.service}}
```
Fügen Sie der Überschreibung Folgendes hinzu, um eine feste Speicherbegrenzung von 32 MB für den Dienst festzulegen.
```
[Service]
MemoryMax=32M
```
1. Sagen Sie`systemd`, dass die Konfiguration neu geladen werden soll
```
[ec2-user ~]$ sudo systemctl daemon-reload
```
1. Beachten Sie, `memcached.service` dass der jetzt mit einem Speicherlimit von 32 MB läuft.
```
[ec2-user ~]$ sudo systemctl status {{memcached.service}}
● memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/memcached.service.d
└─override.conf
Active: active (running) since Fri 2025-01-31 23:09:13 UTC; 49s ago
Main PID: 358423 (memcached)
Tasks: 10 (limit: 18907)
Memory: 1.8M (max: 32.0M available: 30.1M)
CPU: 25ms
CGroup: /system.slice/memcached.service
└─358423 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l 127.0.0.1,::1
Jan 31 23:09:13 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: Started memcached.service - memcached daemon.
```
1. Der Dienst funktioniert normal, wenn er weniger als 32 MB Speicher verwendet. Dies können wir überprüfen, indem wir weniger als 32 MB zufälliger Daten in den Cache laden und dann den Status des Dienstes überprüfen.
```
[ec2-user ~]$ for i in $(seq 1 30); do dd if=/dev/random of=$i bs=512k count=1; memcp -s localhost $i; done
```
```
[ec2-user ~]$ sudo systemctl status {{memcached.service}}
● memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/memcached.service.d
└─override.conf
Active: active (running) since Fri 2025-01-31 23:14:48 UTC; 3s ago
Main PID: 359492 (memcached)
Tasks: 10 (limit: 18907)
Memory: 18.2M (max: 32.0M available: 13.7M)
CPU: 42ms
CGroup: /system.slice/memcached.service
└─359492 /usr/bin/memcached -p 11211 -u memcached -m 64 -c 1024 -l 127.0.0.1,::1
Jan 31 23:14:48 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: Started memcached.service - memcached daemon.
```
1. Wir können jetzt mehr als 32 MB Speicher verwenden, indem wir versuchen, die vollen 64 MB Cache zu verwenden, die in der Standardkonfiguration vorgesehen sind. `memcached` `memcached`
```
[ec2-user ~]$ for i in $(seq 1 150); do dd if=/dev/random of=$i bs=512k count=1; memcp -s localhost $i; done
```
Sie werden feststellen, dass irgendwann während des obigen Befehls Verbindungsfehler zum `memcached` Server auftreten. Dies liegt daran, dass der OOM-Killer den Prozess aufgrund der Einschränkung, die wir ihm auferlegt haben, beendet hat. Der Rest des Systems wird normal funktionieren, und der OOM-Killer berücksichtigt keine anderen Prozesse, da wir nur `memcached.service` diese eingeschränkt haben.
```
[ec2-user ~]$ sudo systemctl status {{memcached.service}}
● memcached.service - memcached daemon
Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/memcached.service.d
└─override.conf
Active: failed (Result: oom-kill) since Fri 2025-01-31 23:20:28 UTC; 2s ago
Duration: 2.901s
Process: 360130 ExecStart=/usr/bin/memcached -p ${PORT} -u ${USER} -m ${CACHESIZE} -c ${MAXCONN} $OPTIONS (code=killed, signal=KILL)
Main PID: 360130 (code=killed, signal=KILL)
CPU: 94ms
Jan 31 23:20:25 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: Started memcached.service - memcached daemon.
Jan 31 23:20:28 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: memcached.service: A process of this unit has been killed by the OOM killer.
Jan 31 23:20:28 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: memcached.service: Main process exited, code=killed, status=9/KILL
Jan 31 23:20:28 ip-1-2-3-4.us-west-2.compute.internal systemd[1]: memcached.service: Failed with result 'oom-kill'.
```