Saponlinux

F -X C h a n ge F -X C h a n ge
PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
c u -tr a c k c u -tr a c k

3
SAP Memory Management f¨r Linux
u

Aus der Sicht des Betriebssystems besteht das SAP-System aus einer Menge
von Prozessen wie jede andere Anwendung auch. Ein SAP-Workprozess un-
terliegt der gleichen Behandlung hinsichtlich der Zuteilung von Betriebssys-

x
tem-Ressourcen, wie CPU oder Hauptspeicher, wie eine Shell, ein Bildverar-
beitungsprogramm oder eine Datenbank. In diesem Kapitel betrachten wir
deshalb zun¨chst die allgemeinen, f¨r alle Prozesse g¨ltigen Konzepte der
a u u
Le
Speicherverwaltung von Linux. Anschließend beschreiben wir in einem zwei-
ten Teil die Struktur der Speicherverwaltung des SAP-Systems. Hier konzen-
trieren wir uns zun¨chst auf den ABAP-Applikationsserver, der durch große
a
pp

Speicheranforderungen gekennzeichnet ist. Um die Hintergr¨nde dieser An-
u
forderungen zu beleuchten, skizzieren wir in einem ersten Schritt die logische
Sicht auf die Speicherverwaltung. Auf der Linux-Plattform finden sich dann
zwei Ans¨tze f¨r die konkrete Implementierung der logischen Anforderun-
a u
gen: Das Standard-Verfahren, das bei allen Unix-Systemen eingesetzt werden
sU

kann, und ein Linux-spezifisches neues Memory Management. Beide werden
im Detail beschrieben. Den Abschluss des zweiten Teils bildet ein Exkurs auf
die Speicherverwaltung im Java-Applikationsserver. Der dritte Teil behandelt
dann Werkzeuge zur Diagnose und Beobachtung der Speicherverwaltung und
hüfig gestellte Fragen zu diesem Themenkomplex.
a
Ein Wort zur Terminologie: Wenn wir im Folgenden vom Hauptspeicher
reden, ist der physisch in der Maschine vorhandene Speicher gemeint. Wir
unterscheiden in der folgenden Diskussion nicht zwischen dem physischen
Hauptspeicher (den SIMMs, DIMMs, etc.), dem Auslagerungs- oder Swap-
bereich und gegebenenfalls vorhandenen Caches (L1, L2, L3). Die Unterschei-
dung zwischen diesem physisch vorhandenen Speicher und den Adressen, die
der Prozess sieht, ist aber zentral und muss stringent durchgehalten werden,
um die Ablüfe auf einem Linux-System zu verstehen. Der Speicher, den eine
a
¨
Anwendung sieht, wird in Ubereinstimmung mit der g¨ngigen Literatur [22]
a
durchg¨ngig als virtueller Speicher bezeichnet. Die Konzepte, die sich hin-
a
ter dieser letzten Bezeichnung verbergen, werden im n¨chsten Abschnitt kurz
a
vorgestellt.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
114 3 SAP Memory Management f¨r Linux
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
3.1 Speicherverwaltung unter Linux

Moderne Betriebssysteme m¨ ssen die Speicheranforderungen ihrer Anwen-
u
dungen auf flexible und effiziente Art erf¨llen. Dabei k¨nnen die Anforde-
u o
rungen der Anwendungen h¨chst unterschiedlich sein: Einige ben¨tigen kaum
o o
Speicher, w¨hrend andere, wie z.B. SAP, zum Teil erhebliche Mengen an Daten
a
im Speicher halten wollen. Die Zuteilung des Speichers durch das Betriebs-
system wird zudem durch weitere Aspekte erschwert:
1. Das Anforderungsmuster einer Anwendung kann sich im Laufe ihrer
Lebensdauer gravierend andern. W¨hrend der Startphase einer neuen
¨ a
Anwendung wird der ausf¨hrende Prozess ublicherweise viel Speicher an-
u ¨
fordern. Ein CPU-intensiver Prozess, wie z.B. Seti@Home, wird dann aller-
dings kaum noch zus¨tzlichen Speicher ben¨tigen. Ein Bildverarbeitungs-
a o
programm, das auf User-Anfrage ein neues Bild in den Speicher l¨dt, wird
a
demgegen¨ber auch zur Laufzeit noch weiteren Speicher ben¨tigen.
u o
2. Es ist m¨glich, dass die Summe der Anforderungen der zu einem gegebenen
o
Zeitpunkt laufenden Anwendungen die Menge des physikalisch vorhande-
¨
x
nen Hauptspeichers ubertreffen.
3. Selbst einzelne Prozesse fordern mitunter mehr Speicher an, als an Haupt-
Le
speicher in der Maschine vorhanden ist.
4. Ein wichtiger Aspekt f¨r die Stabilit¨t des gesamten Systems ist, dass die
u a
Prozesse nicht oder nur kontrolliert auf Speicherbereiche anderer Prozesse
oder gar des Betriebssystems zugreifen k¨nnen.
o
pp

