Die Größen der beiden Pools sind nicht fix, sie hängen von der Speicherauslastung und dem Zugriffsmuster auf die Speicherseiten ab. Im Bild 6.6 ist also nur ein Moment festgehalten, im nächsten Moment können die Verhältnisse schon geringfügig anders aussehen. Der Zugriff von Prozessen auf komprimierte Speicherseiten ist nicht direkt möglich und auch nicht sinnvoll, da die Daten nicht mehr so vorliegen, wie der Prozeß sie abgespeichert hat. Greift ein Prozeß auf Daten zu, die durch Komprimierung im Compressed Pool liegen, muß das Betriebssystem diese zunächst entkomprimieren und im Uncompressed Pool ablegen. Komprimierte Speicherseiten können nicht auf einen Paging-Space ausgelagert werden.
AME kann für jede LPAR individuell aktiviert oder deaktiviert werden, allerdings nicht dynamisch. Soll für eine LPAR AME verwendet werden, muß der sogenannte AME-Faktor angegeben werden. Dieser gibt an um welchen Faktor der tatsächliche Speicher erweitert werden soll. Die dazu notwendige Komprimierungsrate ist größer, da ja der Uncompressed Pool unkomprimiert bleibt. Im Bild oben war die Komprimierungsrate z.B. 1.75 und der erzielte AME-Faktor 1.5. Ein Teil des Speichers muß immer unkomprimiert bleiben, da sonst das Betriebssystem nicht mehr arbeiten kann.
Wie gut AME in der Praxis dann tatsächlich funktioniert, hängt sehr stark von mehreren Faktoren ab:
- Wie gut lassen sich die Daten komprimieren, d.h. welche Komprimierungsrate kann tatsächlich erreicht werden?
- Nach welcher Zeit erfolgt ein Zugriff auf Daten die komprimiert wurden.
- Passt das Working-Set an Speicherseiten in den Uncompressed Pool, der sich ergibt, nachdem weniger häufig benutzte Daten komprimiert wurden.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.