Ressourcen-Verwaltung mit Control Groups (cgroups)

Group CPU Scheduler-Subsystem

Das Group CPU Scheduler-Subsystem erlaubt, die CPU-Shares des Completely Fair Scheduler (CFS) einer Prozess-Gruppe zu konfigurieren. Hierzu muss der Kernel mit der Option CONFIG_FAIR_GROUP_SCHED=y übersetzt worden sein. CPU-Shares geben das Verhältnis von CPU-Bandbreite bzw. CPU-Zeit-Anteilen an, die zwischen allen Control Groups aufgeteilt werden. Der Standartwert bei neu erstellten Gruppen und der Root-Gruppe beträgt 1024. Soll ein Prozess oder eine Gruppe von Prozessen nur halb so viel CPU-Bandbreite erhalten wie die Root-Gruppe, wird die Pseudodatei cpu.shares auf 512 gesetzt. Um die doppelte CPU-Bandbreite zu erhalten, wird der doppelte Wert, relativ zu der/den anderen Gruppen (2048), gesetzt.

Dies ermöglicht zum Beispiel, dass zwei gleichberechtigte Gruppen sich fair die verfügbaren CPU-Ressourcen (50%/50%) teilen. Bei drei gleichberechtigten Gruppen erhält jede Gruppe jeweils nur 33%. Bei zwei Gruppen mit einem CPU-Share von 1024 und drei Gruppen mit einem CPU-Share von 512 erhalten letztere nur 14,3% der CPU-Bandbreite: (512 / (2*1024 + 3*512) = 1/7.

Selbst wenn in einer Gruppe in kürzester Zeit mehrere tausend Prozesse gestartet werden (z.B. ein Kernel-Build mit mehreren Build-Jobs parallel, eine Fork-Bombe, ...), wird eine gleichberechtigte Gruppe nicht benachteiligt, selbst wenn in dieser nur ein Prozess laufen sollte. Dies ist beispielsweise dann hilfreich, wenn auf einem System parallel zwei Dienste gleichberechtigt betrieben werden sollen, die aus mehreren Prozessen bestehen. Für jeden Dienst wird eine Gruppe erstellt und diese bekommt denselben Wert in cpu.shares zugewiesen.

Sollte nun der erste Dienst sehr starke Last verursachen, würde dadurch der zweite Dienst keine Abstriche an CPU-Zeit erfahren. Dies ist selbst dann der Fall, wenn der erste Dienst aufgrund eines Fehlverhaltens mehr und mehr Instanzen mit hoher Last erzeugen sollte und droht, das komplette System unbrauchbar zu machen. Der Administrator kann sich dann nach wie vor ohne Probleme via Netzwerk in das System einloggen, da die System-Prozesse sich in einer weiteren Gruppe befinden, welche ebenfalls einen garantieren Anteil an der CPU-Zeit zugewiesen bekommt. Ohne diese Gruppenaufteilung von CPU-Shares wäre eventuell bei hoher Last das System unbrauchbar und könnte nur durch Betätigung des Netzschalters neu gestartet werden. Hierbei handelt es sich allerdings um keine CPU-Drosselung. Freie CPU-Ressourcen gehen nach wie vor an die jeweilige Gruppe und den Prozess, der diese benötigt.

Das aufgestellte Szenario lässt sich mit einfachen Shellbefehlen folgendermaßen nachvollziehen:

# cd /cgroup
# mkdir -p profs students

# taskset -c 1 yes profs > /dev/null &
[1] 26391

# taskset -c 1 yes students > /dev/null &
[2] 26392

# ps -C yes -o pid,args
PID COMMAND
26391 yes profs
26392 yes students

# echo 26391 > profs/tasks 
# echo 26392 > students/tasks

# ps -C yes -o pid,%cpu,psr,args,etime
PID %CPU PSR COMMAND                         ELAPSED
26391 49.2   1 yes profs                         02:31
26392 49.8   1 yes students                      02:27

Die Control Groups profs und students werden erstellt. Anschließend werden zwei simple Endlos-Schleifen mit CPU-Affinität zu einer einzigen CPU gestartet, um sicherzustellen, dass beide Prozesse sich auf derselben CPU die CPU-Zeit fair teilen müssen. Ansonsten würden die Prozesse auf weitere freie CPUs springen und die Demonstration verfälschen. Mit der formatierten Ausgabe von ps ist zu sehen, dass beide Prozesse prozentual ziemlich genau die Hälfte an Ressourcen erhalten. (Das %CPU-Ergebnis pendelt sich mit der Zeit auf die Ausgabe ein, siehe Spalte etime).

Um die Funktion des Group Schedulers zu demonstrieren, simulieren wir den bereits beschriebenen Zwischenfall, dass ein Prozess unerwarteterweise ein Fehlverhalten aufweist und schlagartig viele Prozesse mit einer hohen CPU-Last erzeugt:

# echo 0 > students/tasks

# for n in `seq 0 100`; do `taskset -c 1 yes misbehave > /dev/null &` ; done

# ps -C yes -o pid,%cpu,psr,args,etime | head
PID %CPU PSR COMMAND                         ELAPSED
26391 50.5   1 yes profs                         08:20
26392 38.5   1 yes students                      08:16
26672  2.6   1 yes misbehave                     01:18
26682  2.6   1 yes misbehave                     01:18
26684  2.6   1 yes misbehave                     01:18
[... 97 ähnliche Zeilen ...]

Mit dem Schreiben von 0 in die Datei students/tasks wird der aktuelle Prozess (Shell) der Gruppe students zugewiesen. Anschließend erzeugen wir in dieser Shell 100 Prozesse, die starke CPU-Last erzeugen (yes). Die Ausgabe von ps zeigt, wie der Prozess yes students unter den neuen Prozessen leidet und weniger Ressourcen erhält. Der Prozess yes profs in der Gruppe profs bleibt davon unbeeindruckt und erhält nach wie vor die 50% CPU-Anteile, die der Gruppe zustehen.