3.1.1 Der virtuelle Adressraum

All diese Probleme werden in heutigen Betriebssystemen wie Linux oder Win-
sU

dows durch die Einf¨hrung des Konzeptes des virtuellen Speichers oder
u
virtuellen (logischen) Adressraums aufgegriffen. Dieser virtuelle Adres-
sraum abstrahiert von der physikalischen Speicherausstattung der Maschine.
Jeder Prozess auf einem solchen Betriebssystem erh¨lt beim Start einen ei-
a
genen logischen Adressraum, der unabh¨ngig von den strukturell identischen
a
Adressrümen anderer Prozesse und von der Ausstattung der Maschine mit
a
physikalischen Hauptspeicher ist. Alle Adressen, die von Compilern oder an-
deren Werkzeugen wie Linkern erzeugt werden, sind als Angaben von Orten
in diesem virtuellen Adressraum zu verstehen. Diese virtuellen Adressen sind
die einzigen, die einem Prozess bekannt und zug¨nglich sind. Das Betriebs-
a
system, das die Illusion des virtuellen Adressraums aufbaut, ist dann auch
daf¨r zust¨ndig, dass Zugriffe auf Stellen im virtuellen Adressraum auf die
u a
zugeh¨rigen Stellen im physikalischen Speicher umgesetzt werden.
o
In Abb. 3.1 ist die grunds¨tzliche Gestalt eines typischen virtuellen Adres-
a
sraums unter Linux zu sehen. Als Vorlage dient dazu die 32-Bit Intel-Plattform
unter einem Linux 2.4 System. Die Details der Abbildung werden im folgenden
Abschnitt erkl¨rt.
a

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
3.1 Speicherverwaltung unter Linux 115
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c

x
Abb. 3.1. Virtueller Adressraum unter Linux
Le
Das Layout des virtuellen Adressraums

Wir untersuchen, schon mit Blick auf die unten anstehende Diskussion der
SAP-Speicherverwaltung, einige Aspekte der Gestalt des virtuellen Adres-
pp

sraums genauer. Wir beginnen mit einigen allgemeinen Aussagen, betrachten
dann typische Probleme des vorgestellten Layouts und zeigen schließlich kurz
auf, welche Entwicklungen im Linux 2.6 Kernel stattgefunden haben.
sU

Allgemeine Aspekte

Den virtuellen Adressraum aus Abb. 3.1 zeichnen zun¨chst einige allgemeine
a
Aspekte aus:
• Die Adressen innerhalb des Adressraums steigen linear an. Linux verwen-
det also keine Segmentierung des Adressraums, s. [23].
• Die maximale Gr¨ße des virtuellen Adressraums ist durch den Aufbau
o
der CPU begrenzt. Bei einer 32-Bit-Plattform stehen nur 32 Bit f¨r die
u
Adressierung zur Verf¨gung. Der virtuelle Adressraum kann damit maxi-
u
mal 232 Byte (4 GB) groß werden. Auf einer 64-Bit-Plattform wird diese
Grenze auf 264 Byte (16 ExaByte) erweitert. Der verf¨gbare Adressraum
u
eines Prozesses steigt damit signiﬁkant an.
• Um den virtuellen Adressraum einfach verwalten zu k¨nnen, wird er in
o
voneinander unabh¨ngige Bl¨cke fester Gr¨ße (Pages) aufgeteilt. Die
a o o
Gr¨ße dieser Pages ist dabei ebenfalls von der unterliegenden Hardware
o
abh¨ngig. Auf der 32-Bit-Intel-Plattform ist sie 4 KiloByte, auf dem Ita-
a
nium liegt sie typischerweise bei 16 KByte und auf AMD64 bei 4 bis

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
8 KByte. Auf diesen Aspekt kommen wir bei der Diskussion des eigentli-
chen Nutzens des virtuellen Adressraums erneut zur¨ck, s. Abschnitt 3.1.2.
u
Die Einteilung in Pages ist ein wesentlicher Teil der Speicherverwaltung
heutiger Betriebssyteme.
• Linux unterteilt den Adressraum in einen Bereich, der dem Prozess selbst
zug¨nglich ist, und einen, der nur dem Betriebssystem vorbehalten ist. In
a
der ublichen Terminologie wird der erste als User Space und der zweite als
¨
Kernel Space bezeichnet. Die Lage dieser Grenze bestimmt die maximale
Gr¨ße des Adressraums, der einem Prozess zug¨nglich ist. Sie wird deshalb
o a
als TASK-SIZE bezeichnet [29]. Bei einem 32-Bit-Intel-System liegt diese
Grenze bei 3 GB, bei einem Intel Itanium-System bei 5 ∗ 261 Byte [30] und
bei einem AMD64-System derzeit bei 512 GB.
• Innerhalb des User-Spaces existieren Bereiche, die mit jeweils einer eigenen
Semantik ausgestattet sind. In der Linux-Nomenklatur werden diese Berei-
che als virtual memory areas (VMA) bezeichnet. Zu diesen Bereichen
geh¨ren der Programm-Code des Prozesses (auch Text-Region genannt),
o
die Daten des Programms (sowohl initialisierte als auch nicht-initialisierte,
Data-Region), der Stack des Programms (Stack-Region) und der Be-
x
reich, aus dem die dynamischen Speicheranforderungen, wie malloc(),
befriedigt werden. Dieser letzte Bereich wird als Heap bezeichnet.
Le
M¨gliche Problemfelder
o
Die Erfahrung lehrt, dass im vorgestellten Layout gerade f¨r speicherintensive
u
pp

