AGGIORNAMENTO: Notare che la seguente risposta si applica a RHEL 6. In RHEL 7, la maggior parte dei cgroups sono gestiti da systemd e libcgroup è deprecato.
Dal momento che questo distacco domanda ho studiato tutta la guida che ho linkato sopra, così come la maggior parte della cgroups.txt documentazione e cpusets.txt . Ora so più di quanto mi aspettassi di conoscere i cgroups, quindi risponderò alla mia domanda qui.
Esistono diversi approcci che puoi adottare. Il contatto della nostra azienda presso Red Hat (un architetto tecnico) ha raccomandato di non applicare una limitazione generale di tutti i processi rispetto a un approccio più dichiarativo, limitando solo i processi che volevamo specificamente limitati. La ragione di ciò, secondo le sue affermazioni sull'argomento, è che è possibile che le chiamate di sistema dipendano dal codice dello spazio utente (come i processi LVM) che, se limitato, potrebbe rallentare il sistema, l'opposto dell'effetto previsto. Così ho finito per limitare diversi processi con nomi specifici e lasciare tutto il resto da solo.
Inoltre, voglio menzionare alcuni dati di base del cgroup che mi mancavano quando ho pubblicato la mia domanda.
I cgroup non dipendono dall'installazione libcgroup
. Tuttavia, si tratta di un set di strumenti per la gestione automatica della configurazione dei cgroup e delle assegnazioni dei processi ai cgroups e può essere molto utile.
Ho scoperto che anche gli strumenti di libcgroup possono essere fuorvianti, poiché il pacchetto libcgroup è basato su una propria serie di astrazioni e ipotesi sull'uso dei cgroup, che sono leggermente diverse dall'attuale implementazione dei cgroup a livello di kernel. (Posso fare degli esempi ma ci vorrebbe del lavoro; commenta se sei interessato.)
Pertanto, prima di utilizzare strumenti libcgroup (come /etc/cgconfig.conf
, /etc/cgrules.conf
, cgexec
, cgcreate
, cgclassify
, etc.) ho fortemente raccomando di avere molta familiarità con il /cgroup
filesystem virtuale in sé, e creare manualmente cgroups, gerarchie cgroup (comprese le gerarchie con più sottosistemi allegati, che libcgroup sneakily e abstract leakily di distanza), riassegnando i processi a diversi cgroup correndo echo $the_pid > /cgroup/some_cgroup_hierarchy/a_cgroup_within_that_hierarchy/tasks
e altri compiti apparentemente magici che si libcgroup
svolgono sotto il cofano.
Un altro concetto di base che mi mancava era che se il /cgroup
filesystem virtuale è montato sul vostro sistema a tutti (o, più precisamente, se uno qualsiasi dei sottosistemi di cgroup alias "controllori" sono montati a tutti), allora ogni processo sul vostro intero sistema è in un cgroup. Non esiste una cosa come "alcuni processi sono in un cgroup e altri no".
Esiste quello che viene chiamato il cgroup radice per una determinata gerarchia, che possiede tutte le risorse del sistema per i sottosistemi collegati. Ad esempio, una gerarchia di cgroup a cui sono collegati i sottosistemi cpuset e blkio, avrebbe un cgroup di root che possederebbe tutti i cpus sul sistema e tutti i blkio sul sistema e potrebbe condividere alcune di tali risorse con i cgroup secondari. Non puoi limitare il cgroup di root perché possiede tutte le risorse del tuo sistema, quindi limitarlo non avrebbe nemmeno senso.
Alcuni altri semplici dati che mi mancavano su libcgroup:
Se lo usi /etc/cgconfig.conf
, dovresti assicurarti che chkconfig --list cgconfig
mostra che cgconfig
è impostato per essere eseguito all'avvio del sistema.
Se si modifica /etc/cgconfig.conf
, è necessario eseguire service cgconfig restart
per caricare le modifiche. (E i problemi con l'arresto del servizio o l'esecuzione cgclear
sono molto comuni quando si scherza con i test. Per il debug, ad esempio lsof /cgroup/cpuset
, si consiglia se cpuset
è il nome della gerarchia di cgroup che si sta utilizzando.)
Se si desidera utilizzare /etc/cgrules.conf
, è necessario assicurarsi che il "daemon del motore delle regole del cgroup" ( cgrulesengd
) sia in esecuzione: service cgred start
e chkconfig cgred on
. (E dovresti essere consapevole di una possibile ma improbabile condizione di gara relativa a questo servizio, come descritto nella Guida alla gestione delle risorse di Red Hat nella sezione 2.8.1 in fondo alla pagina.)
Se vuoi scherzare manualmente e configurare i tuoi cgroups usando il filesystem virtuale (che consiglio per il primo utilizzo), puoi farlo e quindi creare un cgconfig.conf
file per rispecchiare la tua configurazione usando cgsnapshot
con le sue varie opzioni.
E infine, l'informazione chiave che mi mancava quando ho scritto quanto segue:
Tuttavia, l'avvertenza su questo sembra essere ... che i figli di nomecrocessname verranno riassegnati al cgroup limitato cpu0only.
Avevo ragione, ma c'è un'opzione di cui non ero a conoscenza.
cgexec
è il comando per avviare un processo / eseguire un comando e assegnarlo a un cgroup.
cgclassify
è il comando per assegnare un processo già in esecuzione a un cgroup.
Entrambi impediranno anche cgred
( cgrulesengd
) di riassegnare il processo specificato a un diverso cgroup basato su /etc/cgrules.conf
.
Entrambi cgexec
e cgclassify
supportano la --sticky
bandiera, che impedisce inoltrecgred
di riassegnare i processi figlio in base a /etc/cgrules.conf
.
Quindi, la risposta alla domanda mentre l'ho scritta (sebbene non l'installazione che ho finito per implementare, a causa dei consigli del nostro architetto tecnico Red Hat sopra menzionati) è:
Crea il cpu0only
e anycpu
cgroup come descritto nella mia domanda. (Assicurarsi che cgconfig
sia impostato per essere eseguito all'avvio.)
Fai la * cpuset cpu0only
regola come descritto nella mia domanda. (E assicurarsi che cgred
sia impostato per essere eseguito all'avvio.)
Avviare tutti i processi che voglio senza restrizioni con: cgexec -g cpuset:anycpu --sticky myprocessname
.
Tali processi saranno illimitati e anche tutti i loro processi figlio saranno illimitati. Tutto il resto del sistema sarà limitato alla CPU 0 (una volta riavviato, poiché cgred
non applica cgrules ai processi già in esecuzione a meno che non cambino il loro EUID). Questo non è del tutto consigliabile, ma era quello che inizialmente avevo richiesto e si può fare con i cgroups.