Utilizzo e comprensione delle opzioni relative alla pianificazione di systemd in un contesto desktop

Nei file di servizio di systemd, è possibile impostare le seguenti opzioni relative alla pianificazione (dalla systemd.execpagina man , correggimi se sbaglio):

Nice Imposta il livello di default predefinito (priorità di pianificazione) per i processi eseguiti. Prende un numero intero compreso tra -20 (priorità più alta) e 19 (priorità più bassa). Vedi setpriority (2) per i dettagli.

Qual è il bel livello familiare. Sembra che il suo effetto sia "sovvertito" in qualche modo a causa della funzione "autogruppo" dei kernel Linux recenti. Quindi le opzioni di seguito potrebbero essere ciò che vorrei davvero impostare per mantenere i processi comportarsi bene per la mia esperienza desktop.

CPUSchedulingPolicy Imposta il criterio di pianificazione della CPU per i processi eseguiti. Ne prende uno, batch, inattivo, fifo o rr. Vedi sched_setscheduler (2) per i dettagli.

CPUSchedulingPriority Imposta la priorità di pianificazione della CPU per i processi eseguiti. L'intervallo di priorità disponibile dipende dal criterio di pianificazione della CPU selezionato (vedere sopra). Per le politiche di pianificazione in tempo reale è possibile utilizzare un numero intero compreso tra 1 (priorità più bassa) e 99 (priorità più alta). Vedi sched_setscheduler (2) per i dettagli.

CPUSchedulingResetOnFork Accetta un argomento booleano. Se è vero, le priorità e i criteri di pianificazione della CPU elevati verranno reimpostati quando i processi eseguiti si biforcano e non possono quindi passare nei processi figlio. Vedi sched_setscheduler (2) per i dettagli. Il valore predefinito è false.

Capisco l'ultima opzione. Dalla spiegazione dei primi due desidero che posso scegliere una politica di pianificazione e quindi, data tale politica, una priorità. Non mi è del tutto chiaro cosa dovrei scegliere per quale tipo di attività. Ad esempio, è sicuro scegliere "inattivo" per le attività di backup (relativamente intensivo per la CPU, perché deduplicato), oppure è un altro più adatto?

In generale, ottenere una panoramica comprensibile di ciascuna politica, con ciascuna delle sue priorità e l'idoneità per scopi specifici è quello che sto cercando. Anche l'interazione con il bel livello è interessante.

Accanto alla programmazione della CPU, c'è la programmazione IO. Immagino che ciò corrisponda a ionice(correggimi se sbaglio).

IOSchedulingClass Imposta la classe di pianificazione I / O per i processi eseguiti. Prende un numero intero compreso tra 0 e 3 o una delle stringhe none, realtime, best-effort o inattivo. Vedere ioprio_set (2) per i dettagli.

IOSchedulingPriority Imposta la priorità di pianificazione I / O per i processi eseguiti. Accetta un numero intero compreso tra 0 (priorità più alta) e 7 (priorità più bassa). Le priorità disponibili dipendono dalla classe di pianificazione I / O selezionata (vedere sopra). Vedere ioprio_set (2) per i dettagli.

Qui vediamo la stessa struttura della programmazione della CPU. Sto cercando anche lo stesso tipo di informazioni.

Per tutte le opzioni di "Pianificazione", le pagine man di riferimento non sono abbastanza chiare per me, soprattutto nel tradurre le cose in un punto di vista dell'utente desktop un po 'incline tecnicamente.

CPUScheduling {privacy | Priorità}

Il link ti dice che CPUSchedulingPrioritydovrebbe essere impostato solo per la fifoo rrle attività ( "real-time"). Non si desidera forzare la pianificazione in tempo reale dei servizi.

CPUSchedulingPolicy=other è l'impostazione predefinita.

Che lascia batche idle. La differenza tra loro è rilevante solo se si hanno più attività con priorità inattiva che consumano CPU contemporaneamente. In teoria batchoffre una maggiore produttività (in cambio di latenze più lunghe). Ma non è una grande vittoria, quindi non è davvero rilevante in questo caso.