Anwendungen wie SAP auf 32-Bit Plattformen einige Probleme schlummern.
¨
Sie lassen sich alle unter dem Uberbegriff der Verknappung des virtuellen
Adressraums zusammenfassen.
Zun¨chst werden unter Linux 2.4 die vom Prozess verwendeten Bibliothe-
a
ken (hier die sogenannten Shared Libraries) ab einer vordefinierten Stelle
sU

in den Adressraum geladen. Auf der 32 Bit-Intel-Plattform ist dieser Beginn
der Einlagerung durch die Systemsoftware auf 1 GB (hexadezimale Adresse
0x40000000) definiert. Erst nach diesen Bibliotheken werden normalerweise
die Bereiche allokiert, in denen das SAP-System seine gemeinsamen Speicher-
bereiche, wie Buffer, User Memory, etc., ablegt. Diese Bereiche (in Abb. 3.1
als MMAP/Shared Memory bezeichnet) k¨nnen sich also von etwas mehr
o
als 1 GB bis zum Stack-Bereich erstrecken. Der Stack-Bereich besitzt eine va-
riable Gr¨ße und w¨chst in Richtung kleinerer Adressen, d.h. nach unten.
o a
Auf dem Stack werden beispielsweise lokale Variablen eines C-Programms,
oder beim Absteigen in Unterprogramme die Funktionsargumente sowie die
R¨cksprungadresse abgelegt. Da die Gr¨ße des Stack-Bereiches normaler-
u o
weise vergleichsweise klein ist, liegt die maximale Gr¨ße der Shared Memory-
o
Bereiche also bei knapp unter 2 GB.
Der in Abb. 3.1 ebenfalls eingezeichnete Heap-Bereich kann große Teile
des restlichen zur Verf¨gung stehenden Platzes einnehmen. Er ist dabei nicht
u
auf den Bereich oberhalb der Shared Libraries beschr¨nkt. Damit steht f¨r
a u
die Allokierung von Speicher im Heap noch weiterer Platz zur Verf¨gung;u

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
es kann hier zus¨tzlich von mehreren hundert MB ausgegangen werden. In
a
Summe stehen damit einem Prozess auf einer 32-Bit-Intel-Plattform, je nach
Konfiguration, ca. 2,8 GB an virtuellem Adressraum zur Verf¨gung.
u
Ein letztes Problem erw¨chst aus der unterschiedlichen Wachstumsrich-
a
tung von MMAP bzw. Heap auf der einen und dem Stack auf der anderen
Seite. Sowohl der MMAP/Shared Memory-Bereich als auch der Heap wachsen
in Richtung gr¨ßere virtueller Adressen. Der Stack kommt diesen beiden Berei-
o
chen von oben entgegen. Es ist damit grunds¨tzlich klar, dass es zu Kollisionen
a
zwischen Stack und MMAP bzw. Heap kommen kann. Auf 32-Bit-Maschinen
tritt dieses Problem in der Tat auf und f¨hrt zum Abbruch des betroffenen
u
Prozesses. Sowohl die Anwendungen als auch das Betriebssystem verwenden
deshalb mitunter Guard Pages, die die Grenze zwischen Stack und Heap
sch¨tzen.
u

¨
Anderungen im Linux Kernel 2.6

Im 2.6er Linux-Kernel wird ein Teil dieser Probleme angegangen, s. [33].
In Abb. 3.2 ist die neue Gestalt des virtuellen Adressraums skizziert. Der
a
x
auff¨lligste Unterschied ist sicher der Wegfall des festen Bereiches f¨ r die Sha-
u
red Libraries. Diese werden stattdessen direkt unterhalb des Stack-Segments
Le
eingeblendet und wachsen nach unten. Der Stack wird in diesem Szenario auf
eine maximale Gr¨ße bei Prozess-Start festgesetzt. Der Heap-Bereich auf der
o
anderen Seite w¨chst in den gleichen freien Raum in der Mitte des virtuellen
a
Adressraums hinein. Der vorhandene Adressraum ist damit nicht mehr durch
pp

den Shared-Library-Bereich fragmentiert und kann besser ausgenutzt werden.
sU

Abb. 3.2. Virtueller Adressraum unter Linux 2.6

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
c u -tr a c k ¨
Eine weitere, eher kleine Anderung betrifft die oberste Page des Kernel- c u -tr a c k

