Xtelligent | Home | Wissen |

X-Letter

Kurzreferat AIX 4.3.3 Workload Manager


Bearbeitung Karin.Wenzel@xtelligent.de ( karin-wenzel.de )
Datum 18.01.2001
Originaldokument www.xtelligent.de/wissen/xlet_wlm433.htm
Abstract Kurze Vorstellung der Möglichkeiten des Workloadmanager (WLM), der seit AIX 4.3.3 Teil des Betriebssystems ist und der kontrollierten Verwaltung der Ressourcen CPU und Shared Memory dient. Von besonderem Interesse ist der WLM in Umfeldern, in denen nach einer Serverkonsolidierung die Applikationsseparierung oder die Einhaltung von differenzierten Service Level Agreements angestrebt wird.

Vorbemerkung
Der folgende Text ist eine Zusammenfassung technischer Daten und Informationen. Wir haben ihn nach bestem Wissen und Gewissen erstellt. Bitte haben Sie Verständnis dafür, dass wir dennoch keine Haftung für Irrtümer und Fehler übernehmen können. Der Text ist insbesondere kein Ratschlag und keine Handlungsanweisung. Für Übernahme und Ausführung darin enthaltener Ideen und Konzepte können wir daher keinerlei Gewähr übernehmen. Bitte beachten Sie außerdem, dass im Text gegebenenfalls Warenzeichen und Produktnamen Dritter verwendet werden - wir erkennen die entsprechenden Rechte an, bitte tun Sie dies auch. Die Urheberrechte am Text in dieser Form liegen bei Xtelligent IT Consulting GmbH. Wenn Sie diesen Text oder Teile davon verwenden oder vervielfältigen möchten, benötigen Sie dafür unsere Erlaubnis. Bitte kontaktieren Sie uns in diesem Falle. Für eine Beratung zu den im Text angesprochenen Themen stehen wir gern zur Verfügung.

Wir wünschen eine interessante Lektüre!
Das Team von Xtelligent

Xtelligent IT Consulting GmbH, Eßbaumstr. 20, D-84489 Burghausen, Tel 0700-98355443 (bundesweit max. 12,4 ct/min aus dem Festnetz der DTAG), info@xtelligent.de


Inhalt



Einführung

Der AIX Workload Manager (WLM) ist ein in AIX 4.3.3 erstmals implementiertes Tool, das dem Administrator die aktive Kontrolle der Ressourcenverwaltung von CPU-Zeit und Real Memory erlaubt. Der WLM ist in AIX enthalten und damit ohne Aufpreis nutzbar.

Ziel des WLM ist es, auf Servern, die mehrere Applikationen parallel bedienen (z.B. nach Serverkonsolidierung), eine Optimierung der Ressourcenverteilung oder eine Separierung verschiedener Applikationen zu ermöglichen. Jeder Applikation können Prioritäten und Limits für den Zugriff auf Prozessor und Memory zugeteilt werden.

Dadurch kann verhindert werden, dass eine Applikation eine andere behindert, indem sie zu viele Ressourcen an sich bindet. Auch ein Scheduling, das am Tag interaktive Prozesse bevorzugt und in der Nacht dem automatischen Batch-Prozessing Vorrang einräumt sind implementierbar. Durch geeignete Wahl der Parameter kann zum Beispiel auch erreicht werden, dass eine besonders wichtige Applikation stets im Speicher gehalten statt per Paging ausgelagert wird. Dem WLM erschließt sich damit ein weites Anwendungsfeld, von der Erhöhung der Response-Zeiten bei Workstations bis zur Sicherung der Einhaltung von Service-Level-Agreements bei SMP-Systemen mit konkurrierenden Applikationen.

Der WLM ist Teil des Kernels. Er beeinflußt über den Scheduler die Prozessor-Thread-Priorität und über den Virtual Memory Manager (VMM) die Memory-Allokation. Er ist damit ein sehr mächtiges Werkzeug, birgt aber bei Fehlkonfigurationen dadurch auch die Gefahr, die Systemleistung zu verschlechtern.

Einige der im folgenden beschriebenen Features (passiver Modus, Klassifizierung existierender Prozesse u.a.) sind erst mit APAR IY06884 implementiert.


Konzept und Überblick

Applikationen, Klassen und Ressourcen

Der WLM steuert die Ressourcenverteilung auf Basis von Klassen (class). Jede Applikation wird einer Klasse zugeteilt (z.B. alle Prozesse des Root-Users der Klasse system). Und für jede Klasse werden Sollwerte (share), Minimum- und Maximum-Limit der Ressourcennutzung (getrennt für CPU- und Memory-Nutzung) festgelegt. Außerdem wird für jede Klasse ein Tier- Wert festgelegt, der die Wichtigkeit der Klasse definiert. Bei Ressourcenknappheit werden Klassen mit höherer Wichtigkeit bevorzugt.

