Limitazione dell'utilizzo delle risorse di processo in AL2 023 utilizzando systemd - Amazon Linux 2023
Controllo delle risorse con esecuzione di comandi systemd-run singoliControllo delle risorse in un servizio systemd

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. systemdUsing è un sostituto potente e facile da usare della manipolazione cgroups manuale o dell'utilizzo di utilità comecpulimit, in precedenza, disponibili solo per Amazon Linux nel repository di terze parti. EPEL

Per informazioni complete, consulta la systemd documentazione originale di systemd.resource-control o il man pagina relativa a un'istanza 023. systemd.resource-control AL2

Gli esempi seguenti utilizzeranno lo stress test della stress-ng CPU (stress-ngincluso 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.

Esempio 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

  2. 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'--useropzione indica systemd-run di eseguire il comando come utente con cui abbiamo effettuato l'accesso, l'--ttyopzione indica a TTY è allegato, --wait significa attendere il completamento del servizio e l'--property=CPUAccounting=1opzione 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

Esempio 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.

  2. 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 consumatostress-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.

Esempio 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.

  2. 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 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 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 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 (MemoryMaxal 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.

Esempio 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

  2. 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

  3. 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.

  4. Ora che memcached è installato e funzionante, possiamo osservare che funziona inserendo alcuni dati casuali nella cache

    /etc/sysconfig/memcachedNella 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.

  5. 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

  6. Dì di systemd ricaricarne la configurazione

    [ec2-user ~]$ sudo systemctl daemon-reload

  7. 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.

  8. 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.

  9. 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'.