¨
Bereichs. Hier liegt nun eine Page, die f¨r den Prozess zugreifbar ist. Uber
u
diese Page k¨nnen User-Space-Prozesse einen schnelleren Zugriff auf Kernel-
o
Daten erhalten. Diese Page, die sogenannte vsyscall page [35], wird z.Zt. ge-
nutzt, um einige System-Aufrufe zu beschleunigen. Zu diesen Systemaufrufen
z¨hlt vor allem gettimeofday(), mit dem Anwendungen eine Zeitmessung
a
realisieren. Dieser Aufruf wird im SAP-System hüfig verwendet, u.a. zur
a
Performance-Messung.

3.1.2 Einsatz des virtuellen Adressraums

Wir kommen wieder zur¨ck zum Nutzen und zur Verwendung des Konzep-
u
tes eines virtuellen Adressraums. Dazu schauen wir uns die Funktionsweise
eines Systems mit virtuellem Speicher zun¨chst genauer an. Bei der Erzeu-
a
gung eines ausf¨hrbaren Programms werden alle Verweise auf Adressen, z.B.
u
Zugriffe auf Variablen, als virtuelle Adressen kodiert. Die CPU sieht bei der
u
x
Ausf¨hrung eines Prozesses nur diese Adressen. F¨ r den faktischen Zugriff
u
auf den physischen Speicher m¨ ssen diese virtuellen Adressen noch auf die
u
physischen Adressen abgebildet werden. Diese Aufgabe ubernimmt in vielen
¨
Le
Hardware-Architekturen eine spezielle Komponente, die Memory Manage-
ment Unit (MMU). Die MMU erh¨lt als Eingabe eine virtuelle Adresse und
a
erzeugt daraus die Adresse, an der das gew¨ nschte Datum faktisch liegt. F¨r
u u
pp

diese Aufgabe ben¨tigt die MMU typischerweise einige Datenstrukturen, die
o
von der Hardware bereitgestellt und vom Betriebssystem verwaltet werden.
Zu diesen Datenstrukturen z¨hlen die sogenannten Pagetabellen und deren
a
Cache, der Translation Lookaside Buffer (TLB).
Wichtig bei diesem Ablauf ist nun zum einen, dass die Pagetabellen
sU

prozess-spezifisch sind, und zum anderen, dass die Umrechnung f¨r jedenu
Zugriff auf eine virtuelle Adresse neu geschehen muss. W¨hrend dies sicher
a
ein Performance-Problem darstellen kann, bietet es auf der anderen Seite die
Chance, f¨r jede Page einen eigenen physischen Ort zu erlauben. Dabei muss
u
dieser Ort nicht unbedingt im physischen Speicher liegen. Es ist z.B. denkbar,
dass bei der Ausf¨hrung eines Programms eine Page, die den Code enth¨lt,
u a
schon im physischen Speicher liegt, w¨hrend eine Page mit Programm-Daten
a
noch nicht gelesen wurde und sich noch auf der Platte befindet. Analog k¨nnen
o
gerade nicht ben¨tigte Pages in einen Paging-Bereich auf der Platte ausgela-
o
gert werden. Bei Linux wird dieser Paging-Bereich aus historischen Gr¨nden
u
normalerweise Swap-Space genannt. Ganz korrekt ist diese Terminologie al-
lerdings nicht, da Swapping urspr¨nglich das Auslagern ganzer Prozesse be-
u
schrieb. Linux dagegen ist ein Paging-System, da es Pages zwischen dem
Hauptspeicher und dem Auslagerungsbereich verschiebt.
Die Verwendung des in Pages unterteilten virtuellen Adressraum erlaubt
eine recht einfache L¨sung f¨r die oben beschriebenen Grundprobleme einer
o u
Speicherverwaltung (s. S. 114).

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
1. Anforderungen nach weiterem Speicher zur Laufzeit werden im beschrie-
benen Szenario einfach realisiert. Neue Pages werden dem virtuellen
Adressraum hinzugef¨gt und die zugeh¨rigen Daten gegebenenfalls aus
u o
einer Datei o.¨. geladen. Dabei werden Zugriffe auf noch nicht im phy-
a
sikalischen Speicher befindliche Bereiche der Datei zu sogenannten Page
Faults f¨hren, welche das Betriebssystem veranlassen, die gew¨ nschten
u u
Daten in den physikalischen Speicher einzulagern. Weitere Zugriffe auf
diesen Bereich werden dann uber die MMU direkt abgebildet.
¨
2. Da Pages sich nicht permanent im physikalischen Speicher befinden m¨s- u
sen, k¨nnen ganze Prozesse oder auch nur Teile von ihnen in Paging-
o
Bereiche ausgelagert werden. Die Summe der Speicheranforderungen meh-
rerer Prozesse kann damit gr¨ßer sein als der physikalisch vorhandene
o
Hauptspeicher.
3. Die analoge Aussage gilt aus dem gleichen Grund auch f¨r die Behand-
u
lung von Prozessen, deren belegter virtueller Adressraum gr¨ßer ist als der
o
physikalisch vorhandene Hauptspeicher.
4. Da die virtuellen Adressrüme unterschiedlicher Prozesse per se eigen-
a
st¨ndige Einheiten sind, kann bei korrekter Funktionsweise der Abbildung
a
x
von virtuellen zu physikalischen Adressen kein Prozess ohne weiteren Auf-
wand auf die Daten eines anderen Prozesses zugreifen. Auch ist der Zu-
Le
griff auf Betriebssystem-Strukturen durch die Zweiteilung des virtuellen
Adressraums in Kernel- und Userspace verwehrt.
So elegant dieses Vorgehen auch ist, bringt es doch neue Probleme mit sich.
pp

