Cgroups zur Ressourcenkontrolle in Linux

Wie viel darf's denn sein?

Mit dem neuen Cgroups-Feature lässt sich bei modernen Linux-Distributionen der Ressourcen-Verbrauch etwa von Prozessen administrativ beschränken. Besonders interessant ist die Anwendung der Technologie bei virtualisierten Systemen.
Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Vor einigen Jahren führte der Autor eine Linux-Schulung bei einem großen IT-Dienstleister durch. Dessen Administratoren verfügten über umfangreiche Erfahrungen mit kommerziellen Unix-Varianten, wie etwa HP-UX, und stellten die Frage, wie sie unter Linux eine Ressourcensteuerung und -kontrolle umsetzen könnten: Wie kann ein Administrator den genutzten Arbeitsspeicher eines einzelnen Prozesses oder einer Gruppe von Prozessen beschränken?

Zum damaligen Zeitpunkt musste der Autor einräumen, dass Linux diese Funktion nicht bietet. 2006 hat jedoch Rohit Seth begonnen, diese Funktionalität zu entwickeln. Seit dem Kernel 2.6.24 kann ein Administrator diese nun auch nutzen.

Ursprünglich als "process container" bezeichnet, können die Control-Groups (kurz: cgroups) Ressourcen (Arbeitsspeicher, CPU, I/O) limitieren, priorisieren, zählen (für Abrechnungszwecke) und isolieren.

Auch wenn viele Administratoren diese Funktionalität auf einem normalen Server wahrscheinlich nicht einsetzen werden, ist sie beim Einsatz etwa von KVM-Virtualisierung sehr interessant. Mit Cgroups lassen sich die Ressourcen eines virtuellen Gastes beschränken oder gegenüber anderen Gästen priorisieren [1] .

Gruppenzwang

Mit einer Cgroup kann ein Administrator mehrere Prozesse zu einer Gruppe zusammenfassen. Diese Prozesse und sämtliche Kindprozesse kann der Administrator dann mit Parametern für bestimmte Subsysteme versehen. Ein Subsystem ist dann zum Beispiel ein Ressource-Controller, der den verfügbaren Arbeitsspeicher verwaltet. Am einfachsten illustriert dies ein Beispiel.

Um die Cgroups zu verwenden, muss der Administrator zunächst Hierarchien anlegen, in der die Gruppen verwaltet werden. Hierzu editiert er die Datei »/etc/cgconfig.conf« , die in Listing 1 zu sehen ist. Existiert die Datei noch nicht, so muss er das entsprechende Paket noch installieren. Diese Datei legt für jedes Subsystem eine eigene Hierarchie an, unterhalb derer die Cgroups angelegt werden können. Die Hierarchie »/cgroup/cpu« erlaubt die Verwaltung der CPU-Shares, während »/cgroup/net_cls« die Verwaltung der Netz-I/O-Leistung unterstützt.

Listing 1

/etc/cgconfig.conf

 

Ein Start des Cgconfig-Daemons erzeugt dann die Verzeichnisse und mountet das Cgroups-Dateisystem. Mit dem Befehl »lssubsys« kontrolliert der Admin die korrekte Erzeugung der Hierarchien ( Listing 2 ).

Listing 2

lssubsys

 

Die Control Groups legt der Administrator mit dem Befehl »cgcreate« an:

cgcreate -g blkio:/dd

Welche Parameter für das Subsystem Block-I/O zur Verfügung stehen, lässt sich mit dem Befehl in Listing 3 in Erfahrung bringen.

Listing 3

Block-I/O-Subsystem

 

Ab Kernel 2.6.37 unterstützt der Kernel hier auch die Optionen »blkio.throttle.*« . Damit kann der Administrator die maximale I/O-Bandbreite beim Lesen und Schreiben einer Prozessgruppe einschränken. Um dies zu testen, benötigt der Admin zunächst die Major- und Minor-Nummern des Gerätes, auf dem die Bandbreite eingeschränkt werden soll. Handelt es sich um »/dev/sda1« , kann er diese mit einem einfachen »ls« ermitteln:

# ls -l /dev/sda1
brw-rw----. 1 root disk 8, 1 10. Okt 08:32 /dev/sda1

Hier handelt es sich um die Major/Minor-Nummern 8 respektive 1. Um die Bandbreite für die Control-Group nun auf 1 Mbyte/s zu beschränken, verwendet er den Befehl »cgset« oder einfach ein »echo« :

echo "8:1 1048576" > /cgroup/blkio/dd/blkio.throttle.write_bps_device

Für den Test startet er nun dd.

dd if=/dev/zero of=/tmp/test & pid=$!

Zunächst arbeitet der Prozess »dd« in der Root-Cgroup, die nicht eingeschränkt ist. Dies testet der Administrator, indem er dem Prozess ein SIGUSR1 sendet:

# kill -USR1 $pid
578804+0 Datensätze ein
578804+0 Datensätze aus
296347648 Bytes (296 MB) kopiert, 7,00803 s,42,3 MB/s

Um den Prozess in die Cgroup »dd« zu verschieben, verwendet er den Befehl »echo« :

# echo $pid > /cgroups/blkio/dd/tasks

Sendet der Administrator nun erneut ein USR1-Signal an den »dd« -Prozess, erkennt er, dass die durchschnittliche Bandbreite stark sinkt, da der Prozess nun nur noch mit einer Bandbreite von 1 MByte/s schreiben darf.

Statt die maximale Bandbreite zu beschränken, kann der Admin auch die Bandbreiten zwischen den Gruppen priorisieren. Hierzu dient der Parameter »blkio.weight=« . Der Default-Wert beträgt 500. Erhält eine Gruppe den Wert 1000, so kann sie doppelt so häufig auf die Block-Geräte zugreifen wie die anderen Gruppen.

Statt des Echo-Kommandos lassen sich Prozesse auch mit dem Kommando »cgclassify« einzelnen Gruppen zuweisen.

Möchte der Admin einen Prozess direkt in einer bestimmten Gruppe starten, so verwendet er den Befehl »cgexec« :

cgexec -g blkio:dd "dd if=/dev/zero of=/tmp/test"

Automatik

Die manuelle Zuweisung von Prozessen zu verschiedenen Gruppen ist aufwendig und fehlerträchtig. Besser ist es deshalb, wenn der Daemon »cgrulesengd« diese Zuweisung auch automatisch übernimmt. Hierzu benötigt dieser Dienst die Regeldatei »/etc/cgrules.conf« , die ihm mitteilt, welcher Prozess von welchem Benutzer in welcher Control-Group landen soll. Die Datei besitzt eine recht einfache Syntax:

<user>[:<process] <controllers> <destination>

Für das Beispiel mit dem »dd« -Kommando sieht die Regel folgendermaßen aus:

*:dd blkio /dd

Dies fügt die »dd« -Prozesse sämtlicher Benutzer der Controlgroup »/dd« des Blkio-Resource-Controllers hinzu.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023