Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Limiter l'utilisation des ressources du processus en AL2 2023 en utilisant systemd
Sur Amazon Linux 2023 (AL2023), nous vous recommandons d'utiliser `systemd` pour contrôler les ressources qui peuvent être utilisées par des processus ou des groupes de processus. Using `systemd` est une solution puissante et facile à utiliser qui remplace la manipulation `cgroups` manuelle ou l'utilisation d'utilitaires tels que [`cpulimit`](epel.md#cpulimit) ceux qui n'étaient auparavant disponibles que pour Amazon Linux dans le [EPEL](epel.md) référentiel tiers.
Pour des informations complètes, consultez la `systemd` documentation en amont de [systemd.resource-control ou](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) le man page pour `systemd.resource-control` une instance AL2 023.
Les exemples ci-dessous utiliseront le test de stress `stress-ng` du processeur (fourni dans le `stress-ng` package) pour simuler une application gourmande en processeur et `memcached` pour simuler une application gourmande en mémoire.
Les exemples ci-dessous décrivent l'imposition d'une limite de processeur pour une commande unique et d'une limite de mémoire pour un service. La plupart des contraintes de ressources `systemd` proposées peuvent être utilisées partout `systemd` où un processus est exécuté, et plusieurs peuvent être utilisées simultanément. Les exemples ci-dessous sont limités à une seule contrainte à des fins d'illustration.
## Contrôle des ressources `systemd-run` pour exécuter des commandes ponctuelles
Bien qu'il soit généralement associé aux services système, il `systemd` peut également être utilisé par des utilisateurs non root pour exécuter des services, planifier des minuteries ou exécuter des processus ponctuels. Dans l'exemple suivant, nous allons utiliser `stress-ng` comme exemple d'application. Dans le premier exemple, nous l'exécuterons `systemd-run` dans le compte `ec2-user` par défaut, et dans le second, nous limiterons son utilisation du processeur.
**Example Utilisation `systemd-run` sur la ligne de commande pour exécuter un processus, sans limiter l'utilisation des ressources**
1. Assurez-vous que le `stress-ng` package est installé, car nous allons l'utiliser pour notre exemple.
```
[ec2-user ~]$ sudo dnf install -y stress-ng
```
1. `systemd-run`À utiliser pour exécuter un test de stress du processeur de 10 secondes sans limiter la quantité de processeur qu'il peut utiliser.
```
[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
```
L'`--user`option indique `systemd-run` d'exécuter la commande en tant qu'utilisateur sous lequel nous sommes connectés, l'`--tty`option signifie un TTY est attaché, `--wait` signifie attendre que le service soit terminé, et l'`--property=CPUAccounting=1`option indique d'`systemd-run`enregistrer le temps processeur utilisé pour exécuter le processus. L'option de ligne de `--property` commande peut être utilisée pour transmettre des `systemd-run` paramètres qui peuvent être configurés dans un fichier `systemd.unit` de configuration.
Lorsqu'il est demandé de charger le processeur, le `stress-ng` programme utilise tout le temps processeur disponible pour effectuer son test pendant la durée que vous lui demandez d'exécuter. Pour une application réelle, il peut être souhaitable de limiter la durée totale d'exécution d'un processus. Dans l'exemple ci-dessous, nous vous demanderons `stress-ng` de courir pendant une durée plus longue que la limite de durée maximale que nous imposons à son utilisation`systemd-run`.
**Example À utiliser `systemd-run` sur la ligne de commande pour exécuter un processus, en limitant l'utilisation du processeur à 1 seconde**
1. Assurez-vous que le `stress-ng` est installé pour exécuter cet exemple.
1. La `LimitCPU` propriété est l'équivalent de `ulimit -t` ce qui limitera le temps maximum sur le processeur que ce processus sera autorisé à utiliser. Dans ce cas, étant donné que nous demandons un essai de stress de 10 secondes et que nous limitons l'utilisation du processeur à 1 seconde, la commande recevra un `SIGXCPU` signal et échouera.
```
[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
```
Le plus souvent, vous souhaiterez peut-être limiter le pourcentage de temps processeur qui peut être consommé par un processus particulier. Dans l'exemple ci-dessous, nous allons limiter le pourcentage de temps processeur qui peut être consommé par`stress-ng`. Pour un service réel, il peut être souhaitable de limiter le pourcentage maximal de temps processeur qu'un processus d'arrière-plan peut consommer afin de libérer des ressources pour le processus répondant aux demandes des utilisateurs.
**Example `systemd-run`À utiliser pour limiter un processus à 10 % du temps processeur sur un processeur**
1. Assurez-vous que le `stress-ng` est installé pour exécuter cet exemple.
1. Nous allons utiliser la `CPUQuota` propriété `systemd-run` to tell pour limiter l'utilisation du processeur pour la commande que nous allons exécuter. Nous ne limitons pas la durée pendant laquelle le processus peut s'exécuter, ni la quantité de processeur qu'il peut utiliser.
```
[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
```
Notez comment le CPU la comptabilité nous indique que même si le service a fonctionné pendant 10 secondes, il n'a consommé qu'une seconde de temps processeur réel.
Il existe de nombreuses méthodes de configuration `systemd` pour limiter l'utilisation des ressources du processeur, de la mémoire, du réseau et des E/S. Consultez la `systemd` documentation en amont de [systemd.resource-control ou](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) le man page pour `systemd.resource-control` une instance AL2 023 pour une documentation complète.
Dans les coulisses, `systemd` il utilise les fonctionnalités du noyau Linux, notamment `cgroups` pour implémenter ces limites tout en évitant de les configurer manuellement. La [documentation du noyau Linux pour `cgroup-v2`](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html) contient de nombreux détails sur le `cgroups` travail.
## Contrôle des ressources dans un `systemd` service
Plusieurs paramètres peuvent être ajoutés à la `[Service]` section des `systemd` services pour contrôler l'utilisation des ressources du système. Il s'agit à la fois de limites strictes et souples. Pour connaître le comportement exact de chaque option, reportez-vous à la `systemd` documentation en amont de [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) ou au man page pour `systemd.resource-control` une instance AL2 023.
Les limites couramment utilisées consistent `MemoryHigh` à spécifier une limite d'utilisation de la mémoire, `MemoryMax` à définir une limite supérieure stricte (une fois atteinte, le OOM Killer est invoqué) et `CPUQuota` (comme illustré dans la section précédente). Il est également possible de configurer des poids et des priorités plutôt que des nombres fixes.
**Example Utilisation `systemd` pour définir les limites d'utilisation de la mémoire sur les services**
Dans cet exemple`memcached`, nous allons définir une limite d'utilisation de la mémoire dure pour un simple cache clé-valeur et montrer comment le OOM Killer est invoqué pour ce service plutôt que pour l'ensemble du système.
1. Tout d'abord, nous devons installer les packages requis pour cet exemple.
```
[ec2-user ~]$ sudo dnf install -y memcached libmemcached-awesome-tools
```
1. Activez le, `memcached.service` puis démarrez le service pour qu'`memcached`il fonctionne.
```
[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. Vérifiez qu'`memcached.service`il fonctionne.
```
[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. Maintenant qu'il `memcached` est installé et en cours d'exécution, nous pouvons observer qu'il fonctionne en insérant des données aléatoires dans le cache
Dans `/etc/sysconfig/memcached` la `CACHESIZE` variable est définie sur 64 par défaut, ce qui signifie 64 mégaoctets. En insérant plus de données dans le cache que la taille maximale du cache, nous pouvons constater que nous remplissons le cache et que certains éléments sont expulsés`memcached-tool`, et qu'`memcached.service`il utilise environ 64 Mo de mémoire.
```
[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. Utilisez cette `MemoryMax` propriété pour définir une limite stricte quant à l'`memcached.service`endroit où, s'il est touché, le OOM Killer sera invoqué. Des options supplémentaires peuvent être définies pour le service en les ajoutant à un fichier de remplacement. Cela peut être fait soit en éditant directement le `/etc/systemd/system/memcached.service.d/override.conf` fichier, soit de manière interactive à l'aide de la `edit` commande de`systemctl`.
```
[ec2-user ~]$ sudo systemctl edit memcached.service
```
Ajoutez ce qui suit à la dérogation pour définir une limite stricte de 32 Mo de mémoire pour le service.
```
[Service]
MemoryMax=32M
```
1. Dites `systemd` de recharger sa configuration
```
[ec2-user ~]$ sudo systemctl daemon-reload
```
1. Notez que le `memcached.service` fonctionne maintenant avec une limite de mémoire de 32 Mo.
```
[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. Le service fonctionnera normalement en utilisant moins de 32 Mo de mémoire, ce que nous pouvons vérifier en chargeant moins de 32 Mo de données aléatoires dans le cache, puis en vérifiant l'état du service.
```
[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. Nous pouvons maintenant `memcached` utiliser plus de 32 Mo de mémoire en essayant d'utiliser les 64 Mo de cache complets de la `memcached` configuration par défaut.
```
[ec2-user ~]$ for i in $(seq 1 150); do dd if=/dev/random of=$i bs=512k count=1; memcp -s localhost $i; done
```
Vous remarquerez qu'à un moment donné au cours de la commande ci-dessus, des erreurs de connexion au `memcached` serveur se produisent. Cela est dû au fait que le OOM Killer a annulé le processus en raison de la restriction que nous lui avons imposée. Le reste du système fonctionnera normalement, et aucun autre processus ne sera pris en compte par l'OOM Killer, car c'est uniquement celui `memcached.service` que nous avons restreint.
```
[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'.
```