F¨r das SAP-System mit seinen hohen Speicheranforderungen und den damit
u
einhergehenden hüfigen Adressumsetzungen ist zun¨chst die hohe Last auf
a a
den Pagetabellen relevant. Daneben findet sich im SAP-System noch eine sehr
geringe Sequentialit¨t der Speicherzugriffe. Die Anfragen der SAP-Anwender
a
folgen keinem vorhersehbaren Muster. Damit geraten die Caches der Page-
sU

tabellen, die TLBs, ebenfalls unter hohe Last. Die Trefferrate der TLBs ist
bei SAP-Systemen hüfig geringer als bei anderen Anwendungen. Schließlich
a
k¨nnen die hohen Speicheranforderungen des SAP-Systems auch dazu f¨hren,
o u
dass aktuell nicht ben¨tigte Pages aus dem physikalischen Speicher ausgela-
o
gert werden und durch andere Pages ersetzt werden m¨ ssen. Die Qualit¨t der
u a
hier verwendeten Ersetzungsalgorithmen kann immense Auswirkungen auf die
gesamte Performance des Systems haben. Nicht geeignete Algorithmen k¨nneno
im SAP-Umfeld zu Performance-Verlusten bis zum Faktor 10 f¨hren. Die neue-
u
ren Linux-Kernel sind in dieser Beziehung aber mittlerweile von durchgehend
guter Qualit¨t. Dies ist einer der wichtigsten Aspekte, die durch die Tests von
a
Linux-Kerneln im SAP LinuxLab sichergestellt werden.

3.1.3 Shared Memory
Die Separation von unterschiedlichen Prozessen und ihren Adressrümen, die
a
der obige Ansatz des virtuellen Adressraums automatisch liefert, sind einer-
seits f¨r die Stabilit¨t eines Systems wie SAP mit vielen zusammenwirken-
u a

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
den Prozessen und Threads sehr wichtig. Auf der anderen Seite ist die Kom-
munikation zwischen verschiedenen Prozessen in einem SAP-System ebenso
zentral. Die Separation der Adressrüme bietet grunds¨tzlich zun¨chst keine
a a a
M¨glichkeit, auf die Variablen anderer Prozesse zuzugreifen.
o
Um nun eine effektive Inter-Prozess-Kommunikation zu realisieren, m¨ssen
u
spezielle Maßnahmen bei der Implementierung der Anwendung ergriffen wer-
den. Zwei Verfahren sind in diesem Zusammenhang hüfig zu finden:
a
• Die Verwendung von Threads basiert auf der Tatsache, dass die Threads
eines Prozesses, im Gegensatz zu den Prozessen selbst, den selben virtuel-
len Adressraum verwenden. Damit ist eine außerst einfache und schnelle
¨
Kommunikation zwischen verschiedenen Threads m¨glich. Durch die Auf-
o
gabe der Separation verliert eine Multi-Threaded-Anwendung jedoch viel
der oben besprochenen Stabilit¨t (s. Kap. 2.1.3). Im SAP-Umfeld wurde
a
deshalb f¨r den eigentlichen SAP Application Server eine prozessbasierte
u
Architektur verwendet.
• Bei der Verwendung von Prozessen muss daher eine M¨glichkeit gefunden
o
werden, Daten uber den eigenen Adressraum hinaus auch anderen Pro-
¨
a
x
zessen zug¨nglich zu machen. Dieser gemeinsam nutzbare Speicher wird
allgemein als Shared Memory bezeichnet.
Le
In Unix-basierten Systemen gibt es traditionell drei Verfahren, um solches
Shared Memory bereitzustellen, s. [20]:
1. Anwendungen des Memory Mappings (MMAP). Unter Memory Map-
pp

ping wird das Einblenden von Teilen von Dateien des Dateisystems
in den virtuellen Adressraum eines Prozesses verstanden. Die Zugriffe
auf die Daten der Datei m¨ssen dann nicht mehr uber die normalen
u ¨
read()- oder write()-Aufrufe geschehen, sondern k¨nnen analog zu nor-
o
malen Variablen-Zugriffen ablaufen. Dieses Verfahren stellt eine viel ge-
sU