Auf Basis der aktuellen Ressourcennutzung aller Klassen werden dann die Priorisierungen der Speicher- oder CPU-Anforderungen der einzelnen Prozesse festgelegt. Zum Beispiel wird ein Prozess, der einer Klasse angehört, die aktuell ihren Sollwert unterschreitet, bei der Zuteilung von CPU-Zeit bevorzugt behandelt gegenüber dem Prozess einer Klasse, die nahe an ihrem Maximum-Limit operiert.

Konfiguration und Handling des WLM

Die Konfiguration des WLM (Definition der Klassen und ihrer Parameter, Zuordnungsregeln für die Applikationen) kann auf verschiedenen Wegen erfolgen:
per Texteditor und Kommandozeilen Befehlen (wlmcntrl);
per smit (smit wlm);
per webbasiertem Systemmanager (wsm wlm).

Für jede Konfiguration (es können mehrere parallel gespeichert und wechselweise aktiviert werden) wird ein Name vergeben. Die Konfiguration wird jeweils im Verzeichnis /etc/wlm/name gespeichert.

Der WLM kennt drei Modi: aktiv, passiv, stopped. Nur im aktiven Modus greift der WLM tatsächlich in die Ressourcenverwaltung ein. Sobald er gestopped wird, kehrt das System zum üblichen Verhalten zurück. Der passive Modus erlaubt den Test der WLM-Konfiguration: der WLM simuliert hier lediglich das Verhalten im Ernstfall, so dass die Korrektheit des Regelwerks geprüft werden kann und auch statistische Daten zur Optimierung der Parameter gesammelt werden können.

Der WLM ist in einer Standardinstallation zunächst inaktiv. Er kann jederzeit von der Kommandozeile aus gestartet werden. Zur Aktivierung bei jedem Reboot wird er in der /etc/inittab eingetragen. Über Einträge in der crontab können Konfigurationswechsel zu bestimmten Zeiten implementiert werden.


Klassifikation

Kriterien

Die Zuordnung der Systemprozesse zu den WLM-Klassen kann anhand folgender Kriterien erfolgen:

Klassen

Es sind bis zu 27 eigendefinierte Klassen möglich. Daneben existieren die folgenden Klassen und Pseudoklassen (Pseudoklassen unterliegen lediglich einem memory accountig, es können keine Parameter gesetzt werden, die Kontrolle liegt bei den üblichen AIX-Mechanismen):

Regeln

Regeln werden im File /etc/wlm/NAME_DER_KONFIG/rules abgelegt. Sie werden in der angegebenen Reihenfolge abgearbeitet. Spezifischere Regeln müssen daher vor allgemeineren angegeben werden.

Beispiel (/etc/wlm/standard/rules):

* class resvd user group application
System   -    root   -    -
Default  -    -      -    -
Hier werden alle durch Root gestarteten Prozesse der Klasse System zugeordnet, alle verbleibenden der Klasse Default.

Zuordnung

Die Zuordnung der Prozesse erfolgt:
- beim Start des WLM für alle laufenden Prozesse,
- bei aktivem WLM zum Zeitpunkt des exec-Calls der Prozedur.

Dabei gilt:


Ressourcenverwaltung

Parameter

Der WLM berechnet für jede Klasse aus den Vorgaben für Share, Minimum und Maximum Limit (jeweils getrennt für CPU- und Memory-Nutzung) prozentuale Werte (bezogen auf die insgesamt vorhandenen System-Ressourcen) für angestrebten Ressourcennutzung der Klasse. Bei der Festlegung der Verteilung haben Ressourcen Limits Vorrang vor Ressourcen Shares.

Für die Berechnung der Ressourcenverteilung sind die aktiven Klassen maßgeblich. Aktiv ist eine Klasse, wenn mindestens ein Prozess, welcher der Klasse zugehört, aktiv ist. Die Verteilung wird automatisch neu berechnet, wenn Prozesse bisher inaktiver Klassen gestartet werden.

NameDefaultWerteWirkung
tier00 .. 9 0 = am wichtigsten; Auswirkung hauptsächlich auf CPU-Nutzung; Auswirkung umso stärker, je größer Differenz der tier-Werte verschiedener Klassen.
share11 .. 65535 Shares sind Anteile. Die Sollwerte werden in Prozent der vorhandenen Systemressourcen aus den insgesamt vergebenen Anteilen berechnet.
minimum limit00 .. 100 Der Zahlenwert entspricht dem Prozent-Anteil der insgesamt vorhandenen System-Ressourcen. Die Summe aller Minimum Limits innerhalb einer Tier-Gruppe (Klassen mit selbem Tier-Wert) muss kleiner 100% sein. Das Minimum Limit dient nicht der Reservierung von Ressourcen sondern nur der Priorisierung.
maximum limit1000 .. 100 Der Zahlenwert entspricht dem Prozent-Anteil der insgesamt vorhandenen System-Ressourcen. Er muss größer sein als das zugehörige Minimum Limit. Der CPU-Maximum-Wert kann überschritten werden, wenn sonst CPU-Zeit dem wait-Prozess zugeteilt würde. Der Memory-Maximum-Wert kann nicht überschritten werden und ist daher sehr vorsichtig einzusetzen.

