Nella prima parte di questa serie, ho discusso i concetti di base di cgroup e come i cgroup aiutano a gestire le prestazioni e la sicurezza sui server Linux. Qui nella seconda parte, discuto del valore CPUShares e di come viene utilizzato da cgroups. Non dimenticare che nella terza parte guardo all'amministrazione di cgroup e nella quarta parte concludo con cgroups mentre interagiscono con systemd.
Un po' di Linux Elevators
Per questa sezione mi concentrerò su Red Hat Enterprise Linux (RHEL). Tuttavia, nella mia rapida occhiata alle poche scatole di Ubuntu nel mio laboratorio, ho notato delle somiglianze con lo scheduler di I/O. Pertanto, alcuni dei miei punti potrebbero applicarsi anche ad altre distribuzioni. La maggior parte della famiglia di prodotti Red Hat (Fedora, CentOS e RHEL) utilizza deadline o cfq come pianificatori predefiniti.
- Completely Fair Queuing (CFQ):enfatizza l'I/O proveniente da processi in tempo reale e utilizza i dati storici per decidere se un'applicazione emetterà più richieste di I/O nel prossimo futuro.
- Scadenza:tenta di fornire una latenza garantita per le richieste ed è particolarmente adatto quando le operazioni di lettura si verificano più spesso delle operazioni di scrittura. C'è una coda per le letture e una per le scritture. Le operazioni vengono completate in base al tempo trascorso in coda e il kernel tenterà sempre di elaborare le richieste prima che sia trascorso il tempo massimo. Le operazioni di lettura hanno la precedenza sui batch di scrittura per impostazione predefinita.
Con questo in mente, RHEL tende a usare cfq per unità basate su SATA e deadline per tutti gli altri casi di default. Questo gioca un ruolo importante nella messa a punto del tuo sistema. Questi programmi di pianificazione possono essere modificati, ovviamente, e dovresti esaminare il tuo carico di lavoro e scegliere lo strumento di pianificazione più adatto alle tue attività. Vale anche la pena notare che è possibile scegliere uno scheduler per dispositivo a blocchi . Ciò significa che potresti avere più pianificatori su un unico sistema, a seconda di come sono configurati i tuoi dischi.
[ Potrebbe piacerti anche:Configurazione di server SSH containerizzati per la registrazione di sessioni con tlog ]
Condivisioni CPU
Le condivisioni CPU value fornisce attività in un cgroup con una quantità relativa di tempo CPU. Una volta che il sistema ha montato il cpu cgroup controller, è possibile utilizzare il file cpu.shares per definire il numero di azioni assegnate al cgroup. Il tempo della CPU è determinato dividendo le CPUShares di cgroup per il numero totale di CPUShares definite sul sistema. Questa matematica del tempo di CPU diventa piuttosto complicata, quindi diamo un'occhiata ad alcuni diagrammi per chiarire le cose.
Il diagramma sopra rappresenta alcuni degli elementi più comuni su un server del piano di controllo RHEL 7 OpenShift Container Platform. Ogni processo su questo sistema inizia con il / cgruppo.
In RHEL, questo inizia con la radice / cgroup con 1024 condivisioni e il 100% delle risorse della CPU. Il resto delle risorse è diviso equamente tra i gruppi /system.slice , /user.slice e /kubepod.slice , ciascuno con un peso uguale a 1024 per impostazione predefinita, come mostrato di seguito:
In questo scenario, la logica è piuttosto semplice:ogni slice può utilizzare solo il 33% delle CPUShares se tutti i cgroup richiedono condivisioni contemporaneamente. La matematica è piuttosto semplice:
E quando inserisci i numeri:
Tuttavia, cosa succede se si decide di nidificare i gruppi o modificare il peso dei gruppi allo stesso livello? Di seguito è riportato un esempio dei gruppi nidificati:
In questo esempio, vedi che ho creato un cgroup per utenti diversi. Qui è dove la matematica si fa interessante. All'inizio penseresti che la seguente equazione funzionerebbe bene:
Tuttavia, questo è solo il 23% del 33% assegnato a user.slice . Ciò significa utente1 ha circa il 7,6% del tempo CPU totale in base a questi pesi in caso di contesa di risorse.
CPUShares si è appena complicato in fretta. Per fortuna, la maggior parte degli altri controller è più semplice di questo.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
I valori CPUShares possono far sembrare i cgroup davvero complessi. Questo è parte del motivo per cui volevo coprire CPUShares qui. Tuttavia, l'uso corretto di CPUShares ti aiuta a gestire il tuo sistema in modo più efficiente e preciso.
Nel prossimo articolo di questa serie, parlerò dell'amministrazione di cgroup. Spero che continuerai a seguire questa serie. Nella quarta parte concluderò la nostra discussione con systemd e cgroups.