| Home | Wissen |
| Bearbeitung | Karin Wenzel, Xtelligent |
| 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. |
Wir wünschen eine interessante Lektüre!
Das Team von Xtelligent
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.
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.
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.
Die Zuordnung der Systemprozesse zu den WLM-Klassen kann anhand folgender Kriterien erfolgen:
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 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.
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:
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.
| Name | Default | Werte | Wirkung |
| tier | 0 | 0 .. 9 | 0 = am wichtigsten; Auswirkung hauptsächlich auf CPU-Nutzung; Auswirkung umso stärker, je größer Differenz der tier-Werte verschiedener Klassen. |
| share | 1 | 1 .. 65535 | Shares sind Anteile. Die Sollwerte werden in Prozent der vorhandenen Systemressourcen aus den insgesamt vergebenen Anteilen berechnet. |
| minimum limit | 0 | 0 .. 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 limit | 100 | 0 .. 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. |
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.
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!)
Für AIX5L sind folgende neue WLM-Features angekündigt: