Wird eine LPAR heruntergefahren, werden nicht automatisch die Resourcen, wie Prozessoren, Speicher und I/O-Slots, der LPAR freigegeben. Die Resourcen bleiben weiterhin der LPAR zugeordnet und werden dann beim nächsten Aktivieren (mit der aktuellen Konfiguration) wiederverwendet. Im ersten Teil des Beitrags Resourcen von nicht aktivierten LPARs hatten wir uns dies schon angeschaut.
(Hinweis: In den Beispiel-Ausgaben benutzen wir die Version 1.4 des LPAR-Tools, zeigen aber in allen Fällen die unterliegenden Kommandos auf der HMC Kommandozeile. Man kann also alles auch ohne die Verwendung des LPAR-Tools ausprobieren.)
Die Beispiel LPAR lpar1 wurde heruntergefahren, belegt aber aktuell immer noch 100 GB Speicher:
linux $ lpar status lpar1 NAME LPAR_ID LPAR_ENV STATE PROFILE SYNC RMC PROCS PROC_UNITS MEM OS_VERSION lpar1 39 aixlinux Not Activated standard 0 inactive 1 0.2 102400 Unknown linux $
Auf der zugehörigen HMC hmc01 wurden die folgenden Kommandos für die Ausgabe oben ausgeführt:
hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1 hmc01: lshwres -r mem -m ms09 --level lpar --filter lpar_names=lpar1 hmc01: lshwres -r proc -m ms09 --level lpar --filter lpar_names=lpar1
Wie die Ausgabe zeigt, hat die LPAR lpar1 noch ihre Resourcen (Prozessoren, Memory, I/O-Adapter) alloziert.
Um zu verstehen warum beim Deaktivieren einer LPAR die Resourcen nicht frei gegeben werden, muss man sich den „Memory Affinity Score“ anschauen:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 100 0 linux $
HMC Kommandozeile:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
Der Memory Affinity Score beschreibt wie nahe sich Prozessoren und Memory sind, je näher, desto besser ist der Durchsatz auf den Speicher. Das Kommando oben gibt mit einem Wert zwischen 1 und 100 an, wie groß die Affinität zwischen Prozessoren und LPARs ist. Unsere LPAR lpar1 hat aktuell einen Wert von 100, das heißt die bestmögliche Affinität von Speicher und Prozessoren. Würden beim Deaktivieren einer LPAR die Resourcen freigegeben, dann würde die LPAR erst einmal diesen Memory Affinity Score verlieren. Beim nächsten Aktivieren der LPAR hängt es dann von dem dann verfügbaren Speicher und Prozessoren ab wie gut die Memory Affinität dann ist. Wir geben einmal die Resourcen frei:
linux $ lpar -d rmprocs lpar1 1 linux $
HMC Kommandozeile:
hmc01: chhwres -m ms09 -r proc -o r -p lpar1 --procs 1
Es wird nun kein Score mehr angegeben, da der LPAR keine Resourcen mehr zugeordnet sind:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 none none linux $
HMC Kommandozeile:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
Nun lassen wir die Resourcen neu zuweisen und Schauen welchen Einfluß dies auf die Memory Affinität hat:
linux $ lpar applyprof lpar1 standard linux $
HMC Kommandozeile:
hmc01: chsyscfg -r lpar -m ms09 -o apply -p lpar1 -n standard
Wir ermitteln erneut den Memory Affinity Score:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 53 0 linux $
HMC Kommandozeile:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
Der Score ist jetzt nur noch bei 53, die Performance der LPAR ist damit schlechter geworden. Ob und wie stark sich dies dann auch bemerkbar macht, hängt dann letztlich von den Applikationen auf der LPAR ab.
Das die Resourcen beim Deaktivieren einer LPAR nicht freigegeben werden, garantiert also beim nächsten Aktivieren (mit der aktuellen Konfiguration) das die Memory Affinität gleich bleibt und damit die Performance die Gleiche sein sollte.
Gibt man die Resourcen einer LPAR frei (manuell oder automatisch), dann muß man sich im Klaren sein das dies Auswirkungen auf die LPAR hat, wenn sie später wieder aktiviert wird, da dann die Resourcen neu zugewiesen werden und sich ein schlechterer (möglicherweise aber auch ein besserer) Memory Affinity Score ergeben kann.
Umgekehrt kann man vor dem Aktivieren einer neuen LPAR aber auch durch Freigeben von Resourcen dafür sorgen das es eine gute Chance für einen hohen Memory Affinity Score für die neue LPAR gibt.
(Hinweis: die Resource Verteilung kann zur Laufzeit mit Hilfe des Dynamic Plattform Optimizers DPO geändert und verbessert werden. DPO wird ab POWER8 unterstützt.)