nutzte Methode im Bereich der Betriebssystem-nahen Programmierung
dar. Auch im SAP-Umfeld w¨re es ein naheliegender Ansatz zur Reali-
a
sierung von gemeinsam genutztem Speicher der Workprozesse gewesen.
Leider fehlte bis zum Linux-Kernel 2.4 die Unterst¨tzung der besonderen
u
und im SAP-Umfeld notwendigen Spezialform des Anonymous Shared
Maps. Ohne diese Form war die Performance f¨r SAP-Bed¨rfnisse un-
u u
gen¨gend.
u
2. Das SysV Shared Memory. Es geht von der speziellen Struktur eines
sogenannten SHM-Segments aus. Diese SHM-Segmente m¨ssen einmal
u
angelegt und dann in die virtuellen Adressrüme der Prozesse explizit ein-
a
geblendet werden. Die SHM-Segmente sind allerdings nur als Ganzes zu
bearbeiten; es ist zum Beispiel nicht m¨glich, nur einen Teil eines Seg-
o
ments ein- oder auszublenden. Zudem ist die maximale Anzahl solcher
Segmente durch den Parameter SHMMNI des Betriebssystems begrenzt. Die
existierenden SHM-Segmente k¨nnen durch das Werkzeug ipcs angezeigt
o
werden. Das SAP-System verwendet das SysV Shared Memory, um seine
Puffer, wie die Nametab, die Tabellenpuffer und den PXA-Puffer, zu im-

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
3.2 SAP-Speicherverwaltung f¨ r die Linux Plattform
u 121
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
plementieren. Bei den Unixversionen und in der alteren Implementierung
¨
der Speicherverwaltung von SAP auf Linux wird es standardm¨ßig auch
a
f¨r das User-Memory verwendet.
u
3. Das POSIX Shared Memory. Es steht auf der Linux-Plattform erst
mit Kernel 2.4 zur Verf¨gung und wurde von Hans-Christoph Roh-
u
land entwickelt. Das POSIX-SHM stellt gemeinsame Speicherbereiche zur
Verf¨gung, die analog zu normalen Dateien in den Adressraum einge-
u
blendet werden k¨nnen. Diese Speicherbereiche werden unter Linux im
o
eigens daf¨r entwickelten tmpfs als Dateien allokiert. Mehrere Prozesse
u
k¨nnen so die gleiche Datei einblenden und sie als schnellen, gemeinsa-
o
men Speicher verwenden [32]. Eine Variante, um geteilten Speicher im
¨
tmpfs zu erstellen, w¨re beispielsweise das Offnen und Einblenden einer
a
normalen Datei im tmpfs mittels open() und mmap( . . . , MAP SHARED,
. . . ). Technisch ¨quivalent, aber dem POSIX Standard [36] folgend, ist
a
allerdings die Abfolge shm open() und mmap( . . . ).
Diese Form von Shared Memory wird in der SAP-Speicherverwaltung f¨r u
User-Memory derzeit standardm¨ßig ab Linux-Kernel 2.4 und h¨her ein-
a o
gesetzt.
u x
Mit diesen letzten Ausf¨ hrungen sind die Voraussetzungen gegeben, um
in den Abschnitten 3.2.2 und 3.2.3 die beiden derzeit m¨glichen Implemen-
o
Le
tierungen der SAP-Speicherverwaltung verstehen zu k¨nnen. Zuvor jedoch
o
geben wir eine Einf¨hrung in die Probleme der Speicherverwaltung aus Sicht
u
des SAP ABAP-Applikationsserver und stellen die Anforderungen des SAP-
pp

Systems an die Speicherverwaltung des Betriebssystems dar, wie sie sich aus
logischer Sicht, d.h. der Sicht der Anwender, ergeben.
sU

3.2 SAP-Speicherverwaltung f¨r die Linux Plattform
u

