Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Limitazione dell'utilizzo delle risorse di processo in AL2 023 utilizzando systemd
Su Amazon Linux 2023 (AL2023), consigliamo di utilizzare `systemd` per controllare quali risorse possono essere utilizzate da processi o gruppi di processi. `systemd`Using è un sostituto potente e facile da usare della manipolazione `cgroups` manuale o dell'utilizzo di utilità come[`cpulimit`](epel.md#cpulimit), in precedenza, disponibili solo per Amazon Linux nel repository di terze parti. [EPEL](epel.md)
[Per informazioni complete, consulta la `systemd` documentazione originale di systemd.resource-control o il](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) man pagina relativa a un'istanza 023. `systemd.resource-control` AL2
Gli esempi seguenti utilizzeranno lo stress test della `stress-ng` CPU (`stress-ng`incluso nel pacchetto) per simulare un'applicazione che richiede un uso intensivo della CPU e `memcached` per simulare un'applicazione che utilizza molta memoria.
Gli esempi seguenti riguardano l'imposizione di un limite di CPU su un comando singolo e un limite di memoria su un servizio. La maggior parte dei vincoli di risorse `systemd` offerti può essere utilizzata in qualsiasi luogo in cui `systemd` venga eseguito un processo ed è possibile utilizzarne più di uno contemporaneamente. Gli esempi seguenti sono limitati a un singolo vincolo a scopo illustrativo.
## Controllo delle risorse con esecuzione di comandi `systemd-run` singoli
Sebbene comunemente associato ai servizi di sistema, `systemd` può essere utilizzato anche da utenti non root per eseguire servizi, pianificare timer o eseguire processi una tantum. Nel seguente esempio, useremo `stress-ng` come applicazione di esempio. Nel primo esempio, lo eseguiremo utilizzando `systemd-run` l'account `ec2-user` predefinito e nel secondo esempio imporremo dei limiti all'utilizzo della CPU.
**Example Utilizzalo `systemd-run` sulla riga di comando per eseguire un processo, senza limitare l'utilizzo delle risorse**
1. Assicurati che il `stress-ng` pacchetto sia installato, poiché lo useremo per il nostro esempio.
```
[ec2-user ~]$ sudo dnf install -y {{stress-ng}}
```
1. Utilizzalo `systemd-run` per eseguire uno stress test della CPU di 10 secondi senza limitare la quantità di CPU che può utilizzare.
```
[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`opzione indica `systemd-run` di eseguire il comando come utente con cui abbiamo effettuato l'accesso, l'`--tty`opzione indica a TTY è allegato, `--wait` significa attendere il completamento del servizio e l'`--property=CPUAccounting=1`opzione indica di registrare la quantità `systemd-run` di tempo della CPU utilizzata nell'esecuzione del processo. L'opzione della riga di `--property` comando può essere utilizzata per passare `systemd-run` impostazioni che possono essere configurate in un file di `systemd.unit` configurazione.
Quando viene richiesto di caricare la CPU, il `stress-ng` programma utilizzerà tutto il tempo di CPU disponibile per eseguire il test per la durata richiesta per l'esecuzione. Per un'applicazione reale, può essere opportuno porre un limite al tempo di esecuzione totale di un processo. Nell'esempio seguente, chiederemo di eseguire l'operazione per un periodo più lungo rispetto `stress-ng` alla limitazione della durata massima che imponiamo al suo utilizzo. `systemd-run`
**Example Utilizzalo `systemd-run` sulla riga di comando per eseguire un processo, limitando l'utilizzo della CPU a 1 secondo**
1. Assicurati che `stress-ng` sia installato per eseguire questo esempio.
1. La `LimitCPU` proprietà è l'equivalente della `ulimit -t` quale limiterà la quantità massima di tempo sulla CPU che questo processo potrà utilizzare. In questo caso, poiché chiediamo un'esecuzione di stress di 10 secondi e limitiamo l'utilizzo della CPU a 1 secondo, il comando riceverà un `SIGXCPU` segnale e fallirà.
```
[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
```
Più comunemente, potresti voler limitare la percentuale di tempo della CPU che può essere consumata da un particolare processo. Nell'esempio seguente, limiteremo la percentuale di tempo di CPU che può essere consumato`stress-ng`. Per un servizio reale, può essere opportuno limitare la percentuale massima di tempo di CPU che un processo in background può consumare per lasciare libere risorse per il processo che serve le richieste degli utenti.
**Example Consente `systemd-run` di limitare un processo al 10% del tempo di CPU su una sola CPU**
1. Assicurati che `stress-ng` sia installato per eseguire questo esempio.
1. Useremo la `CPUQuota` proprietà per indicare di `systemd-run` limitare l'utilizzo della CPU per il comando che stiamo per eseguire. Non stiamo limitando la quantità di tempo per cui il processo può essere eseguito, ma solo la quantità di CPU che può utilizzare.
```
[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
```
Nota come CPU la contabilità ci dice che mentre il servizio è stato eseguito per 10 secondi, ha consumato solo 1 secondo del tempo effettivo della CPU.
Esistono molti modi di configurazione per `systemd` limitare l'utilizzo delle risorse per CPU, memoria, rete e IO. Consultate la `systemd` documentazione originale di [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) o man pagina relativa a un'istanza 023 per una `systemd.resource-control` documentazione completa. AL2
Dietro le quinte, `systemd` si utilizzano funzionalità del kernel Linux che `cgroups` consentono di implementare questi limiti evitando la necessità di configurarli manualmente. La [documentazione del kernel Linux per `cgroup-v2`](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html) contiene dettagli dettagliati sul `cgroups` lavoro.
## Controllo delle risorse in un servizio `systemd`
È possibile aggiungere diversi parametri alla `[Service]` sezione dei `systemd` servizi per controllare l'utilizzo delle risorse di sistema. Questi includono limiti rigidi e morbidi. Per il comportamento esatto di ciascuna opzione, consulta la `systemd` documentazione originale di [systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) o man pagina per un'istanza 023. `systemd.resource-control` AL2
I limiti più comunemente usati `MemoryHigh` consistono nello specificare un limite di limitazione all'utilizzo della memoria, nell'impostare un limite massimo rigido (`MemoryMax`al quale, una volta raggiunto, viene richiamato l'OOM Killer) e `CPUQuota` (come illustrato nella sezione precedente). È anche possibile configurare pesi e priorità anziché numeri fissi.
**Example Utilizzato `systemd` per impostare i limiti di utilizzo della memoria sui servizi**
In questo esempio imposteremo un limite di utilizzo della memoria rigida per `memcached` una semplice cache chiave-valore e mostreremo come viene richiamato l'OOM Killer per quel servizio anziché per l'intero sistema.
1. Innanzitutto, dobbiamo installare i pacchetti richiesti per questo esempio.
```
[ec2-user ~]$ sudo dnf install -y {{memcached libmemcached-awesome-tools}}
```
1. Abilita `memcached.service` e poi avvia il servizio in modo che `memcached` sia in esecuzione.
```
[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. Verifica che `memcached.service` sia in esecuzione.
```
[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. Ora che `memcached` è installato e funzionante, possiamo osservare che funziona inserendo alcuni dati casuali nella cache
`/etc/sysconfig/memcached`Nella `CACHESIZE` variabile è impostato su 64 per impostazione predefinita, ovvero 64 megabyte. Inserendo nella cache una quantità di dati superiore alla dimensione massima consentita, possiamo vedere che la cache `memcached.service` viene riempita e alcuni elementi vengono eliminati utilizzando `memcached-tool` circa 64 MB di memoria.
```
[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. Utilizzate la `MemoryMax` proprietà per impostare un limite rigido per il `memcached.service` punto in cui, se viene raggiunto, verrà invocato l'OOM Killer. È possibile impostare opzioni aggiuntive per il servizio aggiungendole a un file di override. Questa operazione può essere eseguita modificando direttamente il `/etc/systemd/system/memcached.service.d/override.conf` file o utilizzando in modo interattivo il `edit` comando di. `systemctl`
```
[ec2-user ~]$ sudo systemctl edit {{memcached.service}}
```
Aggiungi quanto segue all'override per impostare un limite rigido di 32 MB di memoria per il servizio.
```
[Service]
MemoryMax=32M
```
1. Dì di `systemd` ricaricarne la configurazione
```
[ec2-user ~]$ sudo systemctl daemon-reload
```
1. Osserva che ora `memcached.service` funziona con un limite di memoria di 32 MB.
```
[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. Il servizio funzionerà normalmente utilizzando meno di 32 MB di memoria, cosa che possiamo verificare caricando meno di 32 MB di dati casuali nella cache e quindi controllando lo stato del servizio.
```
[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. Ora possiamo `memcached` utilizzare più di 32 MB di memoria tentando di utilizzare tutti i 64 MB di cache della configurazione predefinita. `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
```
Osserverai che a un certo punto durante il comando precedente ci sono errori di connessione al server. `memcached` Questo perché OOM Killer ha interrotto il processo a causa della restrizione che gli abbiamo imposto. Il resto del sistema funzionerà normalmente e nessun altro processo verrà preso in considerazione da OOM Killer, in quanto si tratta solo di quelli `memcached.service` che abbiamo limitato.
```
[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'.
```