Come si può limitare il numero di core della CPU che ogni utente può usare?

Abbiamo un computer la cui CPU ha 32 core e verrà utilizzata per eseguire programmi da pochi utenti diversi. Esiste un modo per limitare il numero di core che ciascun utente può utilizzare in qualsiasi momento in modo che un utente non monopolizzi tutta la potenza della CPU?

— Reza
fonte

Non una risposta, solo un'idea. Potresti voler esaminare la configurazione di diverse macchine virtuali. Ciascuno potrebbe avere solo un numero limitato di CPU. Ogni utente sarebbe solo su una delle macchine virtuali e gli utenti su quella VM sarebbero limitati nell'uso della CPU. È possibile che alcuni dei software di virtualizzazione dispongano di strumenti a supporto di questo.

— ghellquist

@ghellquist dovresti dare una risposta

— slebetman

@ghellquist: Probabilmente vuoi qualcosa di il più leggero possibile, come i container Linux, se vuoi solo che utenti diversi vedano solo alcune delle CPU. (ad es. quando avviano un OpenMP o un altro programma che avvia tanti thread quanti ne vede i core, inizierà un numero appropriato per la quantità di core che stai lasciando effettivamente usare a ciascun utente). La virtualizzazione completa, come KVM, ha un costo in termini di prestazioni anche con supporto hardware come VT-X o AMD-V, a partire da livelli extra di tabelle di pagine anche quando si evitano le uscite delle macchine virtuali, in un codice che fa perdere a TLB qualsiasi quantità di memoria.

— Peter Cordes,

Mi dispiace, ma ce n'è ancora bisogno? Come sistema multiutente, Linux per impostazione predefinita implementa già il multitasking preventivo, quindi la situazione in cui un singolo utente (non malintenzionato) si limita a mettere da parte l'intero sistema per se stesso non dovrebbe presentarsi.

— Cubico

Risposte:

Sebbene ciò sia possibile , è complicato e quasi certamente una cattiva idea. Se al momento solo un utente sta utilizzando la macchina, limitarli a N core è uno spreco di risorse. Un approccio molto migliore sarebbe quello di eseguire tutto con nice:

NAME
       nice - run a program with modified scheduling priority

SYNOPSIS
       nice [OPTION] [COMMAND [ARG]...]

DESCRIPTION
       Run  COMMAND  with an adjusted niceness, which affects process scheduling.  With
       no COMMAND, print the current niceness.  Niceness values range  from  -20  (most
       favorable to the process) to 19 (least favorable to the process).

Questo è un ottimo strumento che imposta la priorità di un processo. Quindi, se solo un utente esegue qualcosa, otterrà tutto il tempo di CPU di cui ha bisogno, ma se qualcun altro avvia il proprio lavoro (anche bello), sarà gentile e condividerà tra loro. In questo modo, se tutti i tuoi utenti avvieranno i comandi nice 10 command, nessuno si occuperà delle risorse di risorse (e nessuno metterà in ginocchio il server).

Si noti che un valore elevato significa una priorità bassa. Questa è una misura di quanto dovremmo essere carini e più siamo carini , più condividiamo.

Si noti inoltre che ciò non aiuta a gestire l'allocazione della memoria, influisce solo sulla pianificazione della CPU. Pertanto, se più utenti avviano più processi ad alta intensità di memoria, si verificherà comunque un problema. Se questo è un problema, dovresti esaminare i sistemi di accodamento adeguati come la coppia .

— terdon
fonte

Grazie per la tua risposta. Esistono alcuni "gestori del carico di lavoro" come SLURM ma sono per computer con più nodi. Immagino abbia senso che le persone non abbiano sviluppato app simili per i computer a nodo singolo in quanto non c'è molta richiesta.

— Reza,

@Reza prova nice, da quello che descrivi, è praticamente esattamente ciò di cui hai bisogno.

— terdon

@Reza: Questo perché il sistema operativo lo fa già. Condivide automaticamente le CPU disponibili in tempo per thread / processi, se necessario.

— BlueRaja - Danny Pflughoeft

TL; DR : da una breve ricerca sembra che sia possibile limitare i comandi a un numero specifico di core, tuttavia in tutti i casi è necessario utilizzare un comando che imponga effettivamente la restrizione.

cgroups

