Start/Wissen

WLM, Performance Index, R4HA und Capping — erklärt

Herstellerneutrale Grundlagen, kompakt aufbereitet. Genau der Teil, mit dem wir jeden Ergebnis-Workshop beginnen, damit alle Beteiligten dieselbe Sprache sprechen.

Grundbegriff

MSU, MIPS und CPU-Zeit

MSU steht für „Millions of Service Units per Hour". Es ist das Kapazitäts- und Abrechnungsmaß, maschinenunabhängig normiert und Grundlage für Sub-Capacity, Kapazitätsgrenzen und Gruppenlimits.

MIPS ist eine Vergleichs- und Sizing-Größe für Prozessorleistung — keine Abrechnungsgrundlage.

CPU-Zeit ist die eigentliche Messgröße im System und wird als Service Units erfasst. Über eine Systemkonstante wird daraus CPU-Zeit und schließlich MSU.

Merksatz: Gemessen wird CPU-Zeit, normiert wird in Service Units, abgerechnet wird in MSU.

Steuerung

Wie der Workload Manager arbeitet

Der WLM verteilt CPU-Leistung anhand einer Policy. Immer nur eine Policy ist aktiv; installiert sein dürfen beliebig viele, etwa für Tag- und Nachtbetrieb. Eine Policy besteht aus den Servicedefinitionen (Serviceklassen mit Zielen) und den Klassifizierungsregeln (welcher Workload landet wo).

  • Alle 250 ms sammelt der WLM Messwerte
  • Alle 10 Sekunden hilft er genau einer Serviceklasse
  • Er erkennt, welcher Klasse es am schlechtesten geht — und gibt genau dieser Ressourcen
  • Empfänger werden von hoher Priorität abwärts bedient, Spender von niedriger Priorität aufwärts herangezogen
Kapazitätsgrenze 00:0006:00 12:0018:00 24:00 MSU 4h Rolling Average Verbrauch je Intervall Monats-Peak
Nur die geglättete Kurve ist kostenwirksam — und von ihr nur der höchste Punkt des Abrechnungszeitraums.

Kostenmechanik

Warum es den 4-Stunden-Durchschnitt überhaupt gibt

Drei Gründe, die alle nachvollziehbar sind:

  • Glättung. Kurze Spitzen aus Batch-Starts, Sicherungsläufen oder Speicherbereinigung schlagen nicht unmittelbar auf die Rechnung durch.
  • Nachvollziehbarkeit. Bezahlt wird nachhaltige Nutzung über vier Stunden — reproduzierbar messbar aus den Betriebsdaten.
  • Steuerbarkeit. Der Durchschnitt reagiert träge und vorhersagbar und lässt sich deshalb gezielt begrenzen.

Der Wert wird je Partition geführt, im Raster von 16 Intervallen à 15 Minuten gebildet und immer abgerundet ausgewiesen. Der WLM vergleicht ihn laufend mit der Kapazitätsgrenze der Partition.

Begriffe

Capping, Defined Capacity und Capacity Groups

Soft vs. Hard Capping

Hard Capping begrenzt sofort und unabhängig vom Durchschnitt — es deckelt jede einzelne Dispatch-Entscheidung. Soft Capping greift erst, wenn der 4-Stunden-Durchschnitt die Grenze übersteigt.

Hard Capping deckelt den Moment, Soft Capping den Durchschnitt. Für Kostensteuerung ist Soft Capping das Mittel der Wahl.

Defined Capacity

Ein je Partition festgelegter MSU-Wert, den der Rolling Average nicht überschreiten darf. Er wird an der Managementkonsole gesetzt und ist im laufenden Betrieb änderbar.

Zu knapp gewählt bremst er den Workload aus; zu großzügig hat er keinen Kosteneffekt. Die Kunst liegt genau dazwischen — und die lässt sich messen.

Capacity Groups

Eine Gruppe fasst Partitionen genau einer Maschine unter einem gemeinsamen MSU-Limit zusammen. Der garantierte Anteil jeder Partition ergibt sich aus ihrem Gewichtsanteil.

Ungenutzte Anteile wandern zu den anderen Partitionen — solange die Summe unter dem Gruppenlimit bleibt, capped niemand.

Performance Index

Was der PI aussagt — und was nicht

Der Performance Index misst, wie gut eine Serviceklasse ihr Ziel erreicht. PI < 1 heißt übererfüllt, PI = 1 exakt erfüllt, PI > 1 verfehlt.

Der häufigste Fehlschluss

Ein PI von 0,5 sieht auf den ersten Blick hervorragend aus. Tatsächlich bedeutet er, dass alle Transaktionen in der Hälfte der Zielzeit fertig werden — das Ziel ist also viel zu schwach gesetzt. Die Folge: Die Klasse wird zum Ressourcen-Spender und wird bei Knappheit als Erste ausgebremst.

Ein guter PI entsteht nicht durch ein leichtes Ziel, sondern durch ein Ziel, das der realen Arbeit entspricht. Erst dann steuert der WLM sinnvoll.

Der umgekehrte Fall

Eine Klasse mit hoher Priorität, deren Ziel nie annähernd erreicht wird, ist ebenso ein Befund: Der WLM steckt fortlaufend CPU-Zyklen in ein Ziel, das nicht erreichbar ist — zu Lasten anderer Klassen, die davon tatsächlich profitiert hätten.

Bei transaktionalen Zielen ist der höchste ausgewiesene PI rechnerisch 4. Wer diesen Wert dauerhaft sieht, sollte das Ziel prüfen, nicht die Hardware.

Unterschätzt

Report Classes — geringer Aufwand, hoher Erkenntnisgewinn

Report Classes machen Verbrauch sichtbar, ohne die Steuerung zu beeinflussen: keine Auswirkung auf die Priorisierung, keine eigenen Ziele, praktisch kein Overhead.

Damit werden Fragen beantwortbar, die sonst Schätzung bleiben: Wie viel verbraucht ein einzelner Transaktionsmonitor? Wie oft läuft eine Transaktion und was kostet sie? Wie viel verbraucht der Applikationsbatch im Monat?

Nutzen Sie diese Möglichkeit, wo immer es geht.

Prioritätsstufen richtig lesen

Die Prioritätsstufe einer Serviceklasse bedeutet zeitkritisch oder nicht zeitkritisch — nicht wichtig oder unwichtig. Eine unternehmenskritische Auswertung kann durchaus in einer niedrigen Stufe laufen, wenn sie keine kurze Antwortzeit braucht.

Ebenso häufig missverstanden: Der WLM steuert nur, wenn es tatsächlich eng wird. Ohne echte Ressourcenknappheit gibt es nichts zu verteilen — dann findet auch keine aktive Steuerung statt.

Diesen Teil gibt es auch als Workshop.

Wir bringen Grundlagen und Ihre eigenen Daten zusammen — so wird aus Theorie eine Entscheidungsgrundlage.