idlemuore di fame se qualcos'altro vuole la CPU. La priorità della CPU è alquanto meno significativa di una volta, per i vecchi sistemi UNIX con un singolo core. Sarei più felice a cominciare nice, ad es. Con un buon livello 10 o 14, prima di ricorrere idle. Vedi la prossima sezione.

Tuttavia, la maggior parte dei desktop è relativamente inattiva per la maggior parte del tempo. E quando si dispone di un hog della CPU che anticipa l'attività in background, è comune per l'hog utilizzare solo una delle CPU. Con questo in mente, non mi sentirei troppo rischioso idlenel contesto di un desktop o laptop medio. A meno che non abbia una CPU Atom / Celeron / ARM classificata o inferiore a circa 15 watt ; allora vorrei guardare le cose un po 'più attentamente.

Il buon livello è "sovvertito" dalla funzione "autogruppo" del kernel?

Si.

Il raggruppamento automatico è un po 'strano. L'autore di systemdnon ha apprezzato l'euristica, nemmeno per i desktop. Se si desidera provare a disabilitare il raggruppamento automatico, è possibile impostare sysctl kernel.sched_autogroup_enabled su 0. Immagino sia meglio testare impostando il sysctl in configurazione permanente e riavviando, per assicurarsi di sbarazzarsi di tutti i gruppi automatici.

Quindi dovresti essere in grado di raggiungere livelli piacevoli per i tuoi servizi senza alcun problema. Almeno nelle versioni correnti di systemd - vedere la sezione successiva.

Ad esempio, un buon livello 10 ridurrà il peso di ciascun thread nello scheduler della CPU Linux a circa il 10%. Il piacevole livello 14 è inferiore al 5%. (Link: formula completa )

Appendice: il buon livello è "sovvertito" dai cgroup di systemd?

L' DefaultCPUAccounting= impostazione corrente è disattivata, a meno che non possa essere abilitata senza abilitare anche il controllo della CPU in base al servizio. Quindi dovrebbe andare bene. Puoi verificarlo nella tua attuale documentazione:man systemd-system.conf

Tenere presente che il controllo CPU per servizio sarà abilitato anche quando qualsiasi servizio imposta CPU Account / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

Il seguente estratto di blog non è aggiornato (ma è ancora online). Da allora il comportamento predefinito è cambiato e la documentazione di riferimento è stata aggiornata di conseguenza.

Come impostazione predefinita, se il controller cpu è abilitato nel kernel, systemd creerà un cgroup per ciascun servizio all'avvio. Senza alcuna ulteriore configurazione, questo ha già un buon effetto: su un sistema systemd ogni servizio di sistema otterrà una quantità uniforme di CPU, indipendentemente da quanti processi è costituito. O in altre parole: sul tuo server Web MySQL otterrà la stessa quantità di CPU di Apache, anche se quest'ultima è composta da 1000 processi di script CGI, ma la prima solo con poche attività di lavoro. (Questo comportamento può essere disattivato, vedere DefaultControllers = in /etc/systemd/system.conf.)

Oltre a questo valore predefinito, è possibile configurare esplicitamente le condivisioni della CPU ottenute da un servizio con l'impostazione CPUShares =. Il valore predefinito è 1024, se aumenti questo numero assegnerai più CPU a un servizio rispetto a una inalterata a 1024, se la riduci, meno.

http://0pointer.de/blog/projects/resources.html

Il classico consiglio di messa a punto è "Non ottimizzare, benchmark".

Anziché preoccuparti della consulenza generale, inizia con un caso specifico in cui sei preoccupato per il miglioramento ed è stato valutato per avere una specifica preoccupazione in termini di prestazioni. Lascia che i dati ti consentano la giusta direttiva da ottimizzare. Con i dati, potrebbe essere chiaro se il tuo processo soffre di una cattiva priorità, sta controllando la CPU o ha un altro problema.

I desktop moderni sono spesso molto veloci per funzionare senza alcuna sintonia.