Linux ha cgroupsspesso utilizzato esattamente allo scopo di limitare le risorse disponibili per i processi. Da una breve ricerca, puoi trovare un esempio nella configurazione di Arch Wiki con Matlab (un software scientifico) in /etc/cgconfig.conf:

group matlab {
    perm {
        admin {
            uid = username;
        }
        task {
            uid = username;
        }
    }

    cpuset {
        cpuset.mems="0";
        cpuset.cpus="0-5";
    }
    memory {
        memory.limit_in_bytes = 5000000000;
    }
}

Affinché tale configurazione abbia effetto, è necessario eseguire il processo tramite cgexeccomando, ad esempio dalla stessa pagina wiki:

$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop

taskset

Una domanda correlata su Ask Ubuntu e come limitare un processo a un core della CPU in Linux? [duplicato] sul sito Unix e Linux mostra un esempio dell'uso tasksetper limitare le CPU per il processo. Nella prima domanda, si ottiene analizzando tutti i processi per un determinato utente

$ ps aux | awk '/^housezet/{print $2}' | xargs -l taskset -p 0x00000001

Nell'altra domanda, un processo viene avviato da tasksetsolo:

$ taskset -c 0 mycommand --option  # start a command with the given affinity

Conclusione

Sebbene sia certamente possibile limitare i processi, sembra che non sia così semplice raggiungerlo per determinati utenti. L'esempio nel post Ask Ubuntu collegato richiederebbe una scansione coerente per i processi appartenenti a ciascun utente e che ne utilizzino tasksetuno nuovo. Un approccio molto più ragionevole sarebbe quello di eseguire selettivamente applicazioni ad uso intensivo di CPU, tramite cgexeco taskset; inoltre non ha senso limitare tutti i processi a un numero specifico di CPUS, specialmente per quelli che utilizzano effettivamente il parallelismo e la concorrenza per eseguire i propri compiti più velocemente; limitarli a un numero specifico di CPU può avere l'effetto di rallentare l'elaborazione. Inoltre, come indicato dalla risposta di Terdon, si tratta di uno spreco di risorse

L'esecuzione di applicazioni selezionate tramite taskseto cgexecrichiede la comunicazione con gli utenti per far loro sapere quali applicazioni possono eseguire o la creazione di script wrapper che avvieranno applicazioni selezionate tramite taskselo cgexec.

Inoltre, considera l'impostazione del numero di processi che un utente o un gruppo può generare anziché impostare il limite sul numero di CPU. Ciò può essere ottenuto tramite /etc/security/limits.conffile .

Guarda anche

Come limitare l'utilizzo delle risorse per un determinato processo?

— Sergiy Kolodyazhnyy
fonte

bene, c'è cgrulesengd e cgrules.conf per spostare automaticamente i processi nel cgroup appropriato in base all'utente / al gruppo invece di fare affidamento sugli utenti che eseguono i loro processi con cgexec. Ma sembra, configurarlo in Ubuntu è in qualche modo non banale.

— Hans-Jakob,

@ Hans-Jakob Sembra un po 'contorto, inoltre richiede l'aggiunta di flag del kernel in GRUB. Probabilmente per il livello aziendale della macchina, dove hai molti utenti e non vuoi che si arresti in modo anomalo nel sistema, è probabilmente utile, ma per il desktop - troppo lavoro. Grazie per averlo collegato.

— Sergiy Kolodyazhnyy,

sched_setaffinity(2)dice la maschera di affinità è conservato in tutto execve(2), e che un bambino eredita on fork(2). Pertanto, se si imposta la shell per un utente (o la sua shell grafica per una sessione X), tutto ciò che inizia da quella shell utilizzerà, per impostazione predefinita, la stessa maschera di affinità.

— Peter Cordes,

Un possibile svantaggio sono i programmi che controllano quante CPU ha la macchina quando decidono quanti thread avviare; avranno troppi thread per il numero di core su cui verranno effettivamente programmati. Hai scoperto se i cgroups potrebbero fare qualcosa al riguardo?

— Peter Cordes,

@PeterCordes L'idea della shell di generazione sembra interessante. Dovrò esaminarlo. Grazie ! Per quanto riguarda il secondo commento, no, non ho studiato abbastanza i cgroup a questo punto.

— Sergiy Kolodyazhnyy,