Der SAP ABAP-Applikationsserver geh¨rt sicherlich zu der Sorte von Anwen-
o
dungen, die pro Prozess einen sehr hohen Speicherbedarf besitzen, s. S. 114.
Die Quellen dieses Speicherbedarfs liegen zum einen in den Datenmengen,
die jeder SAP-Anwender f¨r seine Arbeit ben¨tigt und die heute f¨r einen
u o u
gegebenen Zeitpunkt oftmals im GigaByte-Bereich liegen. Eine andere Quelle
sind die steigenden Anforderungen der neuen SAP-Versionen selbst. Hier ist
insbesondere die Unicode-F¨higkeit zu nennen, s. Abschnitt 4.3.3.
a
Auf 64-Bit-Systemen steht dem SAP Applikationsserver hinreichend virtu-
eller Adressraum zu Verf¨gung, so dass auf solchen Systemen der Fokus auf der
u
effizienten Nutzung des physikalischen Speichers liegt. Bei 32-Bit Systemen,
die unter Linux noch hüfig zum Einsatz kommen, liegt die Problematik je-
a
doch an anderer Stelle: Die Gr¨ße des verf¨gbaren virtuellen Adressraums
o u
ist hier die zentrale Beschr¨nkung. Verfahren, um diesen Engpaß zu beseiti-
a
gen, sind also notwendig. Ein Ansatz ist das sogenannte neue oder map
Verfahren f¨r SAP auf Linux, das weiter unten im Detail beschrieben wird.
u

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
3.2.1 Logische Anforderungen an die SAP-Speicherverwaltung
Das in Abschnitt 2.1.3 beschriebene Workprozess-Multiplexing versetzt das
SAP-System zum einen in die Lage, mit einer begrenzten Menge an Work-
prozessen eine deutlich gr¨ßere Anzahl von Anwendern zu bedienen, bringt
o
aber zum anderen Probleme mit sich, wie sie auch Betriebssysteme haben, die
Multi-Tasking-F¨higkeiten besitzen: Da ein Workprozess (analog: eine CPU)
a
im Laufe der Zeit f¨r verschiedene User (analog: verschiedene Tasks) aktiv ist,
u
m¨ssen vor dem User-Wechsel (analog: Task-Switch) fl¨ chtige Daten gesichert
u u
werden.
Bei dem SAP-System z¨hlen zu diesen fl¨chtigen Daten vor allem die
a u
Ergebnisse von Berechnungen und Auswertungen der ausgef¨hrten ABAP-
u
Programme. Die Gr¨ßenordnung dieser Daten kann in heutigen Anwendun-
o
gen leicht im GigaByte-Bereich liegen, wenn z.B. umfangreiche Datenbank-
Tabellen eingelesen und ausgewertet werden m¨ssen. Im SAP-Sprachgebrauch
u
bilden diese Daten einen Teil des User-Contexts. Wenn ein SAP-Work-
prozess einem User zugeteilt wird, muss er gleichzeitig Informationen erhal-
ten, wie er auf den zugeh¨rigen User-Context zugreifen kann (Roll-In). Bei
o

¨
u
x
der Beendigung der Arbeit f¨r diesen User m¨ssen die fl¨chtigen Daten des
u u
User-Contexts gegen das Uberschreiben durch die Daten des n¨chsten Users
gesch¨tzt werden (Roll-Out).
u
a
Le
Diese Vorg¨nge k¨nnen grunds¨tzlich auf verschiedene Arten realisiert wer-
a o a
den. Allen Verfahren gemeinsam sind folgende Aspekte:
• Die User-Contexte aller User m¨ ssen in einem gemeinsamen Bereich ab-
u
pp

gelegt werden. In der SAP-Terminologie findet man mitunter den Begriff
des User-Memory f¨r diesen Bereich.
u
• Dieser Bereich soll f¨ r alle Work-Prozesse gemeinsam zugreifbar sein. Er
u
ist also kein exklusiver Bereich eines Workprozesses.
sU

Dieser letzte Aspekt impliziert, dass das User-Memory aus Effizienzgr¨ nden
u
mittels einer Variante des oben beschriebenen Shared Memories implemen-
tiert werden sollte. Welche von SAP gew¨hlt wurde, h¨ngt von der gew¨hlten
a a a
Implementierung ab und wird weiter unten genauer beschrieben.
Die Frage, wie die Daten des User-Contexts dem Workprozess bereitge-
stellt werden k¨nnen (Roll-In), bleibt von der Art des Shared Memories aller-
o
dings unber¨hrt. Auch hier existieren mehrere M¨glichkeiten. Die einfachste
u o
Version kopiert die Daten aus dem User-Memory in spezielle Bereiche des
Adressraums des Workprozesses. Dieser Ansatz ¨hnelt sehr stark der Imple-
a
mentierung von Task-Switches bei Betriebssystemen [22], die hüfig die Re-
a
gister der CPU in den Hauptspeicher sichern. Der Roll-Out kopiert dann die
Daten in umgekehrter Richtung aus dem Workprozess in das User-Memory
zur¨ck.
u
Im Bereich der Betriebssysteme hat dieser Ansatz seine Berechtigung, da
die Register und der Hauptspeicher sich hinsichtlich Gr¨ße und Zugriffszeiten
o
stark unterscheiden. Der gleiche Ansatz macht im SAP-System heute aller-
dings weniger Sinn, da er nur von einem Speicherbereich in einen anderen

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
3.2 SAP-Speicherverwaltung f¨ r die Linux Plattform
u 123
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
kopiert. Dennoch wurde dieses Verfahren in fr¨hen SAP-Systemen (Versionen
u
kleiner R/3 3.0) verwendet, da der Kopiervorgang selbst von SAP kontrolliert
werden kann. In den zu Beginn der 90er Jahre eingesetzten Maschinen war
der Hauptspeicher eine knappe Ressource. Der Kopier-Vorgang konnte des-
halb durch einen intelligenten Komprimierschritt erg¨nzt werden, der einen
a
Teil der Speicherlast eines SAP-Systems reduzierte. Minimale Reste dieses
Kopier-Schrittes – derzeit von wenigen hundert KiloByte – finden sich aus
historischen Gr¨nden immer noch im SAP-System.
u
In den heutigen Systemen ist der Hauptspeicher nicht mehr in vergleichba-
rem Maße knapp. Das sehr zeitintensive Kopieren wird deshalb seit l¨ngerem
a
nicht mehr f¨r die Masse der Daten des User-Contexts eingesetzt. Die ele-
u
gantere und schnellere Methode arbeitet mit Pointern. Beim Roll-In wird –
stark vereinfacht – ein Pointer auf den relevanten Bereich des User-Contexts
gesetzt und uber diesen Pointer werden dann alle Zugriffe abgewickelt. Der
¨
Roll-Out entspricht dem Umsetzen bzw. zeitweisen Deaktivieren des Poin-
ters. Dieser Ansatz ist – mit seinen im Folgenden besprochenen Varianten –
die Grundlage aller heutigen Formen der Verwaltung des SAP-User-Memory.