CPU Management

Der Scheduler arbeitet Threads nach ihrer Priorität ab. 0 ist die höchste Priorität, 126 die niedrigste Priorität. Der WLM beeinflusst die Abarbeitung, indem er die Priorität der Threads beeinflusst. Die Priorität von fixed priority Prozessen wird zwischen 0 und 39 gewählt. Die höchste vom WLM vergebene Priorität ist daher 40, um diese Prozesse nicht zu stören. Die dem Prozess zugeordnete Priorität ist zunächst gleich der Summe folgender Werte:

Ermittlung des class priority adjustment
Aus den vorgegebenen Parametern für Minimum, Share und Maximum errechnet der WLM für jede Klasse einen prozentual Minimum-, Ziel- (goal) und Maximum-Wert der anzustrebenden Auslastung. Jede Sekunde wird zum Vergleich die tatsächliche class CPU usage berechnet, wobei über die letzten 5 Sekunden gemittelt wird. Außer dem wird DELTA berechnet, die Differenz aus aktueller Usage und Usage vor einer Sekunde. (Ein positives Delta bedeutet also, dass die Klasse gerade ihre CPU-Nutzung steigert.) Mit Hilfe dieser Werte werden Zonen festgelegt und dann das adjustment berechnet:
0% =blue= MIN =green= GOAL =orange= MAX =black= 100%

Zusätzlich wird das Prozess-Swapping durch den WLM so modifiziert, dass der tier Wert der Klasse berücksichtigt wird.

Memory Management

Auch für die Speichernutzung werden Minimum, Goal und Maximum berechnet. Abhängig von der Memory-Nutzung werden wieder Farbzonen definiert:
0% =blue= MIN =green= GOAL =orange= MAX =red
Achtung: mehr Memory als Maximum wird nicht vergeben! 100% = rot.

Memory pages werden mit der Farbe der Klasse ihres Prozesses identifiziert. Das Accounting erfolgt dabei segmentweise: alle pages eines Segments gehören zur selben Klasse. Wenn ein Segment von Prozessen verschiedener Klassen referenziert wird, wird es der Pseudoklasse Shared zugeordnet - und dieser immer die Farbe grün. Die Pages ausgelagerter Prozesse gelten immer als orange. Pinned memory pages werden nicht vom WLM verwaltet.

Die Farben werden "nach Temperatur" geordnet (blau ist am kältesten, rot am heißesten). Freie Pages sind nur für Prozesse zugänglich, die ihr Maximum-Limit noch nicht erreicht haben. Im anderen Fall kann der Prozess nur Pages von Prozessen stehlen, die mindestens so warm sind, wie er selbst. Prozesse einer Klasse, die ihr Maximum Limit erreicht hat, müssen so lange auf Memory warten, bis die Klasse durch Freigabe/Stehlen von Pages wieder unter ihr Limit sinkt. Dies gilt auch dann, wenn freie Pages vorhanden sind!

Innerhalb einer Tier-Gruppe darf die Summe der Minimum Limits 100% der verfügbaren Memory nicht überschreiten. Werden verschiedene Tiers definiert, ist dies aber möglich. Klassen der unwichtigeren Tier-Gruppen werden dann auf orange gesetzt.

(Für die Feinheiten der Memory Klassifikation und Alloziierung, sowie Zusammenwirken mit minfree und maxfree Werten sollten die entsprechenden Handbücher konsultiert werden!)


Kommandos und Tips

Kommandos

Wechselwirkungen

Es existieren Wechselwirkungen mit folgenden klassischen AIX-Tuning-Kommandos:

Tips

Ausblick

Für AIX5L sind folgende neue WLM-Features angekündigt:


| Home | Wissen |
Home - Impressum - Sitemap - Xtelligent-Root-CA-Zertifikat
Die Rechte an Warenzeichen und Produktnamen liegen beim jeweiligen Eigentümer.
© 1999-2005 - all rights reserved - Xtelligent IT Consulting GmbH - webmaster@xtelligent.de
IT-Dienstleistung und EDV-Support - professionell und zuverlässig - in Deutschland
Regionale Schwerpunkte Raum Kassel, Rhein/Main, Stuttgart, München
Xtelligent - Ihr leistungsstarker IT-Spezialist und EDV-Partner!
Wir helfen bei der Lösung Ihrer Anforderung!
Service und Support aus einer Hand!