Shared Memory unter SAP x
Le
F¨r die Speicherung des User-Memory stehen auf einer Linux-Plattform
u
heute grunds¨tzlich die drei unter Abschnitt 3.1.3 beschriebenen Formen zur
a
Verf¨gung. In den ersten von SAP unterst¨tzen Linux-Distributionen, die
u u
pp

auf dem Kernel 2.2 aufsetzten, stand allerdings das tmpfs noch nicht zur
Verf¨gung. Somit musste das User-Memory entweder uber ein Datei-Mapping
u ¨
oder uber das SysV Shared Memory realisiert werden.
¨
Das Datei-Mapping stellte anf¨nglich keine vollwertige L¨sung dar, da erst
a o
mit dem Linux-Kernel 2.4 das gemeinsame und nicht an eine Datei gebundene
sU

Mapping eingef¨hrt wurde. Genau diese Art ist jedoch f¨r das SAP-System
u u
– wie oben beschrieben – wesentlich. Es blieb damit nur die SysV-Variante.
Aber auch hier ergaben sich Probleme. So ist z.B. in Unix-basierten Sys-
temen die Anzahl der SysV-Segmente, s. S. 120, begrenzt. Die Zuteilung eines
eigenen SysV-Segments zu einem SAP-User verbot sich damit von selbst. Die
einzige M¨glichkeit, die f¨r auf Kernel 2.2-basierenden Systemen blieb, war
o u
die Zusammenfassung aller User-Contexte in ein SysV-Segment. In der SAP-
Terminologie wird es auch als Extended Memory bezeichnet.
Der im vorigen Abschnitt beschriebene Pointer auf den gerade ben¨tigten
o
User-Context zeigt damit auf einen Teil dieses SHM-Segments. Bei diesem
Verfahren blendet ein SAP-Workprozess damit zwar alle User-Contexte in
seinen eigenen virtuellen Adressraum ein, durch geeignete Schutzmechanismen
wird aber verhindert, dass auf andere als den gerade aktuellen User-Context
vom Workprozess zugegriffen werden kann.
Abbildung 3.3 bringt die soeben beschriebene Situation ins Bild. Die ge-
rade von einem Workprozess bearbeiteten User-Contexte sind ohne Schraffur
dargestellt. Die anderen User-Contexte sind gesch¨tzt, so dass kein Zugriff
u

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c

x
Le
Abb. 3.3. Workprozesse und User-Contexte im alten Memory Management
pp

m¨glich ist. Ebenfalls eingezeichnet sind die SAP-Buffer (Nametab, Tabellen-
o
puffer, PXA, . . . ), die auch als (SysV) Shared Memory realisiert sind. Die
Lage der zugeh¨rigen Segmente ist allerdings nicht maßstabsgerecht angege-
o
sU

ben, sondern deutet nur die Existenz der Puffer an.
Das Bild macht offensichtlich, dass in dieser Variante als begrenzender Fak-
tor die Summe der User-Contexte auftritt. Diese Summe muss kleiner sein als
der verf¨gbare virtuelle Adressraum eines SAP-Workprozesses. Nach dem auf
u
S. 116 Gesagten liegt die Gr¨ße des f¨r Shared Memory zug¨nglichen Berei-
o u a
ches auf 32-Bit Linux bei knapp unter 2 GByte. Davon muss nach der Abb. 3.3
noch der Platz f¨r die SAP-Buffer abgezogen werden, so dass typischerweise
u
von ca. 1 GByte f¨r alle User-Contexte im SAP-System zusammen ausgegan-
u
gen werden kann. Diese Restriktion ist f¨r moderne Systeme nat¨ rlich ein
u u
merkliches Problem.
Eine denkbare L¨sungsm¨glichkeit k¨nnte in der Installation weiterer Ap-
o o o
plikationsserver auf einem Rechner bestehen. Da jeder Applikationsserver
dann weniger User zu verarbeiten h¨tte, st¨nde jedem einzelnen User mehr
a a
Platz im Extended Memory bereit. Mit der Installation weitere Applikations-
server werden aber auf der anderen Seite zahlreiche Komponenten dupliziert,
z.B. die Puffer, so dass damit sicher mittelfristig kein echter Gewinn verbun-
den ist.

Saponlinux

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Saponlinux