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
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.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 125
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
Einen anderen Weg w¨hlt die Implementierung der neuen Speicherverwal-
a
tung, die im Abschnitt 3.2.3 vorgestellt wird. Sie blendet nur noch den aktuell
ben¨tigten User-Context ein und verschiebt damit die Gr¨ßeneinschr¨nkung
o o a
auch f¨r 32-Bit-Systeme hin zu gr¨ßeren User-Contexten.
u o

3.2.2 Die standard SAP-Speicherverwaltung f¨ r Linux
u

Das Speichermanagement, das unter dem 2.2-Kernel alleine m¨glich war und
o
auch noch bis zum SAP-Basisrelease 4.6 den Standard bildete, basiert auf
einigen der oben schon beschriebenen technischen Konzepte:
• Der initiale Teil der Daten eines User-Contexts wird in den Workprozess
kopiert. Der Bereich im virtuellen Adressraum, der diese Daten aufnimmt,
wird in der SAP-Terminologie als lokaler Roll-Bereich bezeichnet. Tech-
nisch betrachtet ist dieser lokale Rollbereich ein vorab reservierter Bereich
des Heaps.
Ein winziger Teil dieses Kopiervorgangs (wenige 100 KByte) ist fest im
SAP-Applikationsserver implementiert und nicht durch Profilparameter

x
beeinflussbar. Beim Roll-Out, d.h. dem Kopieren dieser Daten aus dem
Workprozess hinaus, landen die Daten in einem weiteren Bereich des Sha-
Le
red Memory, dem globalen Rollbereich oder auch Roll-Puffer. Der
Roll-Puffer nimmt also einen Teil aller User-Contexte gemeinsam auf.
Bei einer angemessenen Einstellung dieses Anteils des User-Contexts liegt
keine hohe Last auf dem globalen Rollbereich.
pp

• Der uberwiegende Teil des User-Contexts wird durch die bereits oben be-
¨
schriebene Pointer-Operation zug¨nglich gemacht. Die User-Contexte sind
a
dabei auf die in Abb. 3.3 dargestellte Weise alle zugleich in den virtuellen
Adressraum des Workprozesses eingeblendet.
sU

Aus Sicherheitsgr¨nden geschieht diese Einblendung aber zun¨chst so,
u a
dass der jeweilige Workprozess auf keinen der Userkontexte zugreifen
kann. Der Workprozess muss deshalb den zugeordneten Speicherbereich
explizit freigeben. Auf einem Unix-basierten System geschieht dies durch
den Systemaufruf mprotect. Beim Roll-Out des Benutzerkontexts werden
die Rechte des Speicherbereichs im Extended Memory wieder auf die al-
ten Werte zur¨ckgesetzt und er damit vor dem Lese- und Schreibzugriff
u
gesch¨tzt. Hierdurch wird verhindert, dass ein Benutzer den Speicherbe-
u
reich eines anderen Benutzers im System lesen oder sogar ver¨ndern kann.
a
Dar¨ber hinaus tritt als Reserve der restliche Heap als dritter Speicher-
u
bereich hinzu, der f¨r die Allokierung von weiteren Daten des User-Contexts
u
verwendet werden kann. Abbildung 3.4 zeigt die beteiligten Speicherberei-
che graphisch. Die uber Pointer zugegriffenen Bereiche sind schraffiert, der
¨
Rollbereich ist dichter gepunktet und der zus¨tzliche Heap leichter gepunk-
a
tet gezeichnet. Man beachte hier, dass Heap-Speicher an vielen Stellen allo-
kiert sein kann und dass der Heap auch kein Gegen¨ber im Shared Memory
u
besitzt. Er kann demnach als privater Speicherbereich betrachtet werden.

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.4. Beteiligte Speicherbereiche beim alten Speichermanagement

Die Bedeutung dieser Eigenschaft und das Zusammenspiel der beschriebenen
pp

Komponenten erschließt sich am besten, wenn in den folgenden Abschnitten
die Besonderheiten von Dialog- und Nicht-Dialog-Workprozessen genauer be-
leuchtet werden [34].
sU

Die Allokierungsreihenfolge f¨ r Dialog-Workprozesse
u

Die einfachste Art, sich das Zusammenwirken der Rollbereiche, des User-
Memory und des restlichen Heaps zu verdeutlichen, bietet die Betrachtung der
Schritte, die bei der Einlagerung eines anf¨nglichen kleinen User-Contexts in
a
einen Dialog-Workprozess ablaufen. Wir nehmen als Szenario dabei an, dass
der User-Context nach der Einlagerung in den Dialog-Workprozess z.B. durch
den Aufbau von internen ABAP-Tabellen kontinuierlich an Gr¨ße zunimmt.
o
Die Schritte bei der Einlagerung und Verarbeitung dieses User-Contexts
sind im Einzelnen:
1. Zu Beginn werden die initialen Teile des User-Contexts in die lokale Roll-
Area kopiert. Dieser Vorgang ﬁndet unabh¨ngig von der Parametrisierung
a
des SAP-Systems immer statt.
o a ¨
Diesem Schritt k¨nnen sich weitere Kopiervorg¨nge anschließen. Uber das
Ausmaß dieses Kopierens und damit die Nutzung der Roll-Area zu diesem
Zeitpunkt entscheiden Einstellungen von Proﬁlparametern, die ab S. 128
genauer beschrieben werden.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 127
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
2. Die folgenden Speicherallokierungen geschehen dann im Extended Me-
mory. Hier existieren allerdings maximale Grenzen f¨r die Menge an Ex-
u
tended Memory, die ein User-Context einnehmen darf. Diese maximalen
Grenzen werden oft auch als Quotas bezeichnet. Diese Beschr¨nkung a
ist aufgrund der auf S. 123 beschriebenen Struktur nachvollziehbar: Kein
einzelner User-Context sollte das gesamte Extended Memory einnehmen
d¨rfen und damit die anderen Benutzer im System blockieren. Der Spei-
u
cherbereich des Benutzerkontextes wird uber den schon besprochenen Sys-
¨
temaufruf mprotect() les- und schreibbar gemacht.
3. Wenn der zul¨ssige Teil des Extended Memory nicht ausreicht, so wird der
a
restliche Teil der Roll-Area f¨r die Bereitstellung von Speicher herangezo-
u
gen. Typischerweise umfasst dieser Bereich einige wenige MByte. Damit
stellt er f¨r große User-Contexte kaum einen Gewinn dar. F¨r kleine Con-
u u
texte jedoch, die wegen eines ausgelasteten Extended Memory dort keinen
Speicher mehr erhalten, kann er ausreichen, um die Speicheranforderun-
gen zu erf¨llen. Die Daten in der Roll-Area werden im Gegensatz zu den
u
Daten im n¨chsten und letzten Speicherbereich beim Roll-Out auf den
a
globalen Roll-Buffer ausgelagert und sind damit f¨r nachfolgende Work-
u
prozesse verf¨ gbar.
u
x
4. Sobald auch die Roll-Area gef¨llt ist, werden ggf. immer noch anste-
u
Le
hende Speicheranforderungen bis zu einer einstellbaren Grenze oder bis
zur Adressraumgrenze aus dem restlichen Heap befriedigt. F¨r diese Da-
u
ten gibt es jedoch keine Auffangbereiche (backing store) außerhalb des
Workprozesses. Die Daten k¨nnen damit nur noch innerhalb des Work-
o
pp

prozesses verarbeitet werden, der gerade den aktuellen Benutzerkontext
bearbeitet. Als Konsequenz muss der Workprozess dem gerade aktuellen
Benutzer so lange zugeordnet bleiben, bis der Dialogschritt abgearbeitet
ist. Im SAP-Sprachgebrauch ist der Workprozess damit im PRIV-Modus
sU

(PRIV f¨r privat). Der Workprozess nimmt solange nicht mehr am nor-
u
malen Multiplexing-Zyklus teil, bis der Verarbeitungsschritt beendet ist
und der Workprozes durchgestartet werden kann. Dieser PRIV-Modus
entspricht damit einer Ausnahmesituation, die u.a. durch den Einsatz der
Roll-Area vermieden werden soll.
Speicheranforderungen, die uber diese vier Allokierungsm¨glichkeiten hinaus-
¨ o
gehen, f¨hren zu einem Abbruch des anfordernden ABAP-Programms. Zu
u
beachten ist in diesem Fall, dass es sich hier nicht um eine Out-Of-Memory-
Situation des Betriebssystems handeln muss, sondern zun¨chst nur eine SAP
a
Quota erreicht wurde oder der virtuelle Adressraum des Workprozesses nicht
mehr ausreicht um alle Speicheranforderungen befriedigen zu k¨nnen.
o
Der Roll-Out arbeitet dann analog:
1. Sch¨tzen des gerade aktiven Speicherbereiches im Extended Memory vor
u
Lese- und Schreibzugriffen,
2. L¨sen des Pointers durch Umsetzung in das Extended Memory,
o
3. Kopieren der Daten des lokalen Roll-Bereich in den globalen Roll-Puffer.

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
Ausgehend von typischen Gr¨ßenordnungen f¨r den lokalen Roll-Bereich sind
o u
im schlimmsten Fall also einige MByte Daten zu kopieren. Bei einer schlechten
Konfiguration kann dies ein merkliches Performance-Problem darstellen.

Die Allokierungsreihenfolge f¨ r Nicht-Dialog-Workprozesse
u

Nicht-Dialog-Workprozesse, wie ein Batch-Workprozess, unterliegen anderen
Anforderungen als Dialog-Workprozesse. F¨r den gerade betrachteten Zu-
u
sammenhang ist vor allem relevant, dass z.B. Batch-Workprozesse nicht dem
Workprozess-Multiplexing unterliegen. Die Speicherallokierung muss deshalb
nicht prim¨r Bereiche ber¨cksichtigen, die auch anderen Workprozessen zur
a u
Verf¨gung gestellt werden k¨nnen (Extended Memory, Roll-Bereich). Im Ge-
u o
genteil sollte Extended Memory, welches in vielen Situationen eine knappe
Ressource ist, sparsam verwendet werden.
Die Allokierungsreihenfolge der Nicht-Dialog-Workprozesse folgt deshalb
einem anderen Muster:
a
x
1. Zun¨chst wird der (gesamte) lokale Roll-Bereich mit Daten gef¨ llt.
u
2. Dann geschieht die Speicherallokierung im privaten Heap des Workprozes-
ses. Auch hier existiert eine einstellbare Grenze f¨r die maximal m¨gliche
u o
Le
Menge des zu allokierenden Speichers.
3. Erst wenn beide Bereiche gef¨llt sind, wird im Extended Memory Speicher
u
gesucht.
pp

Auch hier kommt es zu einem Abbruch des Programms, wenn alle genannten
Bereiche nicht mehr ausreichen oder aber vom Betriebssystem kein Speicher
mehr zur Verf¨gung gestellt werden kann.
u
sU

Wesentliche Parameter der standard SAP-Speicherverwaltung f¨ r
u
Linux

In den beiden letzten Abschnitten wurden die Ablüfe bei der Allokierung von
a
Speicher in Dialog- und Nicht-Dialog-Workprozessen strukturell beschrieben.
Die SAP Profilparameter, die das Verhalten im Detail bestimmen, fassen wir
in diesem Abschnitt zusammen.
F¨r Dialog-Workprozesse stellt sich die Situation wie folgt dar:
u
1. Der Parameter ztta/roll area bestimmt die maximale Gr¨ße des loka-
o
len Roll-Bereichs. Der initial kopierte Teil der Roll-Area wird durch den
Parameter ztta/roll first begrenzt. Bis zu dieser Grenze werden im
ersten Allokierungsschritt Daten in den Workprozess kopiert. Meistens ist
es angebracht, den Standardwert von ztta/roll first = 1 unver¨nderta
zu ubernehmen. Damit wird das SAP-System angewiesen, nur den tech-
¨
nisch minimal notwendigen Teil zu kopieren und dann sofort Speicher im
Extended Memory anzufordern.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 129
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.5. Allokierung und Parameter bei Dialog-Workprozessen in der std -
Le
Implementierung
pp

2. Die gesamte Gr¨ße des Extended Memories pro Instanz wird durch den Pa-
o
rameter em/initial size MB gegeben. Ein einzelner User-Context kann
dabei allerdings nur bis zu Grenze ztta/roll extension anwachsen. Die
gesamte Gr¨ße des Extended Memories einer Instanz unterliegt aller-
o
dings einer Einschr¨nkung. In alteren Releases war die maximale Gr¨ße
a ¨ o
sU

des Extended Memories, wie sie durch em/initial size MB gegeben ist,
durch den Ausdruck 8192*em/blocksize KB begrenzt. Der Proﬁlparame-
ter em/blocksize KB gibt die Gr¨ße der Einheiten an, in denen Speicher-
o
platz im Extended Memory verwaltet und zugeteilt werden kann. F¨r den
u
Default von em/blocksize KB = 1024 waren damit nur 8 GB an Exten-
ded Memory allokierbar. Um einen gr¨ßeren Bereich zu erhalten, musste
o
die Blockgr¨ße erh¨ht werden. Inzwischen liegt die Grenze bei 32 Bit Sys-
o o
temen bei 16384*em/blocksize KB.
Das Extended Memory ist selbst noch in zwei Bereiche unterteilt: Einen
workprozess¨ bergreifenen Bereich, der administrative Daten aufnimmt
u
welche zwischen allen Workprozessen geteilt werden, und dem Bereich
im Extended Memory, der die eigentlichen User-Contexte aufnimmt.
3. Der restliche Bereich der Roll-Area (ztta/roll area) wird anschließend
gef¨llt.
u
4. Der Heap darf nur bis zu einer Gr¨ße von abap/heap area dia verbraucht
o
werden. Der gesamte, allen Workprozessen eines Applikationsservers er-
laubte Heap wird durch abap/heap area total festgelegt.

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
In diesem Umfeld sind noch drei weitere Parameter zu erw¨hnen. Der Pa-
a
rameter abap/heaplimit gibt die Grenze an, bis zu der ein Workprozess
ohne erzwungenen Neustart Heap allokieren kann. Bei einem gr¨ßeren Heap-
o
Verbrauch wird der Workprozess nach Abarbeitung des Dialogschritts ge-
zielt neu gestartet. Diesem Sondermechanismus liegt der Gedanke zugrunde,
dass solche Prozesse Speicherplatz unn¨tig belegen und damit zu einem
o
Speicherengpass beitragen k¨nnen. Bei Linux ist das durch die verwendeten
o
Swapping/Paging-Algorithmen (s. S. 165) zwar nicht sehr kritisch, schadet
allerdings in den meisten F¨llen auch nicht. Weiter kann durch diesen Mecha-
a
nismus sichergestellt werden, dass PRIV Situationen wieder aufgel¨st werden
o
und der Workprozess nach dem Durchstarten wieder am normalen Multiple-
xing teilnehmen kann.
Der Parameter ztta/roll area bestimmt indirekt auch die Gr¨ße deso
globalen Roll-Buffers. Der Parameter rdisp/ROLL SHM gibt die Gr¨ße dieses
o
Puffers direkt an. Neben diesem Puffer im Shared Memory existiert noch eine
Erg¨nzungsdatei im Dateisystem. Ihr Pfad und Name im Dateisystem wird
a
durch den Profilparameter rdisp/rrol file bestimmt. Normalerweise ist der
Name /usr/sap/<SID>/<Instanz-Name>/data/ROLLFL<Instanz-Nummer>.
o
x
Die Gr¨ße der Datei wird durch den Parameter rdisp/ROLL MAXFS festge-
legt. Sollte der Roll-Puffer im Shared Memory nicht ausreichen, und ist die
Le
Datei im Dateisystem groß genug, kann der Speicher langsamer aber trotzdem
noch abgelegt werden.
F¨r Nicht-Dialog-Workprozesse ¨ndert sich an den relevanten Para-
u a
metern nur wenig:
pp

1. Auch hier bestimmt ztta/roll area die Gr¨ße des lokalen Roll-Bereiches.
o
Bis zu dieser Gr¨ße wird bei Nicht-Dialog-Workprozessen direkt in einem
o
Schritt kopiert.
sU

2. Der erlaubte Heap ist durch abap/heap area nondia gegeben.
3. Der Bereich im Extended Memory ist pro User Context ebenfalls durch
ztta/roll extension in seiner Gr¨ße begrenzt.
o
Auch f¨r Nicht-Dialog-Workprozesse gelten die Parameter abap/heaplimit,
u
abap/heap area total, rdisp/ROLL SHM und rdisp/ROLL MAXFS unver¨n- a
dert.
Die beiden Diagramme in Abb. 3.5 und 3.6 zeigen noch einmal diese
Ablüfe bei der Allokierung von Speicher und die jeweils bestimmenden Pa-
a
rameter. Die Darstellung verwendet dabei die gleichen Konventionen wie in
Abb. 3.4.
Ein Speicherbereich, der im Zusammenhang mit der Speicherverwaltung
mitunter genannt wird, mittlerweile logisch mit dem Wechsel von User-
Contexten aber kaum noch etwas zu tun hat, ist der sogenannte Page-
Bereich. Wir beschreiben diesen Bereich des SAP ABAP-Applikationsservers,
der f¨r alle Arten von Workprozessen eine ¨hnliche Semantik besitzt, ab-
u a
schließend und der Vollst¨ndigkeit halber noch kurz. Er hat nichts mit dem
a
auf S. 116 beschriebenen grundlegenden Pagekonzept des Betriebssystems zu

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 131
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.6. Allokierung und Parameter bei Nicht-Dialog-Workprozessen
Le
tun, sondern dient prim¨r der Aufnahme von Daten aus speziellen ABAP-
a
Befehlen, z.B. IMPORT/EXPORT TO/FROM MEMORY. Auch dieser Speicherbereich
pp

ist, ¨hnlich wie der globale Roll-Bereich, in zwei Bereiche aufgeteilt: Ein
a
Teil liegt im Hauptspeicher und wird als Page-Puffer bezeichnet. Der an-
dere Teil liegt als Pagefile im Dateisystem. Die Gr¨ße der Bereiche wird
o
durch die Profilparameter rdisp/PG SHM bzw. rdisp/PG MAXFS beschrieben.
sU

Sie geben die Gr¨ße in Einheiten von 8 KB an. Die Lage des Pagefile be-
o
stimmt der Parameter rdisp/rpag file. Er wird standardm¨ßig auf den Wert
a
/usr/sap/<SID>/<Instanz-Name>/data/PAGFIL<Instanz-Nummer> gesetzt.

3.2.3 Die mapped SAP-Speicherverwaltung f¨ r Linux
u

Auf Plattformen, auf denen der virtuelle Adressraum beschr¨nkt ist, stellt
a
der Ansatz des Standard-Verfahrens einen gravierenden Nachteil dar. Wie
Abb. 3.3 auf S. 124 zeigt, sind in diesem Verfahren alle vorhandenen User-
Kontexte gleichzeitig in den ohnehin knappen virtuellen Adressraum eines
Workprozesses eingeblendet. Damit ist die maximale Gr¨ße der Summe der
o
User-Kontexte durch den verf¨gbaren Adressraum festgelegt.
u
Ein Ausweg aus diesem Engpass besteht nun sicherlich darin, jeweils nur
den gerade ben¨tigten User-Kontext in den Adressraum des Workprozesses
o
einzublenden. Damit kann dann ein User-Kontext so groß werden, wie im
Standard-Verfahren die Summe aller User-Kontexte. Diesem Weg folgt die
neue Speicherverwaltung des SAP-Systems auf Linux. Es ist klar, dass damit

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
die maximale Gr¨ße f¨r einen User-Kontext signifikant w¨chst. User-Kontexte
o u a
von 1 bis 1.5 GByte Gr¨ße sind damit m¨glich. Ebenfalls ist damit der Anzahl
o o
der SAP User, die ein SAP Applikationsserver sogar auf einer 32-Bit-Plattform
verarbeiten kann, theoretisch nach oben hin keine Grenzen mehr gesetzt. Nur
noch praktische Begrenzungen spielen eine Rolle, wie etwa verf¨ gbarer physi-
u
kalischer Hauptspeicher, Anzahl der CPUs oder Durchsatz des I/O Systems.
In den folgenden Abschnitten beschreiben wir zun¨chst die Voraussetzun-
a
gen, die das Betriebssystem bieten muss, um das neue Verfahren zu implemen-
tieren. Dann zeigen wir die grundlegenden Ablüfe der neuen Implementierung
a
auf und diskutieren Aspekte der Konfiguration des neuen Ansatzes. Hierzu
z¨hlt auch das Zero Administration Memory Management unter Linux. Ein
a
kurzer Vergleich der beiden Verfahren bildet den Abschluss der Besch¨ftigung
a
mit der neuen Implementierung.

Notwendige Betriebssytemressourcen

F¨r die Implementierung des neuen Verfahrens scheidet eine SysV-basierende
u

x
Technologie aus den schon auf S. 123 genannten Gr¨nden aus: Mit einem
u
gemeinsamen Speicher auf SysV-Basis kann nicht jedem User ein eigenes Seg-
ment zugeordnet werden. Erst mit der Einf¨hrung des POSIX Shared Memory
u
Le
im Linux Kernel 2.4 ergab sich also die M¨glichkeit, das bisherige Speicher-
o
management von SAP f¨r Linux durch eine weitere Implementierung, die den
u
gerade skizzierten Ideen folgt, zu erg¨nzen.
a
pp

Die Grundidee dabei ist sehr einfach: Das POSIX Shared Memory realisiert
ein Dateisystem, das sogenannte tmpfs, das rein im Hauptspeicher liegt und
damit sehr schnelle Zugriffe gestattet. Dateien in diesem Dateisystem k¨nnen
o
allerdings auf normalem Wege bearbeitet werden. Insbesondere k¨nnen ganze
o
sU

oder nur Teile von Dateien in den virtuellen Adressraum eines Prozesses ein-
geblendet werden. Da sich dabei die Daten der Dateien im Hauptspeicher
befinden, geschehen Operationen wie das Ein- und Ausblenden und der Da-
tenzugriff mit sehr hoher Geschwindigkeit. Die Dateien dieses In-Memory-
Dateisystems k¨nnen damit als Backing Store f¨r die User-Kontexte des
o u
SAP-Applikationsservers dienen. Entscheidend ist dabei nach dem oben Ge-
sagten nat¨rlich, dass nun auch nur Teile dieser Dateien, eben die einzelnen
u
User-Kontexte, in den virtuellen Adressraum eines SAP-Workprozesses ein-
geblendet werden k¨nnen.
o
Um das neue Speichermanagement inklusive des POSIX Shared Memory
zu implementieren, sind auf Betriebssystemseite einige Voraussetzungen not-
wendig:
1. Auf dem Linux Server muss mindestens ein Kernel 2.4 laufen. Erst seit
dieser Kernelversion ist POSIX Shared Memory und damit auch das
tmpfs verf¨gbar. Diese Bedingung sollte allerdings in Zeiten eines auch f¨r
u u
SAP Systeme verf¨gbaren Linux Kernel 2.6 keine wirkliche Einschr¨nkung
u a
mehr bedeuten.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 133
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
2. Das tmpfs ist der zentrale Bestandteil des neuen Speichermanagements:
In ihm wird der Backing Store der SAP Benutzerkontexte auf Betriebs-
systemebene abgebildet. Mitunter findet sich f¨r dieses Dateisystem auch
u
noch der alte Name shmfs oder auch shm, der in Linux Kernel 2.3 verwen-
det wurde. Dieser Name zeigt sehr deutlich die Absicht des Dateisystems:
Es ist ein SHared Memory File System.
Zwei kleinere technische Bemerkungen beleuchten an dieser Stelle das
tmpfs noch etwas n¨her:
a
a) Die Funktionen im Linux-Kernel, die das tmpfs implementieren, wer-
den Kernel-intern auch dazu verwendet, das SysV-Shared Memory zu
realisieren. Diese Tatsache ist aber auf der Ebene der Anwendungen
nicht sichtbar und erfordert auch keine Aktionen des Administrators.
Ebenso mountet der Linux-Kernel das tmpfs automatisch, um Ano-
nymous Shared Memory zu realisieren.
b) Das tmpfs unterscheidet sich von den im Linux-Umfeld bekannten
RAM Disks. Es liegt zwar auch im Hauptspeicher und ist damit beim
Reboot fl¨chtig, allerdings kann es je nach Bedarf bis zu einer maxi-
u
malen Gr¨ße im Hauptspeicher dynamisch wachsen oder schrumpfen.
o
x
RAM Disks hingegen werden mit einer festen Gr¨ße angelegt und be-
o
legen unverz¨glich den konfigurierten Speicherplatz, wohingegen ein
u
Le
leeres tmpfs keinen Speicherplatz ben¨tigt.
o
Die Existenz des tmpfs allein reicht nat¨rlich noch nicht f¨r den Einsatz
u u
im SAP-Applikationsserver aus. Wie jedes Dateisystem muss auch das
tmpfs vor dem Gebrauch in den Verzeichnisbaum des Linux-Rechners
pp

gemountet werden. Dies ist die zweite Voraussetzung. Etwas genauer
gesagt, erwartet SAP, dass der Mountpunkt /dev/shm verwendet wird.
Grunds¨tzlich w¨re hier zwar jeder beliebige Ort denkbar, die von POSIX
a a
definierte Funktion shm open(), die ein POSIX Shared Memory Objekt
sU

erzeugt, erwartet es aber an genau diesem Ort. Diese Funktion ist ab der
Version 2.2 der glibc verf¨gbar.
u
Die Maximalgr¨ße des tmpfs wird dabei uber Mountoptionen vorgegeben,
o ¨
z.B. bewirkt der folgende Aufruf
mount -t tmpfs -o size=5G tmpfs /dev/shm
ein Einh¨ngen des tmpfs im Verzeichnis /dev/shm mit einer maximalen
a
Gr¨ße von 5 GB. Die Gr¨ße kann dabei entweder wie hier absolut angege-
o o
ben werden oder relativ zum vorhandenen physikalischen Arbeitsspeicher:
etwa size=30%. Der Default ist derzeit size=50%, d.h. das tmpfs wird halb
so groß wie der physisch vorhandenen Hauptspeicher konfiguriert. Weitere
Mount-Optionen sind die Anzahl der Inodes nr inodes, s. S. 230, im Dat-
eisystem und die Berechtigungen mode.
In manchen Distributionen geschieht das Mounten des tmpfs durch einen
Eintrag in der Konfigurationsdatei des Kernels /etc/sysconfig/kernel.
Andere schreiben standardm¨ßig einen Eintrag der Form
a
tmpfs /dev/shm tmpfs defaults 0 0

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
in die Datei /etc/fstab. Dadurch wird das tmpfs mit einer Gr¨ße von
o
50% des physischen Hauptspeichers in /dev/shm eingeh¨ngt. Da der Spei-
a
cherplatz im tmpfs allerdings erst bei Bedarf in Anspruch genommen wird
und f¨r das SAP-System gen¨gend Platz im tmpfs wesentlich ist, wird
u u
empfohlen, diesen Standard mit einem Wert von 75% von RAM + Swap-
bereich zu ubersteuern. Bei einem typischen SAP-Server mit 4 GB RAM
¨
und 8 GB Swapbereich w¨re damit folgender Eintrag in der /etc/fstab
a
im Allgemeinen eher sinnvoll
tmpfs /dev/shm tmpfs size=9G 0 0
Der Zugriff auf das tmpfs erfolgt uber g¨ngige Filesystemoperationen,
¨ a
so dass Inhalte wie normale Dateien behandelt werden k¨nnen und der
o
Speicherverbrauch mittels der bekannten Befehle du und df uberpr¨ft
¨ u
werden kann. Aus der Sicht der Werkzeuge, die den Speicherbedarf beob-
achten, stellt sich das tmpfs allerdings etwas anders dar. Die Pages, die
das tmpfs bilden, k¨nnen entweder im Hauptspeicher oder ausgelagert
o
im Swap-Bereich liegen. Im ersten Fall befinden sie sich im Page Cache
und werden deshalb z.B. vom Programm free als cached und nicht als
x
shared angegeben. Das ist zu ber¨cksichtigen, wenn nach der Ursache
u
großer Speicheranforderungen gesucht wird.
Le
3. Die ersten beiden Voraussetzungen, die korrekte Version des Linux-Kernels
und das Mounten des tmpfs, sind direkt mit dem neuen Verfahren zur Ver-
waltung der User-Kontexte verbunden. Daneben m¨ssen aber auch andere
u
Speicherbereiche des SAP Applikationsservers konfiguriert werden. Diese
pp

Einstellungen gelten f¨r das neue und das alte Speichermanagement glei-
u
chermaßen.
An erster Stelle ist hier der Linux Kernel Parameter SHMMAX zu nennen,
der die maximale erlaubte Gr¨ße eines (SysV-) Shared Memory Segments
o
sU

angibt. Dieser Parameter kann wie viele andere auch zur Laufzeit des
Linux-Systems umgestellt werden. Grundlage daf¨r sind die sogenannten
u
System Controls, sysctls. Unter Linux bietet das proc-Dateisystem die
M¨glichkeit, die Konfiguration uber die sysctls durch Schreiben auf spe-
o ¨
zielle Dateien vorzunehmen. Unter /proc/sys finden sich Verzeichnisse,
wie z.B. kernel, in denen Dateien sichtbar gemacht sind, die hüfig ein
a
¨
direktes Andern der gleichnamigen Kernelparameter erm¨glichen. Als Bei-
o
spiel kann hier die Datei /proc/sys/kernel/shmmax dienen, die den oben
genannten Parameter einstellt. Ein
echo 1073741824 > /proc/sys/kernel/shmmax
setzt die maximale Gr¨ße eines Shared Memory Segments auf 1 GB.
o
Ein aquivalenter Ansatz verwendet das Programm sysctl, das w¨hrend
¨ a
des Boot-Vorgangs aufgerufen wird. Die Konfiguration geschieht durch
die Datei /etc/sysctl.conf. Ein entsprechender Eintrag in dieser Datei
lautet:
kernel.shmmax = 1073741824

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 135
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
Der Weg uber den sysctl-Befehl erlaubt die automatische Anpassung
¨
der Einstellungen w¨hrend des Bootens und wird deshalb in einer SAP-
a
Umgebung empfohlen.
F¨r einen SAP-Applikationsserver ist der oben gegebenen Wert von
u
1073741824, d.h. 1 GB, der Minimalwert. Bei kleineren Werten wird ty-
pischerweise der Startvorgang, s. S. 83, abgebrochen werden m¨ssen, da
u
manche der SAP-Puffer nicht angelegt werden k¨nnen. Kandidaten f¨r
o u
große Speicherbereiche sind immer der PXA-Puffer und im alten Speicher-
management das Extended Memory selbst. Der SAP-Applikationsserver
protokolliert solch einen Fehlerfall an verschiedenen Stellen, darunter den
Entwickler-Traces, s. S. 98, mit.
Je nach Distribution sind noch weitere Einstellungen an Kernelparame-
tern f¨r den Betrieb von SAP Software empfohlen. Diese sind meist nicht
u
prim¨r f¨r den Betrieb der SAP-Instanz notwendig, sondern werden durch
a u
Anforderungen der verschiedenen unterst¨tzten Datenbanken notwendig.
u
Als Einstieg in dieses Thema kann [45] dienen.

Im Zusammenhang mit der Speicherkonfiguration stehen schließlich auch

x
die Empfehlungen, die in den Installationshinweisen der SAP f¨r die Konfigu-
u
ration des Swapbereiches unter Linux zu finden sind. Hier wird – unabh¨ngig
a
Le
vom verwendeten Speichermanagement – eine Gr¨ße des Swapbereichs von
o
mindestens dem Zweifachen des physischen Speichers empfohlen. Obwohl Li-
nux eine relativ flexible Swap-Strategie besitzt und es damit grunds¨tzlich
a
mit kleineren Swapbereichen als z.B. andere Unixe auskommt, sollte an dieser
pp

Stelle nicht gespart werden. Swapbereiche kosten nur Festplattenplatz, feh-
lender Platz im Swapbereich kann aber zu den ber¨chtigten Out-Of-Memory-
u
Situationen (OOM) f¨hren, bei denen das Betriebssystem z.B. einen Anwen-
u
dungsprozess beenden muss.
sU

Grundlagen der neuen Speicherverwaltung

Seit dem Release 6.20 des SAP Web Application Servers verwendet ein SAP-
System auf Linux standardm¨ßig das sogenannte Neue SAP Speicherma-
a
nagement f¨r Linux. Bereits in den SAP Basisreleasen 4.5B und 4.6D war
u
dieses neue Verhalten allerdings bei ausreichend aktuellem SAP Kernelpat-
chstand alternativ zum bisherigen Standardverfahren aktivierbar. Um nun
zwischen den beiden Verfahren wechseln zu k¨nnen, wurde der Parameter
o
es/implementation im SAP-Instanzprofil eingef¨hrt, uber den die Umschal-
u ¨
tung zwischen den Implementierungen stattfindet. Der Parameter besitzt zwei
erlaubte Werte:

• Wird es/implementation = std gesetzt, ist das Standard SAP Speicher-
management f¨r Linux, die SysV Shared Memory Implementierung, ak-
u
tiviert. Hiermit verhalten sich auch neue SAP-Systeme wie in Abschnitt
3.2.2 beschrieben.

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
• Wird es/implementation = map gesetzt, ist das Neue SAP Speicherma- c u -tr a c k

nagement f¨r Linux aktiv und das SAP-System verh¨lt sich wie in die-
u a
sem Abschnitt 3.2.3 ausgef¨hrt. Der Name map r¨hrt daher, dass nun
u u
der Schwerpunkt auf dem wiederholten Einblenden einzelner Userkontexte
liegt.

Wie schon in Kapitel 2.2.1 bei der Beschreibung des Startvorgangs des
SAP-Systems angesprochen, wird das Extended Memory vom Dispatcher-
prozess initialisiert. Anders als bei der Standard-Implementierung werden
beim neuen SAP Memory Management f¨r Linux allerdings nicht die Sys-
u
calls shmget() bzw. shmat() zum Anlegen bzw. Bearbeiten von System V
Shared Memory Segmenten verwendet, sondern der Aufruf shm open() zum
Anlegen von POSIX Shared Memory Objekten. Diese Objekte werden als
Datei im tmpfs mit Namen SAP ES <Instanz-Nummer> <laufende-Nummer>
angelegt. Dieser Name setzt sich aus der SAP-internen Kennung ES f¨r u
Extended Memory Segments, der Nummer der Instanz und einer laufen-
den Nummer zusammen. Die Verwendung der Instanz-Nummer zeigt, dass
o
x
es weiterhin m¨glich ist, mehrere SAP Applikationsserver auf einem Linux-
Rechner zu betreiben. Im neuen Speichermanagement sollte es zwar nicht
mehr notwendig sein, mehrere Instanzen eines Systems auf dem gleichen Rech-
Le
ner zu betreiben. Allerdings erm¨glicht dies auch mehrere Applikationsin-
o
stanzen unterschiedlicher SAP-Systeme auf dem gleichen Server zu betrei-
ben.
pp

Die fortlaufende Nummer erkl¨rt sich dadurch, dass beim Start des Ap-
a
plikationsservers nur ein initialer Bereich im tmpfs angelegt wird, s. Pro-
ﬁlparameter em/initial size MB. Diese Datei w¨ rde dann beispielsweise
u
SAP ES 42 000 heißen. Bei Bedarf kann der verf¨gbare Platz bis zum Errei-
u
chen der maximalen Gr¨ße von (em/max size MB) durch Hinzuf¨gen weite-
o u
sU

rer Dateien erweitert werden. Diese neuen Dateien werden mit der halben
Gr¨ße von em/initial size MB angelegt. Zur Unterscheidung wird die lau-
o
fende Nummer erh¨ht, so dass die zweite Datei im Beispiel dann den Namen
o
SAP ES 42 001 erhalten w¨rde. Zusammen bilden diese Dateien das Extended
u
Memory im neuen Speichermanagement.
Aus der Sicht des SAP Applikationsservers wird nun der bereitgestellte
Platz im Extended Memory f¨r zwei verschiedene Arten von Daten verwen-
u
det. Den gr¨ßeren Teil nehmen die schon mehrfach erw¨hnten User-Kontexte
o a
ein, die nach Bedarf einzeln in den Adressraum eines SAP Workprozesses
eingeblendet (mmap-ed) werden. Der restliche Teil besteht aus Daten, die
User- und Workprozess-¨bergreifend sind und damit nicht dem Mapping beim
u
Roll-In und Roll-Out unterliegen m¨ssen.
u
Dieser Bereich wird in der SAP-Terminologie als Extended Global Me-
mory bezeichnet. In ihm liegen zun¨chst vor allem administrative Daten. Die
a
Gr¨ße dieses Bereiches wird durch den Proﬁlparameter em/global area MB
o
gegeben. Daneben liegt im Extended Global Memory ab dem Release 6.40
auch die ABAP Shared Objects Area. Durch die ABAP Shared Objects

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 137
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.7. Workprozesse und User-Contexte in der neuen Speicherverwaltung
Le
wird ABAP-Programmen eine M¨glichkeit gegeben, eine Form von Shared
o
Memory zu verwenden. Die Gr¨ße dieses Bereiches wird durch den Profilpa-
o
rameter abap/shared objects size MB bestimmt.
pp

Ein SAP-Workprozess, der einen User-Kontext bearbeiten soll, wird diesen
im neuen Speichermanagement in seinen virtuellen Adressraum einblenden.
Der Bereich im virtuellen Adressraum, in den dieser einzelne User-Kontext
eingeblendet wird, wird auch als Adressfenster bezeichnet. Die Gr¨ße die-
o
ses Fensters wird durch den Parameter em/address space MB konfiguriert.
sU

Hierbei ist aber zu beachten, dass dieses Fenster nicht nur den individuel-
len User-Kontext, sondern auch das Extended Global Memory aufnehmen
muss. Es besteht also aus einer sogenannten Private Segment Area und
dem Extended Global Memory. Bei der Einstellung dieses Parameters ist
demzufolge darauf zu achten, dass em/address space MB stets gr¨ßer als die
o
Summe aus der maximal erwarteten Gr¨ße eines Benutzer-Kontextes, der
o
Gr¨ße abap/shared objects size MB und der Gr¨ße em/global area MB ist.
o o

Allokationsreihenfolge eines Workprozesses
Bei der Allokationsreihenfolge eines Workprozesses wird bei Einsatz des neues
Verfahrens nicht mehr zwischen Dialog- und Nichtdialogprozessen unterschie-
den. Da mit der neuen Implementierung schnelles Extended Memory hüfig a
in weitaus gr¨ßerem Umfang als bisher zur Verf¨gung steht, kann es nun
o u
auch von Nicht-Dialogworkprozessen standardm¨ßig verwendet werden. Die
a
Allokationsabfolge ist nun in beiden F¨llen mit der eines herk¨mmlichen Dia-
a o
logworkprozesses identisch:

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

Abb. 3.8. Parameter in der neuen Speicherverwaltung

1. Zun¨chst wird eine kleine Menge im Rollbereich verwendet.
a
2. Danach wird sofort Speicher im Extended Memory allokiert.
u
x
3. Erst wenn dar¨berhinaus noch weiterer Speicher ben¨tigt wird, kommt
der restliche Rollpuffer zum Einsatz.
o
Le
4. Den Abschluss bildet die Allokierung im Prozess-lokalen Heap.
In sehr seltenen und meistens mit SAP zu diskutierenden F¨llen kann es sinn-
a
voll sein, diese Reihenfolge zu ver¨ndern. Daf¨r existiert der Report RSMEMORY,
a u
pp

der es erlaubt, die Allokierungsreihenfolge der einzelnen Workprozesstypen,
unterteilt nach Dialog- und Nicht-Dialogworkprozessen, zur Laufzeit umzu-
schalten.
sU

Wesentliche Parameter der neuen SAP-Speicherverwaltung f¨ r
u
Linux

Viele der SAP Profilparameter, die bei einer Konfiguration f¨r das neue Spei-
u
chermanagement eine Rolle spielen, besitzen eine ¨hnliche oder gar identische
a
Semantik zum Standard-Fall, s. Abschnitt 3.2.2. Bei anderen hingegen ver-
schob sich die Bedeutung leicht, und einige wenige sind neu hinzugekommen.
Wir geben deshalb im Folgenden eine zusammenfassende Darstellung:
• Der Parameter em/initial size MB gibt nun nicht mehr die Gr¨ße deso
kompletten Extended Memory an, sondern nur noch die initiale Gr¨ße der
o
SAP ES-Datei im tmpfs. Wird w¨hrend des Betriebs der SAP Instanz mehr
a
Speicher f¨r Benutzerkontexte ben¨tigt, erweitert der SAP Applikations-
u o
server automatisch das Extended Memory und legt eine neue Datei mit
der halben Gr¨ße von em/initial size MB an. Diese Schrittweite ist im
o
SAP Applikationsserver fest vorgegeben. Bei der x86 Plattform (Intel 32
Bit Linux) ist der initiale Wert auf 2040 MB begrenzt, um die Erweite-
rungsschritte in nicht allzu großen Schritten erfolgen zu lassen.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 139
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
• Neue SAP ES-Dateien im tmpfs werden bis zu einer maximalen Gesamt- c u -tr a c k

gr¨ße von em/max size MB pro SAP Instanz angelegt. Bei der Konfigura-
o
tion dieses Parameters ist darauf zu achten, dass er nicht gr¨ßer als der
o
¨
verf¨gbare Platz im tmpfs eingestellt wird, da es sonst beim Uberschreiten
u
der Dateisystemgrenzen sehr wahrscheinlich zu Abbr¨chen der SAP In-
u
stanz kommt.
• Anders als die beiden vorigen Parameter betrifft em/address space MB
eine workprozesslokale Gr¨ße, das Fenster im virtuellen Adressraum ei-
o
nes Workprozesses, in das ein User-Kontext aus dem Extended Memory
im tmpfs eingeblendet wird. Die Gr¨ße dieses Parameters bestimmt da-
o
durch auch die Menge an Extended Memory mit, die jeder einzelne Be-
nutzerkontext maximal belegen kann. Dieses Adressfenster wird bereits
beim Start der SAP Instanz allokiert/reserviert. Wenn durch zu große
Werte Adressraumgrenzen verletzt werden, kommt es zum Abbruch des
Startvorgangs, was praktisch allerdings nur auf 32-Bit-Plattformen auf-
tritt.
• Weiterhin legt ztta/roll extension die maximale Menge an Extended
Memory eines einzelnen Benutzerkontextes fest, vgl. auch Abschnitt 3.2.2.

x
Damit bestimmt der kleinere der beiden Parameter em/address space MB
und ztta/roll extension aus SAP-Sicht, wieviel Extended Memory ein
Benutzerkontext uberhaupt anfordern kann. Restriktionen aufgrund der
¨
Le
Gestalt des virtuellen Adressraums, z.B. 32-Bit, m¨ssen gegebenenfalls
u
noch beachtet werden.
• Der Parameter em/global area MB bestimmt die maximale Gr¨ße des o
pp

Speicherbereichs im Extended Memory, der f¨r global data, d.h. Be-
u
nutzer- und Workprozess-unabh¨ngige Daten, reserviert ist. War dieser
a
Bereich in ¨lteren SAP-Versionen im Vergleich zum gesamten Extended
a
Memory noch relativ klein, w¨chst seine Bedeutung und dementsprechend
a
auch die Gr¨ße in aktuellen Versionen weiter an:
o
sU

Wurden fr¨her nur Verwaltungsdaten zur internen Kommunikation von
u
SAP Kernelkomponenten, wie Task Handler und Enqueue, mit geringem
Platzbedarf abgelegt, werden hier in aktuellen Versionen auch Speicher-
bereiche des seit Version 6.40 in den Web Application Server integrierten
ITS abgelegt.
Gerade daher ist es wichtig zu erw¨hnen, dass die Gr¨ße dieses Para-
a o
meters vom Adressfenster, d.h. em/address space MB, abgezogen werden
muss, um den faktisch verf¨gbaren Adressraum f¨r einen User-Kontext
u u
im Extended Memory zu erhalten. In kommenden Releases werden noch
weitere Daten in der Extended Global Area hinterlegt werden.
• Der Parameter abap/shared objects size MB setzt die Gr¨ße des Berei-
o
ches f¨r die ABAP Shared Objects. Sie geh¨ren auch zur Extended Glo-
u o
bal Area und liegen damit im Adressfenster von em/address space MB.
Normalerweise ben¨tigen die ABAP Shared Objects recht wenig Platz. In
o
manchen Situationen, wie etwa beim Einsatz des SAP Strategic Enter-
prise Management (SEM), wird allerdings empfohlen, diesen Profilpara-
meter zu erh¨hen. Gerade bei 32 Bit Systemen m¨ssen dabei die besonde-
o 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
ren Rahmenbedingungen bei der Berechnung des verf¨gbaren Adressraums
u
ber¨cksichtigt werden.
u
• Der Parameter em/blocksize KB gibt die SAP-interne Granularit¨t im a
Extended Memory an. Fordert ein Benutzerkontext Speicher an, wird ihm
vom SAP Kernel Speicher in Schritten von em/blocksize KB zugeteilt, auf
den nur dieser Benutzer zugreifen kann. Bei der Parametrisierung sollte
folgendes ber¨cksichtigt werden:
u
– Wird die Blockgr¨ße zu groß gew¨hlt, kommt es zum Verschnitt
o a
von Speicher. Ben¨tigt ein Benutzerkontext Speicher im Extended Me-
o
mory, wird eine Einheit aus den SAP ES-Dateien mit der Gr¨ße vono
em/blocksize KB vom Betriebssystem angefordert. Eventuell kann die-
ser Speicher allerdings intern im SAP-System gar nicht vollst¨ndiga
verwendet werden, da der anfordernde Benutzerkontext nicht so viel
zus¨tzlichen Speicher ben¨tigt. Daraus resultiert, dass gegen¨ber dem
a o u
Betriebssystem mehr Speicher vom SAP-System allokiert wurde, als
intern verwendet werden kann, also der Speicherbedarf gr¨ßer als un-
o
bedingt notwendig ausf¨llt.
a
– Wird im Gegenzug die Blockgr¨ße zu klein gew¨hlt, gibt es zwar we-
o a

x
niger Verschnitt, allerdings kann es nun einfacher zu einer Fragmen-
tierung der SAP-internen Speicherverwaltung und dadurch zu Out-Of-
Memory (OOM) Situationen kommen: Nach einer gewissen Laufzeit
Le
des Systems k¨nnen gr¨ßere Speicherbereiche u. U. nicht mehr zusam-
o o
menh¨ngend allokiert werden.
a
Weiter bedeutet eine gr¨ßere Anzahl von Pages einen erh¨hten Admi-
o o
pp

nistrationsbedarf bei der Verwaltung, was wiederum Auswirkungen auf
die Performance des Systems haben kann.
Aus den beschriebenen Gr¨nden muss bei der Konﬁguration ein prakti-
u
kabler Mittelweg zwischen der Gr¨ße der einzelnen Pages und deren Ge-
o
samtzahl im System gefunden werden. Es zeigt sich, dass vor allem auf
sU

gut best¨ckten Maschinen große Bl¨cke eher zu empfehlen sind. So war
u o
in alteren Releases der Default-Wert f¨ r em/blocksize KB auf 1024, d.h.
¨ u
1 MB, gesetzt. In den Releases ab 6.40 steht der Standard-Wert dagegen
auf 4096.
Die Wahl der Blockgr¨ße hat noch eine weitere Konsequenz: Da jeder Block
o
einzeln vom SAP-System verwaltet werden muss, deﬁniert das SAP-Sys-
tem eine maximale Menge an Bl¨cken, die verarbeitet werden k¨nnen. Das
o o
Produkt dieser Anzahl mit der Blockgr¨ße gibt also die maximale Gr¨ße
o o
des Extended Memories an. In ¨lteren Releases war die Anzahl auf 8192
a
Bl¨cke beschr¨nkt. Bei einer Blockgr¨ße von 1024 ergab sich damit eine
o a o
maximale Gr¨ße des Extended Memories von 8 GB. Mittlerweile wurde
o
auch diese maximale Anzahl auf 16384 erh¨ht. Bei 4096 KB großen Bl¨cken
o o
kann das Extended Memory damit 64 GB groß werden.
Die Parameter abap/heap area *, rdisp/ROLL SHM, rdisp/ROLL MAXFS,
rdisp/PG SHM, rdisp/PG MAXFS, ztta/roll area und ztta/roll first, die
in Abschnitt 3.2.2 zudem noch genannt wurden, verhalten sich exakt wie be-
reits dort beschrieben.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 141
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
Zero Administration Memory Management
Aus den obigen Beschreibungen wird sehr schnell deutlich, dass es eine Viel-
zahl von Einstellm¨glichkeiten und Abh¨ngigkeiten im Bereich der SAP-
o a
Speicherverwaltung gibt. Fehlerhafte oder nicht optimale Setzungen k¨nnen
o
zudem einen erheblichen Einfluss auf die Performance des SAP-Systems ha-
ben. Es war deshalb naheliegend, eine Umgebung zu schaffen, in der ein Groß-
teil der komplexen Konfigurationsaufgaben automatisch erledigt werden kann
und der Administrator des SAP-Systems damit vom Einstellen jedes einzelnen
Parameters befreit wird.
Diese Aufgabe ubernimmt auf der Linux-Plattform das sogenannte Zero
¨
Administration Memory Management, kurz ZAMM.
Es ist derzeit allerdings nur f¨r das neue Memory Management unter Li-
u
nux verf¨gbar, d.h. es/implementation = map. Dies liegt haupts¨chlich daran,
u a
dass die Standard-Implementierung im Linuxumfeld derzeit kaum eingesetzt
wird.
Das ZAMM wurde bewusst in starker Anlehnung an einen ahnlichen An-
¨
satz auf der Windows-Plattform konzipiert. Administratoren, die bereits dies-
bez¨gliche Erfahrungen auf der Windows-Plattform gemacht haben, werden
u
x
sich sehr leicht auch in einer Linux-Umgebung zurecht finden. In beiden
Umgebungen ist die zentrale Gr¨ße des Verfahrens ein neuer Profilparame-
o
Le
ter PHYS MEMSIZE, der im Instanzprofil eines SAP-Applikationsservers einge-
stellt werden kann. In der Linux-Implementierung dient der Parameter als Be-
rechnungsgrundlage f¨r den Anteil, den der SAP-Applikationsserver an den
u
physischen Ressourcen, wie vor allem dem tmpfs, erhalten soll. Aus dieser
pp

Information berechnet der SAP-Applikationsserver zum Startzeitpunkt dann
Vorschlagswerte f¨r weitere Profilparameter der Speicherverwaltung der SAP-
u
Instanz. Diese Vorschlagswerte k¨nnen aber nat¨rlich durch manuelle Eintra-
o u
gungen in den Profilen noch ubersteuert werden, s. S. 94. Durch diese Vor-
¨
sU

gehensweise hat der Systemadministrator die M¨glichkeit lenkend einzugrei-
o
fen, falls ein System besondere Anforderungen an das Speichermanagement
stellt und die Standardeinstellungen bzw. -algorithmen nicht ausreichen. Al-
lerdings ist es bei unsachgem¨ßer Einstellung oder auch beim nur teilweisen
a
¨
Ubersteuern voneinander abh¨ngiger Parameter m¨glich, dass das System mit
a o
verringerter Performance lüft oder sogar uberhaupt nicht mehr startet. Aus
a ¨
diesem Grund sollte man bei manuellen Ver¨nderungen den Anweisungen des
a
SAP Supports folgen, s. [37], oder detaillierte Kenntnisse uber das SAP-Spei-
¨
chermanagement f¨ r Linux und speziell das ZAMM besitzen, wie sie im fol-
u
genden beschrieben werden.
Der Profilparameter PHYS MEMSIZE kann den Anteil an den physischen Res-
sourcen auf verschiedene Weisen angeben. In der einfachsten Form wird er im
Instanzprofil nicht gesetzt. In diesem Fall geht der SAP Applikationsserver da-
von aus, dass die gesamten Ressourcen des Servers der Instanz zur Verf¨ gung
u
stehen sollen. Insbesondere wird dann der gesamte Platz im tmpfs f¨r die In-
u
stanz in Beschlag genommen. Bei einer expliziten Setzung von PHYS MEMSIZE
im Instanzprofil kann der Anteil auf zwei verschiedene Weisen ausgedr¨ ckt u
werden:

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
1. Durch Angabe eines prozentualen Wertes. Eine Beispielsetzung ist
PHYS_MEMSIZE=50%
bei der der SAP-Applikationsserver die H¨lfte des tmpfs f¨r seine Zwecke
a u
belegt.
2. Durch Angabe der absoluten Menge an physischen Speicher in MegaByte,
die zur Verf¨gung stehen soll. So gibt die Setzung
u
PHYS_MEMSIZE=1500
an, dass die Instanz 1500 MegaByte an Hauptspeicher verwenden soll.
Diese Angabe wird allerdings nicht direkt verwendet, sondern zun¨chst
a
zum vorhandenen physischen Hauptspeicher in Bezug gesetzt und damit
wieder zu einer prozentualen Gr¨ße umgewandelt. Mit diesem Prozentwert
o
kann dann die Gr¨ße des zugeh¨rigen Teils des tmpfs bestimmt werden.
o o
Bei einer Gr¨ße des physischen Hauptspeichers von 2000 MB, ergibt sich
o
damit eine erlaubte Nutzung des tmpfs von 75% f¨r diese Instanz.
u
¨
Der Ubersicht halber wird empfohlen PHYS MEMSIZE mit prozentualen
Werten zu konfigurieren.

x
Aus dieser Beschreibung geht hervor, dass der Parameter PHYS MEMSIZE nur
der Bestimmung weiterer SAP Profilparameter dient. Er macht keine Vorgabe,
wieviel physischer Hauptspeicher zu einem gegebenen Zeitpunkt faktisch dem
Le
SAP-Applikationsserver zugeordnet ist. Diese Verteilung wird dem Betriebs-
system uberlassen und ist weiterhin auch noch von anderen Parametern des
¨
SAP-Applikationsservers abh¨ngig, die nicht von ZAMM beeinflusst werden
a
pp

k¨nnen.
o
Die Art und Weise, wie Profilparameter durch das ZAMM beeinflusst wer-
den, wenn keiner der Parameter manuell im Profil ubersteuert wird, schauen
¨
wir uns nun noch genauer an. Das im Folgenden beschriebene Verhalten spie-
gelt den Stand des SAP Kernel 6.40 f¨r 32-Bit-Plattformen wider und kann
u
sU

sich durchaus in Zukunft andern:
¨
• Der Parameter em/initial size MB erh¨lt den Wert von PHYS MEMSIZE.
a
Dadurch wird dem Parameter der absolute Wert von PHYS MEMSIZE zuge-
wiesen, mit dessen Gr¨ße die erste der SAP ES-Dateien im tmpfs angelegt
o
wird. Auf 32-Bit Systemen ist diese initiale Gr¨ße auf 2040 MB beschr¨nkt.
o a
Diese Begrenzung stammt urspr¨ nglich daher, dass der Aufruf shm open
u
nur 32-Bit Dateien erstellen kann. Allerdings k¨nnen auch mehrere Dateien
o
im tmpfs erstellt und parallel eingeblendet werden. Mittlerweile ist diese
Beschr¨nkung allerdings auch sinnvoll, um die Erweiterungsschritte beim
a
Vergr¨ßern des Extended Memory auf 32-Bit Systemen nicht allzu groß
o
ausfallen zu lassen.
Bei 64-Bit Systemen ist diese Begrenzung im ZAMM nicht mehr vorhan-
den, hier wird der gesamte errechnete Initialwert beim Starten des Appli-
kationsservers, ggf. verteilt uber mehrere Dateien, im tmpfs angelegt.
¨
• Der Parameter em/max size MB wird so eingestellt, dass er den durch die
Angabe von PHYS MEMSIZE berechneten Prozentsatz des tmpfs einnimmt.
Als Sicherheit werden einige MegaByte abgezogen.

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 143
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
• Auch der Parameter rdisp/PG SHM wird in Abh¨ngigkeit von dem f¨r die
a u c u -tr a c k

Instanz verf¨gbaren Speicher auf Werte zwischen 1024 (8 MB) und 8192
u
(64 MB) eingestellt.
• Gleiches gilt auch f¨r den Parameter rdisp/ROLL SHM: Dieser erh¨lt je
u a
nach verf¨gbarer Speichermenge Werte zwischen 1024 (8 MB) und 16384
u
(128 MB) zugewiesen.
• Die Parameter rdisp/PG MAXFS und rdisp/ROLL MAXFS werden fest auf
einen Wert von 32768 (256 MB) eingestellt.
• Der Parameter ztta/roll area wird fest auf einen Wert von 3 500 000
(3,5 MB) eingestellt
• Der Parameter ztta/roll first wird fest auf den Wert 1 eingestellt. Da-
mit wird der Workprozess nur den unbedingt notwendigen Speicher im
Rollbereich anfordern, der wenige hundert KiloByte umfasst, und ansch-
ließend sofort Extended Memory verwenden.
• Der Parameter ztta/roll extension wird auf 4 000 000 000 einge-
stellt, womit zumindest auf 32 Bit Systemen em/address space MB der
beschr¨nkende Parameter des Extended Memory pro Userkontext ist.
a
• Der Parameter em/block size KB wird je nach verf¨gbarem SAP Exten-
u

x
ded Memory f¨r die Instanz (vgl. em/max size MB) und der verf¨gbaren
u u
Anzahl an ES-Bl¨cken auf ein Vielfaches von 1024 (1 MB) eingestellt.
o
Le
Das Zero Administration Memory Management auf 64-Bit Plattformen
verh¨lt sich seit kurzer Zeit ahnlich wie die bereits f¨r 32-Bit beschriebene
a ¨ u
Implementierung. Allerdings weichen hier die Werte aufgrund des vergr¨ßerten
o
pp

Adressraums doch teilweise stark ab. Daher gehen wir im Folgenden noch
einmal detailiert auf die Implementierung f¨r die 64-Bit Plattform ein:
u

• Der Parameter em/initial size MB erh¨lt den Wert von PHYS MEMSIZE.
a
sU

Dadurch wird dem Parameter der absoluten Wert von PHYS MEMSIZE zuge-
wiesen, mit dessen Gr¨ße die erste der SAP ES-Dateien im tmpfs angelegt
o
wird. Eine Beschr¨nkung des Maximalwerts ist nicht vorhanden. Dennoch
a
werden aufgrund der Beschr¨nkungen von shm open derzeit immer noch
a
mehrere SAP ES-Dateien mit jeweils 2047 MB angelegt.
• Der Parameter em/max size MB wird unver¨ndert so eingestellt, dass er
a
den durch die Angabe von PHYS MEMSIZE berechneten Prozentsatz des
tmpfs einnimmt. Als Sicherheit werden einige MegaByte abgezogen.
• Auch der Parameter rdisp/PG SHM wird in Abh¨ngigkeit vom f¨r die In-
a u
stanz verf¨gbaren Speicher auf Werte zwischen 32768 (256 MB) und 65536
u
(512 MB) eingestellt.
• Gleiches gilt auch f¨r den Parameter rdisp/ROLL SHM: Dieser erh¨lt je
u a
nach verf¨gbarer Speichermenge Werte zwischen 32768 (256 MB) und
u
131072 (1024 MB) zugewiesen.
• Die Parameter rdisp/PG MAXFS und rdisp/ROLL MAXFS werden fest auf
einen Wert von 131072 (1024 MB) eingestellt.
• Der Parameter ztta/roll area wird fest auf einen Wert von 6 500 000
(6,5 MB) eingestellt.

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
• Der Parameter ztta/roll first wird unver¨ndert fest auf den Wert 1
a c u -tr a c k

eingestellt.
• Der Parameter ztta/roll extension wird fest auf den Wert 4 000 000 000
gesetzt, so dass auch f¨ r speicherhungrige Benutzerkontexte ausreichend
u
Extended Memory zur Verf¨gung gestellt wird.
u
• Der Parameter em/block size KB wird je nach verf¨gbarem SAP Exten-
u
ded Memory f¨r die Instanz (vgl. em/max size MB) auf ein Vielfaches von
u
1024 (1 MB), mindestens jedoch 4096 (4 MB) eingestellt.
Zu beachten ist, dass der Parameter em/address space MB der das Adres-
sfenster im Workprozess bestimmt, in welches Extended Memory eingeblendet
wird, nicht vom Zero Administration Memory Management beeinflusst wird.
Hier ist demnach der statische Kerneldefault aktiv, falls er nicht manuell im
Instanzprofil ubersteuert wird. Auf 32 Bit Plattformen liegt er derzeit bei
¨
einem Wert von 512 MB, auf 64 Bit Plattformen bei 4096 MB.
Auf 32 Bit Systemen ist eine Vergr¨ßerung des Parameters oftmals ri-
o
sikobehaftet, da er mit den anderen SAP Shared Memory Bereichen, wie
den SAP Puffern, um den oft schon zu knapp bemessenen verwendbaren

x
Adressraum konkurriert. Wird jedoch ein 64 Bit System eingesetzt, spricht
derzeit nichts gegen eine Anpassung des Parameters, falls gr¨ßere Benut-
o
zerkontexte es erfordern. Wird eine Vergr¨ßerung vorgenommen, sollte auch
o
Le
ztta/roll extension entsprechend angepasst werden.
Zur Verdeutlichung geben wir zum Abschluss in Tabelle 3.1 noch vier Bei-
spielkonfigurationen an, wie sie in aktuellen SAP-Releases (Release 6.40) vom
ZAMM berechnet werden. Wir gehen dabei von einem Linux-Applikationsser-
pp

ver mit 8 GB Hauptspeicher, dementsprechend 16 GB Swap und einem
tmpfs von 18 GB (75% von RAM und Swap) aus. Mit dieser Ausstattung
ergeben sich bei den jeweiligen Setzungen von PHYS MEMSIZE die in der Ta-
belle 3.1 gezeigten Parametereinstellungen.
sU

Diskussion der beiden Verfahren

Bei der Beschreibung der beiden Ans¨tze zur Speicherverwaltung auf der
a
Linux-Plattform wurde deutlich, dass die map-Implementierung urspr¨nglich
u
aus der Not eines kleinen virtuellen Adressraums und zunehmend gr¨ßerer o
¨
User-Kontexte geboren wurde. Mit dem Ubergang zu 64-Bit-Systemen f¨llt a
diese Notlage aber nun weg, s. Abschnitt 3.3.4, so dass hier sehr wohl die
Verwendung der std-Variante denkbar ist. Somit stellt sich auf einer wach-
senden Zahl von Plattformen die Frage, welche Implementierungsvariante nun
gew¨hlt werden sollte oder gar, ob die map-Implementierung uberhaupt wei-
a ¨
ter unterst¨tzt werden soll. Schließlich geht Linux mit dieser Form einen Weg,
u
der von dem der anderen Unixe abweicht, die ublicherweise nur die std-Form
¨
kennen.
Hier muss angemerkt werden, dass Systeme mit relativ kleinem virtuellen
Adressraum auch in den n¨chsten Jahren noch produktiv eingesetzt werden.
a
F¨r diese ist die map-Implementierung die einzige gangbare Alternative, s.
u

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 145
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
Tabelle 3.1. Beispielparametrisierungen durch das Zero Administration Memory
Management von SAP auf Linux

Parametername Beispiel 1 (32 Bit) Beispiel 2 (32 Bit) Beispiel 3 (32 Bit) Beispiel 4 (64 Bit)

PHYS MEMSIZE 100% 30% 6000 100%

em/initial size MB 2040 MB 2040 MB 2040 MB 8192 MB
em/max size MB 18422 MB 5529 MB 14008 MB 18422 MB
em/address space MB 512 MB 512 MB 512 MB 4096 MB
em/block size KB 4096 4096 4096 4096
rdisp/ROLL MAXFS 32768 (256 MB) 32768 (256 MB) 32768 (256 MB) 131072 (1024 MB)
rdisp/ROLL SHM 16384 (128 MB) 16384 (128 MB) 16384 (128 MB) 131072 (1024 MB)
rdisp/PG MAXFS 32768 (256 MB) 32768 (256 MB) 32768 (256 MB) 131072 (1024 MB)
rdisp/PG SHM 8192 (64 MB) 8192 (64 MB) 8192 (64 MB) 65546 (512 MB)
ztta/roll area 3 500 000 3 500 000 3 500 000 6 500 000
ztta/roll first 1 Byte 1 Byte 1 Byte 1 Byte
ztta/roll extension 4 000 000 000 4 000 000 000 4 000 000 000 4 000 000 000

x
Abschnitt 3.3.3. Es ist damit auch zu erwarten, dass die beiden Implementie-
rungen aus diesem Grunde weiterhin parallel existieren werden.
Le
Aus technischer Sicht stellen sich die beiden Varianten als wesentlich
gleichwertig dar. Es sind bis jetzt keine signifikanten Unterschiede in der Per-
formance sichtbar geworden, die eine eindeutige Entscheidung f¨r die eine
u
oder andere Variante nahelegen.
pp

Die Koexistenz der beiden Ans¨tze erm¨glicht hingegen einen vergleichs-
a o
¨
weisen bequemen Ubergang von anderen Plattformen auf ein Linux-basiertes
SAP-System. Bei einer Migration von einem klassischen Unix auf ein (64-
Bit) Linux-System kann die bekannte std-Form weiterhin genutzt werden.
sU

War hingegen Windows die Quellplattform, sollten sich die Administratoren
schnell mit der gewohnten map-implementierung auch auf Linux zurechtfinden.
Die Tabelle A.2 im Anhang A.1 gibt eine Zusammenfassung der relevan-
ten Parameter der Speicherverwaltung und ihrer Bedeutung in den beiden
Varianten.

3.2.4 Exkurs SAP Web Application Server Java

Mit dem SAP Web Application Server Java erweitert SAP die Menge der
Programmiersprachen, die f¨r die Entwicklung von Gesch¨ftsanwendungen
u a
zur Verf¨gung stehen, um die Sprache Java. SAP kommt damit einem hüfig
u a
geüßerten Wunsch entgegen. In mancher Hinsicht ahneln sich die Sprachen
a ¨
ABAP und Java stark:
• Beide ben¨tigen eine Laufzeitumgebung, um ausgef¨hrt zu werden. Im
o u
ABAP-Fall ist das der SAP ABAP-Applikationsserver und bei Java die
Java Virtual Machine (JVM). Beide stellen eine weitere Abstrakti-
onsschicht zwischen dem Anwendungsprogramm und dem Betriebssystem

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
bereit, so dass Java-Anwendungen in den weitaus meisten F¨llen keine
a
Abh¨ngigkeiten von einem konkreten Betriebssystem besitzen. Ausnah-
a
men treten nur dann auf, wenn explizit spezielle Funktionen der zugrun-
deliegenden Betriebssystemplattform verwendet werden. Dazu z¨hlen z.B.
a
in Java Aufrufe uber das Java Native Interface (JNI).
¨
• Beide sind zudem eingebettet in eine Infrastruktur, die weitere Dienste be-
reitstellt. Bei ABAP wird dies ebenfalls durch den SAP-Applikationsserver
geleistet. Wesentliche Bestandteile dieser Infrastruktur, wie Enqueue und
Verbucher, wurden auf S. 67 vorgestellt. Im Java-Umfeld nimmt diese Rolle
ein J2EE-Server ein.
Die beiden wesentlichen Bestandteile einer im SAP-System einsetzbaren Java-
Umgebung sind also zum einen die JVM und zum anderen der J2EE-Server.
F¨r die erste Komponente setzt SAP derzeit auf Linux die Standard-JVMs
u
von IBM und SUN ein. Es ist allerdings geplant, eine eigene SAP-JVM zu
implementieren, die den besonderen Anspr¨chen der SAP-Umgebung besser
u
gerecht wird und st¨rker integriert werden kann. Auf der Ebene des J2EE-
a
Servers verwendet die SAP die eigene J2EE-Engine, s. Abschnitt 2.3.1.

x
Auf die Abl¨ufe in einem J2EE-Server gehen wir an dieser Stelle nicht
a
weiter ein, da sie durch die zugrundeliegende JVM vom Betriebssystem weit-
gehend unabh¨ngig und damit f¨r das Thema dieses Buches nicht zentral
a u
Le
sind. Anders liegt der Fall bei JVM selbst. Hier existieren durchaus Einstel-
lungen, die speziell f¨r die Linux-Plattform sind. Im Weiteren gehen wir etwas
u
genauer auf diese Eigenschaften und Einstellungen der als HotSpot bezeich-
pp

neten SUN Java Virtual Machine ein. JVMs anderer Hersteller weisen ein
strukturell ahnliches Verhalten auf, auch wenn die Namen der Parameter ggf.
¨
etwas abweichen k¨nnen.
o
Die erste Option beim Aufruf einer SUN JVM w¨hlt das zu verwendende
a
sU

Verhaltensmuster. Eine SUN JVM unterscheidet hier zwischen zwei Einstel-
lungen:
• Anwendungen, bei denen kleine Speicheranforderungen, d.h. ein schmaler
Footprint, und eine schnelle Startzeit wichtig sind, sollten mit der Option
-client gestartet werden.
• Anwendungen, bei denen das Hauptaugenmerk auf Leistung liegt, sollten
mit -server gestartet werden. Dies gilt f¨ r nahezu alle Anwendungen in
u
SAP-Umgebungen.
Standardm¨ßig ist die Option -client voreingestellt, so dass -server explizit
a
gesetzt werden muss.
Bei der weiteren Parametrisierung der JVM ist zu beachten, dass es ver-
schiedene Parameterklassen gibt:
• Standard-Optionen sind durch die Speziﬁkation der JVM, genauer des
Java Application Launcher, vorgegeben und werden auch in zuk¨nfti-
u
gen Releases der JVM vorhanden sein. Zu diesen Optionen geh¨ren
o
die oben beschriebene Vorgabe des Verhaltensmusters, die Angabe

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 147
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
des Classpaths uber -cp und das Setzen von Systemeigenschaften durch
¨
-D<name>=<wert>.
• Parameter der Form -X<nnn> sind dagegen nicht durch die Spezifikation
einer JVM standardisiert und m¨ssen deshalb nicht in jeder Java Virtual
u
Machine vorhanden sein. Auch die Bedeutung muss nicht in allen JVM die
¨
gleiche sein. Eine Ubersicht uber diese Parameter einer gegebenen JVM
¨
wird durch den Aufruf java -X auf der Kommandozeile ausgegeben.
• Noch spezieller sind die Parameter der Form -XX:<nnn>. Sie sind gleichfalls
spezifisch f¨r eine JVM, setzen aber gewissen Eigenschaften des zugrunde-
u
liegenden Betriebssystems oder besondere Rechte des Anwenders voraus.
Eine Liste der unterst¨tzten -XX:-Parameter kann leider nicht uber die
u ¨
Kommandozeile ausgegeben werden; sie sind der jeweiligen JVM Doku-
mentation zu entnehmen.
Ein Aufruf eines Java-Programms, der die oben genannten Parametertypen
verwendet, k¨nnte damit die folgende Gestalt haben:
o
java -server -cp ˜/java/classes -Xms192m

x -XX:NewSize=32m <class>
Die Bedeutung der verwendeten Parameter -Xms192m und -XX:NewSize=32m
Le
kl¨ren wir im n¨chsten Abschnitt, wo einige der wichtigeren Einstellungen f¨r
a a u
das Java-Speichermanagement vorgestellt werden.
pp
sU

Abb. 3.9. SAP J2EE Engine Config Tool

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
Im SAP-Umfeld geschieht die Konfiguration typischerweise mittels des
SAP J2EE Config Tools. In dieser Anwendung (Abb. 3.9) k¨nnen nichto
nur Parameter der Speicherverwaltung eingestellt werden, sondern auch die
Anzahl der Serverprozesse etc. Unter [40] finden sich weiterf¨hrende Informa-
u
tionen.

Java Speicherverwaltung

Die Speicherverwaltung von Java ist durch zwei Designentscheidungen domi-
niert:
1. Zun¨chst ist Java konzipiert als eine Objekt-orientierte Sprache, die den
a
Entwickler weitgehend von der Notwendigkeit entbindet, den Lebenszy-
klus der Objekte selbst zu verwalten. Insbesondere bedeutet dies, dass
Java im Gegensatz etwa zu C++ keine explizite Destruktion von Objek-
ten unterst¨tzt.
u
2. Auf der anderen Seite verwendet Java als Speicherbereich f¨ r die Objekte
u
nur einen Heap-¨hnlichen Speicherbereich in der JVM. Diesem Heap ist
a

x
die besondere Eigenschaft zu eigen, dass Allokierungen in ihm unter der
Kontrolle des allokierenden Programms und des unten beschriebene Gar-
Le
bage Collectors sind und das Betriebssystem oder die Systemumgebung
keinen Einfluss darauf nehmen.
Aus Sicht der Speicherausnutzung ist die Verwendung des Java-Heaps
vor allem auf 32-Bit-Systemen mit ihren Adressraum-Restriktionen inter-
pp

essant, s. Kap. 3.3.3. In den meisten F¨llen ben¨tigen die JVMs einen
a o
zusammenh¨ngenden Adressraum f¨r den Java-Heap. Probleme wie die
a u
Fragmentierung des Adressraums durch Shared Libraries spielen deshalb
auch im Java Umfeld eine Rolle.
sU

Aus diesen beiden Tatsachen folgt zun¨chst, dass Java die Objekte, die im
a
Heap angelegt sind, nur uber Referenzen anspricht. Wenn keine Referenz
¨
mehr auf ein Objekt verweist, steht es dem Java-Programm nicht mehr zur
Verf¨gung und wird deshalb als Garbage (Datenm¨ll) bezeichnet. Aus der
u u
ersten der oben genannten Entscheidungen folgt dann weiterhin, dass die JVM
Mechanismen implementieren muss, die den Heap absuchen und Garbage
verwerfen, um so nicht mehr benutzten Speicherplatz wiederverwenden zu
k¨nnen. Diese Verfahren sind als Garbage Collector bekannt. Sie sind zen-
o
tral f¨r die Speicherverwaltung von Java und k¨nnen massive Auswirkungen
u o
auf die Performance von Java-Anwendungen haben.
Die einfachste Form eines Garbage Collectors sucht alle vorhandenen Ob-
jekte ab und gibt den Speicherplatz der nicht mehr verwendeten frei. In großen
Anwendungen ist dieser brute force Ansatz nicht mehr praktikabel. Deshalb
verwenden alle heute in der Praxis eingesetzten Garbage Collectoren Heuri-
stiken, um das Auffinden von wiederverwendbarem Speicherplatz zu vereinfa-
chen. Diese Heuristiken sind durch Parameter beeinflussbar. F¨r die Sun JVM
u
1.4.2, die zum Zeitpunkt des Schreibens die aktuelle JVM im SAP Umfeld ist,

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
u 149
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c

Abb. 3.10. Standardm¨ßige Anordnung der Java VM Generations
a

skizzieren wir die Konzepte und wichtigsten Parameter des prim¨ren Garbage
a
Collectors, s. [38, 39]. F¨ r die konkreten Werte, die diese Parameter im SAP-
u

x
Umfeld annehmen sollten, verweisen wir auf die Installationsleitf¨den und die
a
Hinweise der SAP. Einige Linux-Besonderheiten deuten wir im Abschnitt 3.3.2
an.
Le
Der Garbage Collector der Sun JVM basiert auf der zentralen Beobach-
tung, dass die weitaus gr¨ßte Menge der neu erzeugten Objekte sehr schnell
o
stirbt. Die Objekte, typischerweise sind es nur ca. 2%, die alter werden,
¨
pp

uberdauern dann auch nicht selten die gesamte Lebenszeit des Programms.
¨
Ein effizienter Garbage Collector kann nun diese unterschiedlichen Verhal-
tensweisen ber¨cksichtigen. Mit der Sun JVM Version 1.2 wurde deshalb das
u
Konzept einer Generation eingef¨hrt, das Objekte einer ahnlichen Alters-
u ¨
stufe zusammenfasst. Der verf¨ gbare Speicher wird damit in Bereiche auf-
u
sU

geteilt, die einer Generation von Objekten zugeordnet sind. Neue Objekte
werden beispielsweise in der Young Generation angelegt. Wenn sie einige
Lüfe des Garbage Collectors, auch Collections genannt, uberstanden ha-
a ¨
ben, gelangen sie in die best¨ndigere Tenured Generation. Ein spezieller
a
Teil dieser alten Generation ist die sogenannte Permanent Generation, in
der Daten der JVM selbst gelagert werden. Dazu z¨hlen Objekte vom Typ
a
Class, etc. Abbildung 3.10 zeigt die Anordnung der verschiedenen Generatio-
nen im Adressraum der JVM.
Daraus ist ersichtlich, dass die Einteilung in der Praxis noch etwas feiner
als ist, als gerade angedeutet wurde. So besteht der Bereich der Young Gene-
ration aus einem Eden genannten Abschnitt, in dem Objekte initial angelegt
¨
werden, und aus zwei Survivor-Abschnitten. Ahnliche Abschnitte finden sich
auch in der Tenured und der Permanent Generation.
Die haupts¨chliche Bedeutung dieser Unterteilung liegt nun darin, dass
a
in jeder Generation ein anderes Verfahren zur Garbage Collection eingesetzt
werden kann, wenn der Platz in dieser Generation zu knapp wird. Im Be-
reich der Young Generation werden beispielsweise bei einem Lauf des Gar-

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
bage Collectors nur die noch aktiven und nicht mehr alle Objekte in einen der
Survivor-Bereiche kopiert. Da zudem auch die aktiven Objekte des anderen
Survivor-Bereichs in diesen Bereich kopiert werden, ist immer ein Survivor-
Bereich belegt und einer frei. Wenn Objekte einige dieser Kopiervorg¨nge, die
a
sogenannten Minor Collections, hinter sich haben, gelangen sie schließlich
in den Bereich der Tenured Generation.
Wenn die Tenured Generation voll belegt ist, beginnt auch hier ein Lauf
des Garbage Collectors, der nun als Major Collection bezeichnet wird. Er
verwendet statt des Kopier-Verfahrens andere Ans¨tze und muss dann alle
a
aktiven Objekte des Adressraums uberpr¨fen. Diese Major Collection ist es,
¨ u
die durch den Aufruf System.gc() im Java-Code explizit angestoßen werden
kann.
F¨r das Laufzeitverhalten der großen und kleinen Collection und da-
u
mit f¨r den gesamten Vorgang sind nun die Gr¨ßen der jeweiligen Berei-
u o
che wichtig. Die Angaben der Gr¨ßen geschehen uber die oben beschrie-
o ¨
benen -X<nnn> und -XX:<nnn> Parameter. So wird die initiale Gr¨ße des o
grundlegenden Heaps durch den Parameter -Xms<initial> gegeben und die
maximal erlaubte Gr¨ße des Heaps durch -Xmx<maximum>. Innerhalb dieser
o
x
Grenzen kann der aktuell verwendete Heap schwanken, da die JVM bei jeder
Garbage Collection den Heap-Bedarf anpasst, um innerhalb eines vorgege-
Le
benen Intervalls zu bleiben. Dieses Intervall wird durch das Verh¨ltnis von
a
freiem Speicher zu gerade aktiven Objekte bestimmt. Die Untergrenze gibt
der Parameter -XX:MinHeapFreeRatio=<minimum> an und die Obergrenze
-XX:MaxHeapFreeRatio=<maximum>. Ein typisches Beispiel f¨r eine notwen-
u
pp

dige Setzung der gerade genannten Parameter ist die initiale Gr¨ße des Heaps.
o
Die normalerweise defaultm¨ßige Setzung von 64 MB ist f¨r Serveranwendun-
a u
gen viel zu klein. Hier werden im SAP-Umfeld deutlich gr¨ßere Werte empfoh-
o
len, um hüfige Vergr¨ßerungen des Heaps zu vermeiden, da diese insbesondere
a o
sU

den Startvorgang von Serveranwendungen merklich verlangsamen.
Ein zweiter Bereich, in dem mitunter eine explizite Setzung notwendig
ist, betrifft das Verh¨ltnis der Young zur Tenured Generation. Je gr¨ßer die
a o
Young Generation ist, desto seltener m¨ssen die Minor Collections ablau-
u
fen. Auf der anderen Seite nimmt damit aber auch der verf¨gbare Platz
u
f¨r die Tenured Generation ab. Standardm¨ßig wird die initiale Gr¨ße der
u a o
Young Generation durch den Parameter -XX:NewRatio kontrolliert, der das
Verh¨ltnis zwischen Young und Tenured Generation bestimmt. Wird beispiels-
a
weise -XX:NewRatio=3 konfiguriert, bedeutet dies, dass die Gr¨ße der Young
o
Generation ein Verh¨ltnis von 1:3 zur Tenured Generation haben soll – oder
a
anders gesagt, die Young Generation 1/4 der Gr¨ße der Tenured Generation
o
in Anspruch nehmen soll.
Die folgende Tabelle 3.2 gibt eine Zusammenstellung einiger wichtiger Pa-
rameter zur Konfiguration der JVM.
Als Einheit akzeptieren alle hier genannten Parameter die Abk¨rzungen k
u
oder K f¨r KiloByte, m oder M f¨r MegaByte, bzw. g oder G f¨r GigaByte. Die
u u u
Einstellung -Xmx512m stellt dem Heap der JVM damit maximal 512 MegaByte

PD PD

!

!
W

W
O

O
N

N
y

y
bu

bu
3.3 Tipps und Tricks 151
to

to
k

k
lic

lic
C

C
w

w
m

m
w w
w

w
o

o
.d o .c .d o .c
Tabelle 3.2. Wichtige Parameter f¨ r die Speicherkonﬁguration der Java Virtual
u
Machine

Parametername Bedeutung

-Xms<n> initiale Gr¨ße des Java Heaps
o
-Xmx<n> maximale Gr¨ße des Java Heaps, bis zu der die Virtual
o
Machine erweitern kann
-Xss<n> Gr¨ße des Stacks eines Java Threads
o
-XX:NewSize<n> initiale Gr¨ße der Young Generation
o
-XX:MaxNewSize<n> maximale Gr¨ße der Young Generation
o
-XX:MaxPermSize<n> maximale Gr¨ße der Permanent Generation
o

zur Verf¨gung. Die konkreten Werte h¨ngen dabei von der gew¨hlten JVM ab.
u a a
Da sie sich, wie oben beschrieben, mit der Version und sogar dem Build der
JVM andern k¨nnen, sehen wir hier von der Angabe konkreter Zahlenwerte
¨ o
ab und verweisen auf die Hinweise von SAP.

x
Le
3.3 Tipps und Tricks

Im dritten großen Abschnitt dieses Kapitels k¨nnen wir davon ausgehen, dass
o
pp

die Grundlagen der Speicherverwaltung, wie sie in den ersten beiden Abschnit-
ten 3.1 und 3.2 beschrieben wurden, bekannt sind. Wir wenden uns deshalb
nun einigen der Fragen und Problemen zu, die im Umfeld der Speicherver-
waltung auftreten. Dabei folgen wir wieder dem bekannten Muster, indem
wir zun¨chst die verf¨gbaren Werkzeuge beschreiben und dann auf spezielle
a u
sU

Fragestellungen eingehen.

3.3.1 Werkzeuge zur Analyse von Speicherproblemen auf Linux

Zur Analyse von Speicherproblemen stehen dem Administrator eine Vielzahl
von Werkzeugen zur Verf¨gung, die allerdings nicht immer intuitiv zu bedie-
u
nen sind. Beispielhaft werden im Folgenden einige wichtige Transaktionen im
SAP-System und Werkzeuge auf Betriebssystemebene n¨her betrachtet.
a

Werkzeuge im SAP-System

An zentraler Stelle bei der Untersuchung der Speicherverwaltung steht im
SAP-System sicher die Transaktion ST02. Sie gibt in ihrem Einstiegsbild-
schirm zun¨chst detaillierte Auskunft uber die vorhandenen Speicherbereiche
a ¨
im SAP-System und deren Eigenschaften, s. Abb. 3.11. Zu den vermittelten
Informationen geh¨ren
o

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
pp

Abb. 3.11. Einstiegsbild der Transaktion ST02
sU

• Angaben uber die Gr¨ße und Verwendung der SAP-Buffer, zu denen un-
¨ o
ter anderem die Nametab geh¨rt, die die Metainformationen uber die
o ¨
Tabellen im SAP-System enth¨lt, die Tabellenpuffer, die die Daten der
a
Tabellen zwischenspeichern, und der Programmpuffer PXA. Eine ge-
nauere Beschreibung der einzelnen Puffer finden Sie in [34].
• Angaben uber die Gr¨ße und Verwendung des hier als SAP Memory be-
¨ o
zeichneten benutzerspezifischen Speichers, der Thema der in den ersten
beiden Abschnitten dieses Kapitels dargestellt wurde.
• Daten uber die Gr¨ße des SAP Cursor Cache und die Zugriffe auf die
¨ o
verschiedenen Arten des Tabellenpuffers.

Von diesen Angaben sind insbesondere die Stellen relevant, an denen die
Trefferquote und der Freiplatz von Nametab, Tabellenpuffer und PXA an-
gezeigt werden. Beim SAP-Memory wird hüfig das Verh¨ltnis von Max. Use
a a
zu In Memory f¨r das Extended Memory herangezogen. Speziell im Standard-
u
Verfahren deuten dabei ahnlich große Werte auf eine Speicherknappheit hin.
¨

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
Zu beachten ist jedoch, dass in der Zeile Extended Memory immer Bezug
auf die Gr¨ße des verf¨gbaren Extended Memory genommen wird, daher
o u
aus historischen Gr¨nden auf den Wert des Parameters em/initial size MB.
u
Bei der Standard-Implementierung kann dieser Bereich zur Laufzeit nicht
vergr¨ßert werden, so dass hohe F¨llgrade auf evtl. bevorstehende Speiche-
o u
rengp¨sse hindeuten. Im neuen Speichermanagement gibt dieser Wert jedoch
a
nur die Summe der gerade im tmpfs angelegten Dateien an, die, wie auf S. 138
beschrieben, bei Bedarf automatisch vom SAP Server erweitert werden. F¨r u
fundierte Erfahrungswerte verweisen wir auf [34] und die Empfehlungen des
SAP Supports. Eine Hilfe kann in gewissen Situationen auch [42] bieten.
Im Detail Analysis Menu der Transaktion ST02 kann dann in die ge-
nauere Untersuchung einzelner Teilbereiche der Speicherverwaltung eingestie-
gen werden. Hier sind vor allem zwei Unterpunkte zu nennen. Zun¨chst zeigt
a
die Wahl SAP Memory Kenngr¨ßen der schon mehrfach besprochenen SAP-
o
Speicherbereiche Roll, Page, Extended Memory und Heap an (Abb. 3.12). In

x
Le
pp
sU

Abb. 3.12. Transaktion ST02: SAP Memory

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
pp

Abb. 3.13. Transaktion ST02: Storage
sU

¨
vielen F¨llen erweist sich zudem die Mode List als sehr hilfreich. Uber sie kann
a
die Verteilung des Speicherverbrauchs auf die einzelnen SAP-User bestimmt
werden. Zur Identifikation von besonders großen Speicheranforderungen ist
die Mode List unentbehrlich.
Eine zweite wichtige Informationsquelle ist der Unterpunkt Storage im
Detail Menu. Abbildung 3.13 zeigt den Gesamtverbrauch des SAP-Appli-
kationsservers in den einzelnen Bereichen Puffer, User-spezifischer Speicher
und Heap an. Eine Absch¨tzung des notwendigen Bedarfs an physischem
a
Hauptspeicher beruht hüfig auf den hier gefundenen Angaben. Zudem muss
a
die Summe aus den drei genannten Speicherbereichen zum verf¨gbaren vir-
u
tuellen Speicher passen. In einem System mit dem neuen Speichermana-
gement heißt das konkret, dass die Summe aller Puffer plus die Gr¨ße o
des Parameters em/address space MB plus der erlaubte Heap (Parameter
abap/heap area (non)dia) kleiner als der allokierbare virtuelle Speicher sein
muss.

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

x
Le
pp

Abb. 3.14. Transaktion ST02: Storage Technical
sU

Zu beachten ist hier wiederum, dass Size of Extended Memory bei Ver-
wendung des Neuen Speichermanagements nur die Gr¨ße der Dateien im
o
tmpfs angibt, so dass zumindest auf 32 Bit Plattformen im Normalfall nicht
davon ausgegangen werden darf, dass dieser Bereich etwa von einem einzelnen
User komplett angefordert werden kann.
Eine Br¨cke zu den Angaben des Betriebssystems schl¨gt dann der techni-
u a
sche Blick auf die Speicherbereiche des SAP-Applikationsservers. In Abb. 3.14
wird der Unterpunkt Shared Memory Technical gezeigt, der schon auf S. 83
kurz angesprochen wurde. Die Liste zeigt die Shared Memory Bereiche, die der
SAP-Applikationsserver allokiert hat. In der Spalte Key wird der SAP-interne
Schl¨ssel gezeigt, die Spalte Address gibt den Ort im virtuellen Adressraum
u
an, an dem der Bereich eingeblendet ist, und die Spalte OsKey zeigt die Um-
rechnung des SAP-Keys in den Key, den das Betriebssystem f¨ r sein shmget()
u
ben¨tigt (S. 83). In einigen neueren Releases ist diese Anzeige allerdings nicht
o
ganz vollst¨ndig. Unter [43] werden die zur Vervollst¨ndigung notwendigen
a 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
Anpassungen beschrieben. Das Handle enth¨lt schließlich die SHM-Id, die
a
shmget() zur¨ckgibt, und die Spalte Att die Anzahl der (Work-) Prozesse,
u
die dieses SHM-Segment eingeh¨ngt haben. Wir zeigen weiter unten, wie sich
a
diese Situation mittels Betriebssystemwerkzeugen darstellt.
Eine Erg¨nzung zu den Daten der Transaktion ST02 kann die Transak-
a
tion SM04 bieten. Sie zeigt im Springen | Memory-Zweig den benutzerspe-
zifischen Speicherverbrauch und gibt damit ahnliche Informationen wie die
¨
Mode List. Diese Werte werden mitunter herangezogen, um den Unterschied
zwischen dem gesamten aktuell belegten Platz, dem Wert unter Extended
Memory: Current Use im Einstiegsbild der ST02, und dem von User faktisch
verwendeten zu bestimmen.
Eine zunehmend wichtiger werdende Information wird derzeit allerdings
durch keine der beiden gerade genannten Transaktionen geliefert: Schon mehr-
fach wurde auf die Global Area im Extended Memory hingewiesen (S. 136).
Der F¨llgrad dieses Speicherbereichs kann derzeit nur durch den Report
u
RSMEMORY angezeigt werden. Der Unterpunkt EG ¨bersicht zeigt die gesamte,
U
aktuell genutzte und maximal genutzte Gr¨ße der Global Area an.
o
Um den Auslastungsgrad von abap/shared objects size MB zu ermit-
x
teln, dessen Bereich ebensfalls im Extended Memory liegt und nicht dem ein-
zelnen Benutzer f¨r normale Speicheranforderungen zug¨nglich ist, gibt es
u a
Le
ab SAP Kernel 6.40 die Transaktion SHMM, die uberpr¨ft, wieviel Speicher in
¨ u
diesem Bereich belegt und wieviel derzeit noch frei ist.
Die letzte Transaktion, der wir uns an dieser Stelle zuwenden, liegt an der
Grenze des SAP-Applikationsservers zum Betriebssystem. Die Transaktion
pp

ST06 bezieht den Großteil ihrer Daten vom saposcol (S. 73). Der saposcol
wiederum geht wie nahezu alle Monitoring-Werkzeuge unter Linux vor und
liest die ben¨tigten Daten aus Dateien des /proc-Dateisystem aus. Die Daten,
o
die die Transaktion ST06 anzeigt, beinhalten deshalb nicht mehr Informatio-
sU

nen als auch uber die weiter unten genannten Werkzeuge gewonnen werden
¨
k¨nnen. Die Transaktion f¨hrt aber im Gegensatz zu den einfachen Diagnose-
o u
Werkzeugen auf Kommandozeilenebene eine Historie und kann deshalb bei
der Analyse von Problemen hilfreich sein. Auch wird kein Shell-Zugang zu
einem SAP-System ben¨tigt, um Betriebssystemdaten lesen zu k¨nnen. Auch
o o
wenn das unter technischen Gesichtspunkten auf der Linux-Plattform kein
Problem darstellt, vereinfacht diese Tatsache doch mitunter die Verwaltung
einer Systemlandschaft.

Werkzeuge auf Betriebssystemebene

Die Werkzeuge zur Untersuchung der Speicherverwaltung, die wir im Folgen-
den vorstellen, geh¨ren zu einfachen Kommadozeilen-Befehlen, die auf jeder
o
Linux-Plattform zur Verf¨gung stehen sollten. Gerade im Umfeld des System
u
Monitorings sind in den letzten Jahren unter Linux große Fortschritte gemacht
worden. Da es sich aber hüfig um propriet¨re Software handelt, vermeiden
a a
wir an dieser Stelle einen Exkurs in dieses umfangreiche Gebiet.

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
Den Anfang macht allerdings ein Programm, das zum Auslieferungsum-
fang der SAP geh¨rt und der Vollst¨ndigkeit halber erw¨hnt werden sollte:
o a a
Das Programm sappfpar dient dem Test von SAP Profilparametern. Mittels
des Aufrufs
sappfpar check pf=/usr/sap/<SID>/SYS/profile/<Profile>
kann eine einfache Konsistenzpr¨fung der Profilparameter im angegebenen
u
Profil gestartet werden. Diese Aktion hat sich vor allem bei einer Installation
¨
oder bei gr¨ßeren Anderungen an den Profilparametern als sinnvoll herausge-
o
stellt.
¨
Gerade bei Anderungen an adressraumrelevanten Parametern auf 32-Bit
Systemen kann mittels sappfpar bereits vor dem Aktivieren des Profils im
SAP Applikationsserver besser abgesch¨tzt werden, ob die neuen Werte zu
a
einem lauff¨higen System f¨hren. Hier ist insbesondere der Wert von Shared
a u
Memory interessant, da er die Summe der mit diesem Profil konfigurierten
SAP-Puffer aufaddiert. Ein analoger Test kann auch uber die Transaktion
¨
ST10 vorgenommen werden.
F¨r die Ansicht der allokierten Speicherbereiche stellt SAP das Programm
u
a ¨
x
showipc bereit. Es erh¨lt ublicherweise die Instanznummer als Kommando-
zeilenparameter mitgegeben und gibt dann eine ahnliche Information wie das
¨
Le
weiter unten beschriebene ipcs aus. Es ist dabei allerdings spezifisch auf die
SAP-Situation angepasst. Das folgende, etwas komprimiert dargestellte Li-
sting zeigt den Aufruf und eine typische Ausgabe. Die ersten Zeilen geben die
Daten der SysV Shared Memory Bereiche an, dann folgen die Semaphoren
pp

und weitere IPC-Objekte.
lnxsap:soladm 54> showipc 42

Show/Cleanup SAP-IPC-Objects V2.3, 94/01/20
sU

===========================================

Running SAP-Systems (Nr)...:
----------------------------------------------------------
---- Show IPC-Objects of Sap-System 42 -------------------
----------------------------------------------------------
OsKey: 14201 0x00003779 Shared Memory Key: 1 Size: 0.0 MB
OsKey: 14202 0x0000377a Shared Memory Key: 2 Size: 2.3 MB
OsKey: 14203 0x0000377b Shared Memory Key: 3 Size: 12.4 MB
OsKey: 14204 0x0000377c Shared Memory Key: 4 Size: 0.5 MB
OsKey: 14206 0x0000377e Shared Memory Key: 6 Size: 439.4 MB
OsKey: 14207 0x0000377f Shared Memory Key: 7 Size: 0.0 MB
OsKey: 14219 0x0000378b Shared Memory Key: 19 Size: 143.0 MB
OsKey: 14221 0x0000378d Shared Memory Key: 21 Size: 0.5 MB

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
OsKey: 14240 0x000037a0 Shared Memory Key: 40 Size: 59.1 MB
OsKey: 14241 0x000037a1 Shared Memory Key: 41 Size: 6.1 MB
OsKey: 14251 0x000037ab Shared Memory Key: 51 Size: 3.7 MB
OsKey: 14252 0x000037ac Shared Memory Key: 52 Size: 0.0 MB
OsKey: 14254 0x000037ae Shared Memory Key: 54 Size: 4.0 MB
OsKey: 14257 0x000037b1 Shared Memory Key: 57 Size: 0.5 MB
OsKey: 24201 0x00005e89 Semaphore Key: 1
OsKey: 24202 0x00005e8a Semaphore Key: 2
OsKey: 24203 0x00005e8b Semaphore Key: 3
OsKey: 24204 0x00005e8c Semaphore Key: 4
... <more lines> ...

... <more lines> ... x
OsKey: 24234 0x00005eaa Semaphore Key: 34

OsKey: 58900142 0x0382beae SCSA Shared Memory Key: 58900000
Le
Size: 4096 0.0 MB Att: 13

Summary of Shared Memory Sizes: 1024.9 MB
pp

Number of IPC-Objects...........: 95
Summary of SAP Shared Memory....: 1024.9 MB
Summary of all Shared Memory....: 1041.4 MB

Das Listing zeigt die Menge der von SAP allokierten IPC-Objekte sehr deut-
sU

lich. Da in seltenen F¨llen das manuelle L¨schen aller allokierten Objekte,
a o
wie Shared Memory Bereiche und Semaphoren, notwendig werden kann, liefert
SAP auch ein Hilfsmittel aus, dass solch eine Aufgabe erledigt. Das Programm
cleanipc besitzt eine ¨hnliches Schnittstelle zum Verwender wie showipc.
a
Neben der Instanznummer m¨ssen aber in neueren Releases noch gesondert
u
Parameter angegeben werden, um IPC-Objekte zu l¨schen. Der Aufruf
o
lnxsap:soladm 61> cleanipc 42 remove
l¨scht alle IPC-Objekte der Instanz mit der Instanznummer 42. Im Vergleich
o
zu einer wiederholten Verwendung von ipcrm ist das sicher eine Verbesserung.
Noch ein Wort zur Warnung: cleanipc darf nat¨rlich nie w¨hrend der Lauf-
u a
zeit der Instanz aufgerufen werden. Selbst wenn das Betriebssystem manche
Operationen nicht zul¨sst, kann die Instanz dennoch gef¨hrlich instabil wer-
a a
den. Eine ahnliche Aussage gilt im ubrigen auch in merklich abgeschw¨chter
¨ ¨ a
Form f¨r manche anderen Werkzeuge der SAP, etwa esmon etc.
u
Die Programme, die Linux standardm¨ßig zur Anzeige der Speichergr¨ßen
a o
mitbringt, erhalten nahezu alle ihre Daten durch das Auslesen der entspre-

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
chenden Dateien im /proc-Dateisystem. Zu den Programmen, die auf diese
Weise vorgehen und damit in gewissen Bereichen aquivalente Werte liefern,
¨
z¨hlen vor allem free und vmstat. free dient ublicherweise prim¨r zur Aus-
a ¨ a
gabe des belegten und freien physischen Hauptspeichers und basiert auf den
Daten von /proc/meminfo

lnxsap:˜ # free
total used free shared buffers cached
Mem: 1031976 958900 73076 0 47132 387264
-/+ buffers/cache: 322824 452300
Swap: 4192924 914064 3278860

Die Form der Darstellung hat dabei schon hüfig f¨r Verwirrung gesorgt, da
a u
auf einem Linux-System der freie Hauptspeicher immer als sehr klein ange-
zeigt wird. Linux ist deshalb aber kein speicher-intensives Betriebssystem,
sondern geht von der Pr¨misse aus, dass der physische Hauptspeicher f¨ r die
a u
effiziente Nutzung vorhanden ist und nicht f¨r das Brachliegen. Linux allo-
u
kiert deshalb intern dynamisch Speicher f¨r seine Caches, der bei Bedarf an
u
Anwendungsprogramme zur¨ckgegeben wird.
u
¨
x
Das Programm vmstat zeigt uber die Speicherverteilung hinaus noch eine
Vielzahl anderer Daten an. Die hüfigste Verwendung ist aber wohl die zur
a
Le
Beobachtung von Aktivit¨ten der Speicherverwaltung
a

lnxsap:˜ # vmstat 3 3 -S m
prcs -----------memory------ -swap- --io--- -system- ----cpu----
pp

r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 912 13 47 390 1 4 7 11 44 8 3 0 96 1
0 0 912 13 47 390 0 0 0 0 112 167 0 0 99 0
0 0 912 13 47 390 0 0 0 12 109 190 0 0 99 0
sU

Hier werden neben den freien und belegten Bereichen auch die Swap- und
Block-Operationen pro Sekunde und die Auslastung der CPU angegeben. Die
Swap- und Block-Operationen werden im 2.6er Linux-Kernel aus der Da-
tei /proc/vmstat gelesen. Sie unterscheiden sich dadurch, dass die Block-
Operationen alle Zugriffe auf Block-Ger¨te z¨hlen, w¨hrend die Swap-Opera-
a a a
tionen nur Zugriffe auf die Swap-Bereiche ber¨cksichtigen, die aufgrund von
u
echten Swap- oder Paging-Aktionen durchgef¨hrt wurden. Es ist deshalb nicht
u
ungew¨hnlich, in der Anzeige von vmstat keine Swaps festzustellen, sondern
o
nur Block-Operationen – im Gegenteil, eine hohe Anzahl von Swaps ist ein
Anzeichen f¨r einen Speicherengpass.
u
Noch umfangreicher als vmstat ist das Programm sar, das Daten uber ¨
die gesamte Systemaktivit¨t anzeigt. F¨r die Bedienung verweisen wir auf die
a u
man Page [41]. Die inhaltlichen Aussagen der letzten Abs¨tze gelten auch f¨r
a u
sar nat¨rlich unver¨ndert.
u a
In einer SAP-Umgebung von besonderer Bedeutung ist auch das schon
hüfiger erw¨hnte Programm ipcs, das die IPC-Objekte anzeigt. F¨r das in
a a u
Abb. 3.14 gezeigte Beispiel liefert ipcs die folgende etwas vereinfachte Ansicht

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
lnxsap:soladm 54> ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch
0x00004dbe 753664 root 777 220298 1
0x44000000 786433 sdb 660 524828 2
0x44000064 819202 sdb 664 5513216 2
0x44000001 851971 sdb 666 131208 1
0x44000002 884740 sdb 666 131208 1
0x44000003 917509 sdb 666 6557656 9
0x00000000 950278 soladm 777 1024 1
0x00002796 983047 soladm 740 4194304 1
0x00000000 1015816 soladm 777 1024 1
0x0382beae 1048585 soladm 666 4096 13
0x000037b1 1081354 soladm 740 545276 10
0x00003782 4423691 soladm 740 56000000 11
0x00003779 4456460 soladm 740 312 11
0x0000377a 4489229 soladm 740 2515208 11
0x0000377b 4521998 soladm 740 13059200 11
0x000037ac 4554767
0x00003797 4587536
0x000037ab 4620305
x
soladm
soladm
soladm
740
740
740
53752
3922420
3972228
11
11
9
Le
0x000037b6 4653074 soladm 740 85716680 10
0x00003781 4685843 soladm 740 134217728 8
0x00003780 4718612 soladm 740 67108864 8
0x0000378a 4751381 soladm 740 263200 8
pp

0x000037a0 4784150 soladm 740 62000000 8
0x0000377f 4816919 soladm 740 7424 8
0x0000377c 4849688 soladm 740 524824 8
0x0000378d 8192025 soladm 740 528176 1
sU

0x000037a1 11534362 soladm 740 6499592 8
0x0000378b 11567131 soladm 740 149999904 8
0x00003799 11599900 soladm 740 10240000 8
0x000037ae 11632669 soladm 740 4194376 8
0x000037b9 11665438 soladm 740 4194376 8
0x000037b8 11698207 soladm 740 4194440 8
0x000037b7 11730976 soladm 740 13024 1
0x0000377e 11763745 soladm 740 460800000 2595
0x00003796 11796514 soladm 740 8352 8
0x0000379a 11829283 soladm 740 4194304 5
0x000037b2 11862052 soladm 740 2076 5
0x0000019d 11894821 soladm 666 524 0

Die Keys, die in der ersten Spalte gelistet sind, m¨ssen mit dem OsKey von
u
S. 155 verglichen werden und die shmid mit der Handle-Spalte. Beispielweise
zeigt die drittletzte Zeile den Key 0x0000379a. Ein Blick auf Abb. 3.14 zeigt,
dass es sich hierbei um die Enqueue-Tabelle mit dem dezimalen Schl¨ssel u
14234 handelt. Diese Information passt zur Ausgabe des Programms showipc
weiter oben.

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
Bei der neuen Form des SAP-Speichermanagements k¨nnen durch ein ein-
o
faches ls -lah /dev/shm auch die Dateien des Extended Memories beobach-
tet werden
lnxsap: # ls -lah /dev/shm
total 459527
drwxrwxrwt 3 root root 80 Jun 6 22:29 .
drwxr-xr-x 33 root root 176K Jun 6 18:46 ..
-rw------- 1 soladm sapsys 2.0G Jun 6 22:29 SAP_ES_42_000

W¨hrend die bisher genannten Werkzeuge Prozess-¨bergreifende Informa-
a u
tionen liefern, zeigen die folgenden Verfahren Details der einzelnen Prozesse.
Die Befehle ps und top sind jedem Administrator bekannt und geben Aus-
kunft uber den Speicherverbrauch eines Prozesses. Die genaue Verteilung des
¨
allokierten Speichers im virtuellen Adressraum des Prozesses mit der PID
<nn> geben beide allerdings nicht an. Hier kann das Programm pmap oder
ein direkter Blick in die Datei /proc/<nn>/maps helfen. Das folgende Listing
zeigt die Gestalt des virtuellen Adressraums eines Workprozesses unseres Bei-
spielsystems auf einem Intel 32-Bit-Prozessor. Die Pfade zu den Bibliotheken
und deren Namen sind dabei zur besseren Lesbarkeit in manchen F¨llen etwas
a
u
x
verk¨rzt dargestellt und die Angabe des Oﬀsets, die in der vollen Ausgabe in
der dritten Spalte geschieht, wurde ganz unterdr¨ckt:
u
Le
lnxsap: # cat /proc/4234/maps
08048000-098af000 r-xp 03:07 58287 disp+work
098af000-09cc2000 rw-p 03:07 58287 disp+work
pp

09cc2000-0d8ef000 rwxp 00:00 0
40000000-40016000 r-xp 03:07 19555 /lib/ld-2.3.3.so
40016000-40017000 rw-p 03:07 19555 /lib/ld-2.3.3.so
40017000-40019000 rw-p 00:00 0
40025000-40027000 r-xp 03:07 19564 /lib/libdl.so.2
sU

40027000-40028000 rw-p 03:07 19564 /lib/libdl.so.2
40028000-408dd000 r-xp 03:07 58290 dw_gui.so
408dd000-40a65000 rw-p 03:07 58290 dw_gui.so
40a65000-40a6a000 rw-p 00:00 0
40a6a000-41111000 r-xp 03:07 58292 dw_xml.so
41111000-411b0000 rw-p 03:07 58292 dw_xml.so
411b0000-411b1000 rw-p 00:00 0
411b1000-41c72000 r-xp 03:07 58293 dw_xtc.so
41c72000-41d69000 rw-p 03:07 58293 dw_xtc.so
41d69000-41d6a000 rw-p 00:00 0
41d6a000-41e4f000 r-xp 03:07 58291 dw_stl.so
41e4f000-41e86000 rw-p 03:07 58291 dw_stl.so
41e86000-41e88000 rw-p 00:00 0
41e88000-41ec2000 r-xp 03:07 66939 libstdc++-3
41ec2000-41ed3000 rw-p 03:07 66939 libstdc++-3
41ed3000-41ed5000 rw-p 00:00 0
41ed5000-41ef6000 r-xp 03:07 19582 tls/libm.so.6
41ef6000-41ef7000 rw-p 03:07 19582 tls/libm.so.6
41ef7000-41f04000 r-xp 03:07 19583 tls/libpthread.so.0

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
41f04000-41f05000 rw-p 03:07 19583 tls/libpthread.so.0
41f05000-41f07000 rw-p 00:00 0
41f07000-42011000 r-xp 03:07 19581 tls/libc.so.6
42011000-42019000 rw-p 03:07 19581 tls/libc.so.6
42019000-42064000 rw-p 00:00 0
42064000-420ea000 r--s 00:06 124649483 /SYSV000037b1 (deleted)
420ea000-45652000 rw-s 00:06 127991820 /SYSV00003782 (deleted)
45653000-45745000 r-xp 03:07 58378 dbadaslib.so
45745000-45782000 rw-p 03:07 58378 dbadaslib.so
45782000-457a9000 rw-p 00:00 0
457a9000-457aa000 rw-s 00:06 1114122 /SYSV0382beae (deleted)
457aa000-457ab000 rw-s 00:06 128155663 /SYSV00003779 (deleted)
457b7000-457bf000 r-xp 03:07 19570 /lib/libnss_files.so.2
457bf000-457c0000 rw-p 03:07 19570 /lib/libnss_files.so.2
457c0000-457c4000 r-xp 03:07 19569 /lib/libnss_dns.so.2
457c4000-457c5000 rw-p 03:07 19569 /lib/libnss_dns.so.2
457c5000-457d4000 r-xp 03:07 19576 /lib/libresolv.so.2
457d4000-457d5000 rw-p 03:07 19576 /lib/libresolv.so.2
457d5000-457d7000 rw-p 00:00 0
457d7000-45a3e000
45a3e000-466b3000
466b3000-466c1000
rw-s
rw-s
rw-s
x
00:06
00:06
00:06
128188432
128221201
128253970
/SYSV0000377a
/SYSV0000377b
/SYSV000037ac
(deleted)
(deleted)
(deleted)
Le
466c1000-46a7f000 rw-s 00:06 128286739 /SYSV00003797 (deleted)
46a7f000-46ef1000 rw-p 00:00 0
46ef1000-472bb000 rw-s 00:06 128319508 /SYSV000037ab (deleted)
472bb000-5febb000 ---p 00:00 0
pp

5febb000-5ff93000 rw-s 00:0c 102773 /dev/shm/SAP_ES_42_000
5ff93000-5ff94000 ---s 00:0c 102773 /dev/shm/SAP_ES_42_000
5ff94000-6033b000 rw-s 00:0c 102773 /dev/shm/SAP_ES_42_000
6033b000-61390000 r--s 00:0c 102773 /dev/shm/SAP_ES_42_000
sU

61390000-61391000 ---s 00:0c 102773 /dev/shm/SAP_ES_42_000
61391000-672bb000 rw-s 00:0c 102773 /dev/shm/SAP_ES_42_000
672bb000-672dc000 rw-p 00:00 0
672dc000-6c49b000 rw-s 00:06 128352277 /SYSV000037b6 (deleted)
6c49b000-6c51e000 rw-p 00:00 0
6c51e000-6c5e5000 r-xp 03:07 58913 libpcr.so
6c5e5000-6c611000 rw-p 03:07 58913 libpcr.so
6c611000-6c61b000 rw-p 00:00 0
6c61b000-6c61c000 rw-s 03:07 59058 .sdb/irtrace.shm
6c61c000-6cc5d000 rw-s 00:06 983046 /SYSV44000003 (deleted)
6cc5d000-6cc7e000 rw-p 00:00 0
6cc7e000-74c7e000 rw-s 00:06 131694614 /SYSV00003781 (deleted)
74c7e000-78c7e000 rw-s 00:06 131727383 /SYSV00003780 (deleted)
78c7e000-78cbf000 rw-s 00:06 131760152 /SYSV0000378a (deleted)
78cbf000-7c7e0000 rw-s 00:06 131792921 /SYSV000037a0 (deleted)
7c7e0000-7c7e2000 rw-s 00:06 131825690 /SYSV0000377f (deleted)
7c7e2000-7c863000 rw-s 00:06 131858459 /SYSV0000377c (deleted)
7c863000-7ce96000 rw-s 00:06 131923997 /SYSV000037a1 (deleted)
7ce96000-82df5000 rw-s 00:06 131956766 /SYSV0000378b (deleted)

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
82df5000-837b9000 rw-s 00:06 131989535 /SYSV00003799 (deleted)
837b9000-83bba000 rw-s 00:06 132022304 /SYSV000037ae (deleted)
83bba000-83fbb000 rw-s 00:06 132055073 /SYSV000037b9 (deleted)
83fbb000-843bc000 rw-s 00:06 132087842 /SYSV000037b8 (deleted)
843bc000-843c2000 r--p 03:07 22424 de_DE/LC_COLLATE
843c2000-843f5000 r--p 03:07 22285 de_DE/LC_CTYPE
843fb000-845db000 rw-p 00:00 0
845db000-8521e000 rw-s 00:06 132120611 /SYSV0000377e (deleted)
8521e000-9fd4f000 r--s 00:06 132120611 /SYSV0000377e (deleted)
9fd4f000-9fda9000 rw-p 00:00 0
9fda9000-9fdac000 rw-s 00:06 132153380 /SYSV00003796 (deleted)
9fdac000-9fedb000 r-xp 03:07 58322 libsapsecu.so
9fedb000-9feef000 rw-p 03:07 58322 libsapsecu.so
9feef000-9ff6d000 rw-p 00:00 0
9ff6d000-9ff73000 r--p 03:07 22424 en_US/LC_COLLATE
9ff73000-9ff79000 r--s 03:07 19795 gconv-modules.cache
9ff79000-9ffa5000 r--p 03:07 22423 en_US/LC_CTYPE
9ffa5000-a027d000 rw-p 00:00 0
a027d000-a067d000 rw-s 00:06 135528486 /SYSV0000379a (deleted)
a067d000-a067f000
a067f000-a0680000
a0680000-a0681000
rw-p
rw-s
r-xp
x
00:00
00:06
03:07
0
135561256
19744
/SYSV000037b2 (deleted)
ISO8859-1.so
Le
a0681000-a0682000 rw-p 03:07 19744 ISO8859-1.so
a0682000-a072a000 rw-p 00:00 0
bff83000-c0000000 rwxp 00:00 0
ffffe000-fffff000 ---p 00:00 0
pp

Diese Listendarstellung birgt die genauesten Informationen uber die Gestalt
¨
des virtuellen Adressraum eines Prozesses, die mit einfachen Linux-Mitteln
erh¨ltlich ist, s. auch [32]. Jede Zeile beschreibt dabei eine der auf S. 116 schon
a
sU

vorgestellten Virtual Memory Areas (VMA). In der ersten Spalte wird die
Start- und die End-Adresse der jeweiligen VMA im virtuellen Adressraum des
Prozesses angegeben. Aus dem obigen Listing geht z.B. hervor, dass der erste
eingeblendete Bereich bei 0x08048000, d.h. bei ca. 128 MB, beginnt. Er endet
bei 0x098af000 und ist damit 6247 Pages groß. Die n¨chste Spalte gibt die
a
Rechte dieser VMA an, die in unserem Beipiel als r-xp gegeben sind. Die VMA
besteht also aus Pages, die gelesen (r) und ausgef¨hrt (x) werden k¨nnen.
u o
Die Pages sind zudem prozess-privat (p) und kein gemeinsamer Bereich, wie
Shared Memory. In diesem Fall w¨re das letzte Zeichen ein s.
a
Die n¨chsten beiden abgebildeten Spalten 3 und 4 geben den Ort auf dem
a
Dateisystem an, von wo die Daten der VMA in den virtuellen Adressraum
eingeblendet wurden. Dieser Bereich wird ublicherweise als Backing Store
¨
bezeichnet. Die Spalte 3 enth¨lt die Major- und Minor-Nummer des zugrun-
a
deliegenden Ger¨ts und die Spalte 4 die Inodenummer der Datei. Die Major
a
und Minor-Nummer k¨nnen durch ein ls -l /dev mit dem symbolischen
o
Namen des Ger¨tes, z.B. /dev/hda7 in Beziehung gebracht werden. Die In-
a
odenummer kann mittels des Befehls ls -i angezeigt werden. Der zugeh¨rige o
Dateiname, wenn er denn existiert, bildet schließlich die letzte Spalte. Damit

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
zeigt sich, dass die erste Zeile das Einblenden des SAP-Kernels disp+work in
den virtuellen Adressraum des Prozesses beschreibt. Die Rechte helfen bei der
Pr¨zisierung dieser Aussage: der ausf¨ hrbare Code wird an diese Stelle ein-
a u
gelagert. Die n¨chste und die ubern¨chste Zeile zeigen dann den zugeh¨rigen
a ¨ a o
Datenbereich, der aus einer VMA f¨r die initialisierten und einer VMA f¨r
u u
die nicht-initialisierten Daten besteht.
Dieses Verfahren, Code und Daten direkt hintereinander in den Adres-
sraum des ausf¨ hrenden Prozesses einzublenden, findet sich bei allen aus-
u
f¨hrbaren Programmen unter Linux. Auch die Shared Libraries folgen diesem
u
Muster. Im obigen Beispiel sind hier z.B. die libc.so.6 und die Datenbank-
Bibliothek dbadaslib.so zu nennen.
Andere Bereiche treten nur einmal als Datenbereich mit den Rechten rw-
auf. Hier kann unterschieden werden zwischen den privaten Bereichen, die
typischerweise zum Heap geh¨ren und beispielsweise per malloc() allokiert
o
wurden, und den gemeinsamen Bereichen. Zu den letzteren z¨hlen in unserem
a
Beispiel die SystemV-Shared Memory Segmente. Das vorletzte der Segmente,
das den Namen /SYSV0000379a erhalten hat, entspricht wieder der oben schon
erw¨hnten Enqueue-Tabelle. Aber auch die Bereiche des Extended Memories
a

x
/dev/shm/SAP ES 42 000 sind als gemeinsamer Speicher erkennbar.
Die letzten beiden Zeilen schließlich stellen den Stack und zu guter Letzt
die Page dar, die f¨r die vsyscalls verwendet werden kann, s. S. 118.
u
Le
F¨r die 64-Bit-Plattformen, wie ia64, x86 64 und zSeries, folgen beispiel-
u
hafte Darstellungen im Abschnitt 3.3.4. Sie geben dann einen guten Eindruck
von der Gr¨ße des virtuellen Adressraums, der mit 64 Bit zur Verf¨gung steht.
o u
pp

3.3.2 Allgemeine Fragen und Probleme

Unsere Erfahrung in der Bearbeitung von Kundenproblemen zeigt, dass man-
sU

che Fragen beim Betrieb von SAP-Systemen auf Linux immer wieder gestellt
werden. Die Fragen, die weitgehend unabh¨ngig von der zugrundeliegenden
a
Hardware-Plattform sind, behandeln wir in diesem Abschnitt. Auf spezielle
Aspekte von 32- und 64-Bit-Systemen gehen wir weiter unten ein.

Betriebssystemebene

Die Frage, die im Umfeld der Linux-Speicherverwaltung vermutlich am hü- a
figsten gestellt wird, betrifft das Paging oder Swapping des Linux-Systems. Sie
tritt in verschiedenen Formen auf. Beliebte Varianten sind z.B. die Fragen nach
der Menge an ben¨tigtem Swap-Space oder nach der vertretbaren Menge an
o
Swap-Outs. Zur Enttüschung direkt vorweg: Eine allgemeing¨ltige Antwort
a u
auf diese Fragen gibt es nicht. Wir stellen in diesem Abschnitt aber einige
der wichtigsten Grundlagen zusammen, so dass die Beantwortung f¨r den u
Einzelfall leichter fallen sollte.
Zun¨chst ist an zwei wichtige Eigenschaften der Linux-Speicherverwaltung
a
zu erinnern. Die erste beschreibt, wie Linux Swap-Speicher bereitstellt. Wenn
unter Linux ein Prozess Speicher allokiert, wird dieser Speicher nicht sofort

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
auch im Swap-Bereich reserviert. Die Allokierung geschieht meistens erst,
wenn der Pages des Prozesses wirklich auf den Swap-Bereich ausgelagert wer-
den m¨ssen. Dieses Verfahren wird mitunter als late swap allocation be-
u
zeichnet. Manche Unix-Derivate folgen einem anderen Muster und stellen den
Swap-Speicher unmittelbar bei der Allokierung bereit. Da in vielen F¨llen der
a
allokierte Speicher aber nur kurzfristig ben¨tigt wird, muss er dann nicht auf
o
den Swap-Bereich ausgelagert werden. Ein Verfahren wie das von Linux spart
damit Platz im Swap-Bereich ein.
Auf der anderen Seite trachtet der Linux-Kernel danach, immer eine ge-
wisse Menge an Speicher zur freien Verf¨gung zu haben. Er versucht – durch
u
diverse Kernel-Threads, wie kswapd – deshalb Pages schon vorab auszulagern.
Hierbei kann aber zwischen zwei Formen der Auslagerung unterscheiden wer-
den. Auf der einen Seite stehen die Pages, die Daten von Objekten des Datei-
systems zwischenspeichern. Sie liegen unter Linux 2.4 im Buffer- und bei Linux
2.6 in einem vereinheitlichten Page-Cache. Wenn solche Pages durch Schreib-
Vorg¨nge ver¨ndert wurden, muss der Kernel diese Daten irgendwann auf die
a a
entsprechenden Plattenbereich schreiben. IO-Vorg¨nge dieser Art sind damit
a
nicht zu vermeiden. Sie werden in Tools wie sar unter dem allgemeinen Be-

x
griff der Pageouts angezeigt, der jede Form der Auslagern einer Page auf
Platte beschreibt. Die zweite Form der Auslagerung betrifft die eigentlichen
Swapouts, bei denen Pages auf den Swap-Bereich geschrieben werden. In
Le
manchen Tools werden sie zum einen eigens ausgewiesen, zum anderen aber
auch zu den Pageouts hinzugerechnet. Dieses zweifache Auftreten, einmal di-
rekt, einmal versteckt, ist mitunter verwirrend.
pp

Auf dieser Basis sind nun einige Hilfestellungen bei typischen Fragen
m¨glich:
o

• Wenn ich schon viel physikalischen RAM habe, muss ich dann
sU

noch (viel) Swap installieren?
Ja. Es w¨re zwar theoretisch denkbar, die Speicheranforderungen aller je-
a
mals auf dem gegebenen Rechner laufenden Anwendungen zu ermitteln
und entsprechend ausreichend physikalischen RAM zur Verf¨gung zu stel-
u
len. Es sollte dann nicht mehr zu Swapouts kommen, die durch Speiche-
rengp¨sse, etc. bedingt sind. Auch w¨ rden die großen Geschwindigkeitsun-
a u
terschiede zwischen Hauptspeicher und Festplatten dann nicht mehr zum
Tragen kommen.
Zwei Gr¨nde sprechen aber gegen eine Konfiguration mit nur minimalem
u
Swap. Zun¨chst versucht der Linux-Kernel nach dem zweiten der oben ge-
a
nannten Punkte stets Pages zu befreien. Ein Beispiel f¨r Pages, die nahezu
u
immer ausgelagert werden k¨nnen, sind solche, die nur beim Starten der
o
Anwendung genutzt wurden. Im weiteren Verlauf k¨nnen sie durchaus vom
o
Kernel ausgelagert werden. Ein Swap-Bereich kann damit die Performance
erh¨hen.
o
Speziell f¨r das SAP-System kommt noch hinzu, dass die Speicheranforde-
u
rungen gerade im Heap, die letztlich im Swap aufgefangen werden, hoch-
gradig dynamisch sind. Auch Profilparameter wie abap/heap area total

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
helfen nur bedingt bei der Bestimmung der faktischen Speicheranforde-
rungen.
• Wieviel Swap brauche ich denn dann f¨ r den Einsatz von SAP
u
auf Linux?
Unter Linux gilt die klassische Formel Swap >= 2 * RAM aufgrund des
ersten oben genannten Punktes nicht unbedingt verpflichtend. Ein Linux-
System kann durchaus mit weniger Platz im Swap-Bereich auskommen. Es
ist allerdings nicht zu empfehlen, an dieser Stelle im Server-Bereich zu spa-
ren. Plattenplatz ist heute vergleichsweise g¨ nstig, eine etwas großz¨ gige
u u
Dimensionierung des Swap-Bereichs, vielleicht sogar verteilt uber mehrere
¨
Plattencontroller, stellt in den meisten F¨llen kein Problem dar.
a
Ein Fehler, der durch Platzmangel im Swap erzeugt wird, hat demge-
gen¨ber schon unangenehmere Auswirkungen. Normalerweise f¨hrt er zu
u u
einer sogenannten Out-Of-Memory-Situation (OOM), in der der Linux
Kernel in den meisten F¨llen einen Prozess beenden muss.
a
Aus diesem Grund besteht f¨r den Betrieb von SAP auf Linux die Emp-
u
fehlung, den Swapbereich mit der doppelten Gr¨ße des Hauptspeichers zu
o
konfigurieren.
•
x
Wieviel Paging / Swapping ist zul¨ssig?
a
a
Die Antwort auf diese Frage h¨ngt in hohem Maße von der Konfigura-
tion des Systems ab. Aspekte wie die Geschwindigkeit des I/O-Subsystems
Le
(Festplattencontroller, Festplatten, . . . ) spielen eine große Rolle. Generell
l¨ßt sich nach dem bereits Gesagten nur festhalten, dass im eingeschwun-
a
genen Zustand des Systems kein Swapping stattfinden sollte. Paging-
pp

Vorg¨nge, um z.B. Daten aus Dateien auf die Platte zu bringen, sind
a
demgegen¨ber stets m¨glich. Im Falle der PageOuts gilt dieses Aussage f¨r
u o u
alle Komponenten in einem SAP-System. Bei den PageIns muss noch nach
reinen Applikationsservern und Datenbankmaschinen unterschieden wer-
sU

den. Auf dem ersten Typ sind PageIn-Vorg¨nge eher selten, da nur selten
a
Einlese-Vorg¨nge vom Dateisystem unternommen werden. Bei Datenbank-
a
Maschinen hingegen geschieht dies hüfiger.
a
• Ist Pageout oder Pagein schlimmer?
Gerade wurde schon gesagt, dass auf einem Applikationsserver im einge-
schwungenen Zustand prim¨r PageOuts stattfinden sollten. Aber auch bei
a
den Datenbank-Servern, bei denen PageIns zum Gesch¨ft geh¨ren, sind
a o
sie eher unerw¨nscht, da die Caches der Datenbank einen Großteil der
u
Lesezugriffe auf die Platte abfangen sollen.
• Brauche ich f¨ r den SAP-Betrieb diese seltsamen Prozesse wie
u
kswapd und pdflush? Welche Bedeutung haben die uberhaupt? ¨
Die Antwort auf die erste Frage lautet: Ja. In neueren Linux-Systemen wer-
den Aufgaben der Speicherverwaltung durch spezielle Kernel-Threads
erledigt, die als Prozesse dargestellt sind. Im 2.4-Kernel geh¨ren kswapd,
o
bdflush und kupdate dazu.
kswapd wird dann aktiv, wenn in einem bestimmten Speicherbereich, ei-
ner Zone, zu wenig freie Pages existieren. Der Kernel-Thread gibt dann
vorzugsweise nicht ver¨nderte Pages auch aus den Caches frei und erzeugt
a

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
Requests f¨r den I/O-Scheduler, der das faktische Schreiben dieser Pages
u
auf die Ger¨te ubernimmt. Diese Aufgabe hat der kswapd auch in der
a ¨
2.6er-Reihe noch. Der Wert unter /proc/sys/vm/page cluster gibt an,
wieviele Pages kswapd zusammen bearbeiten soll.
Die Verwaltung der Pages, die zu Objekten des Dateisystems geh¨ren, o
ubernehmen in der 2.4er-Reihe die Kernel-Threads bdflush und kupdate.
¨
bdflush schreibt modifizierte Bl¨cke, die zu Dateien geh¨ren, aus dem
o o
Buffer-Cache auf die Platte und sorgt damit f¨r die Konsistenz des Datei-
u
systems. Damit ist das bekannte verz¨gerte, asynchrone Schreiben m¨glich.
o o
Er wird aktiv, wenn das Linux Memory Management Platzprobleme mel-
det oder wenn im Buffer Cache selbst zu wenig Platz verf¨ gbar ist. Im
u
Gegensatz dazu wird kupdate in periodischen Abst¨nden aktiv und ver-
a
sucht, modizierte Pages herauszuschreiben. Beide k¨nnen uber Werte unter
o ¨
/proc/sys/vm/ konfiguriert werden.
In der 2.6er-Reihe ubernimmt pdflush die Aufgaben von bdflush und
¨
kupdate. Auch er schreibt Daten aus dem Pagecache auf die Platte. Genau
wie bei seinen Vorg¨ngern ist auch bei pdflush die wichtigste Konfigura-
a
tionsm¨glichkeit, die Angabe der Grenze, ab wann ein Wegschreiben der
o

x
Daten erfolgen soll, der Cache also als voll markiert wird.
In einer SAP-Umgebung sind all diese Aufgaben wesentlich f¨r einen per-
formanten Betrieb des Systems.
u
Le
• Muss ich denn die Speicherverwaltung des Linux-Kernels para-
metrisieren, um SAP auf Linux betreiben zu k¨nnen? o
¨
Im allgemeinen Fall eher nein. Anderungen an den Einstellungen, die in der
pp

vorigen Antwort beschrieben wurden, f¨hren in keinem uns derzeit bekann-
u
ten Szenario zu einer signifikanten Verbesserung der Gesamtperformance.
Ein Grund f¨r dieses Verhalten liegt im Speicherzugriffsmuster der SAP
u
Applikationsserver. Die Workprozesse gehen, unter anderem aufgrund des
sU

Multiplexings, s. S. 69, ohne genau vorhersagbares Zugriffsmuster, sondern
eher chaotisches vor. Die meisten Einstellungen an den Kernelparametern
verbessern dagegen oft nur nur ein spezielles Zugriffsmuster.

SAP-Ebene
Ein Großteil der erfahrungsgem¨ß hüfig gestellten Fragen wurde im bisheri-
a a
gen Verlauf dieses Kapitels schon behandelt. Dieser Abschnitt greift deshalb
nur einige spezielle Probleme auf, die im Umfeld der Speicherverwaltung auf
SAP-Ebene auftreten. Diese Fragen lassen sich einteilen in Fragen zu Puffer-
einstellungen und zu Einstellungen des User-Memory.
Bei den Puffern steht der Programmpuffer PXA an erster Stelle. In alteren
¨
SAP-Releases war die interne Struktur des Puffers so, dass die Fragmen-
tierung ein wiederkehrendes Problem darstellte. In neueren Releases ab 4.5
wurde diese Schwierigkeit weitgehend behoben. Es bleibt in den weitaus mei-
sten F¨llen nur noch die Frage nach der Gr¨ße des Programmpuffers offen.
a o
Ein zu kleiner Programmpuffer kann die effiziente Ausf¨hrung von ABAP-
u
Programmen verhindern, eine zu große Einstellung an Betriebssystemgrenzen

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
stoßen. Hierbei ist besonders zu bedenken, dass der Programmpuffer stets als
SysV-Segment realisiert ist und damit durch Parameter wie SHMMAX begrenzt
wird.
Wenn der ABAP-Programmpuffer nicht in der Gr¨ße allokiert werden
o
kann, die der Parameter abap/buffersize vorgibt, kommt es zum RABAX-
Fehler, der in den Developertraces im Workverzeichnis der Instanz protokol-
liert wird:
A Fri Apr 22 16:18:47 2005
A
A ---PXA-------------------------------------------
A PXA INITIALIZATION
A System page size: 4kb, admin_size: 31788kb.
I *** ERROR => shmget(11906,1126400000,2016)
(22: Invalid argument) [shmux.c 1904]
A RABAX in run level 1
A RABAX in unkown environment: task_type=0, run level=1,
rabax state=80000000
...

x
Im vorliegenden Fall konnte der ABAP-Programmpuffer nicht mit der kon-
figurierten Gr¨ße von 1 100 000 KB (1126400000 Byte) allokiert werden.
o
Le
Die Ursache kann zum einen durch einen zu kleinen Adressraum verursacht
sein, andererseits aber auch durch nicht ausreichend angepasste Linux Kernel
Parameter. Wie auf S. 134 beschrieben, gibt der sysctl-Parameter SHMMAX, mit
pp

welcher Gr¨ße ein SysV-Shared Memory maximal angefordert werden darf.
o
Wird versucht einen SAP Puffer mit einem gr¨ßeren Wert anzulegen, kommt
o
es zum Fehler.
Das gleiche passiert auch, wenn im ganzen Linux System mehr SysV-
Shared Memory angefordert wird, als SHMALL zul¨sst. Dieser Parameter gibt
a
sU

an, wieviel Pages im gesamten System f¨ r das SysV-Shared Memory einge-
u
setzt werden d¨rfen. Beim Einsatz der std-Implementierung oder von 64 Bit
u
Systemen kann es vorkommen, dass diese Parameter initial nicht ausreichend
groß eingestellt wurden.
Mit den SAP-Puffern verbunden ist auch der zweite Themenkomplex, der
mitunter Aufmerksamkeit verdient. Jeder der SAP-Puffer ist zur Zugriffskon-
trolle mit einer Semaphor assoziiert, s. S. 71 und 83. Diese Semaphoren
werden in der Transaktion ST02 im Unterpunkt Detail Analysis angezeigt,
s. Abb. 3.15. In sehr speziellen Situationen kann es zu l¨ngeren Wartezeiten
a
kommen, bis ein Workprozess auf den gew¨nschten Puffer zugreifen darf. In
u
solchen F¨llen zeigt dieser Unterpunkt der Transaktion ST02 die Semaphor
a
an, auf die lange gewartet wird. Diese Information kann Hilfestellung bei der
L¨sung des damit verbundenen Performance-Problems geben.
o
Im Umfeld der User-spezifischen Speicherbereiche sind auf Seiten des
ABAP-Applikationsservers noch der Roll- und der Page-Puffer zu erw¨hnen.a
Beide Puffer bestehen aus einem Bereich, der im Hauptspeicher existiert, und
einer Datei auf dem Dateisystem, s. S. 130. Der in der Datei verf¨ gbare Platz
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

x
Le
pp
sU

Abb. 3.15. Transaktion ST02: Semaphores

wird dabei aber nur verwendet, wenn der Speicherbereich voll ist. Leider exi-
stiert nun gerade im Bereich des hüfiger eingesetzten Roll-Puffers eine Frag-
a
mentierung, die dazu f¨hren kann, dass der Rollpuffer zwar noch freien Platz
u
besitzt, dennoch aber die Datei beschrieben wird. In einer eingeschwungenen
Umgebung sollten deshalb die Speicherparameter, die im Zusammenhang mit
der std- und der map-Implementierung vorgestellt wurden, stets so eingestellt
werden, dass m¨glichst kein Roll-Verbrauch stattfindet. Diese Aussage gilt
o
in dieser Form nicht f¨r den Pagebereich, da die ABAP-Anweisungen, die
u
den Page-Puffer verwenden, dies unabh¨ngig von der Speicherkonfiguration
a
tun. Hier sollte immer auf eine hinreichende Gr¨ße des Page-Puffers geachtet
o
werden.

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.3.3 Besonderheiten bei SAP-Systemen mit 32-Bit Linux

Plattformen, auf denen der virtuelle Adressraum durch die 32-Bit-Vorgabe
auf 4 GB beschr¨nkt ist, stellen f¨r ein speicherhungriges System wie SAP
a u
eine große Herausforderung dar. Selbst mit der neuen Implementierung des
Speichermanagements, s. Abschnitt 3.2.3, bleibt diese Restriktion sp¨rbar.
u
Große Userkontexte von 1.5 GB und gr¨ßer sind heute keine Seltenheit mehr
o
und bringen selbst die Variante es/implementation = map an ihre Grenzen.
Einige der typischen Probleme auf 32-Bit-Plattformen beschreiben wir im Fol-
genden.
Schon auf S. 115 wurde beschrieben, dass der Linux Kernel von den
verf¨gbaren 4 GB bei f¨r SAP freigegebenen Kerneln 1 GB f¨r seine Zwecke
u u u
reserviert. Einer Anwendung stehen damit nur noch die unteren 3 GB zur
Verf¨gung. Das klassische Bild eines solchen Adressraums ﬁndet sich noch
u
einmal in Abb. 3.16, die Abb. 3.1 um eine Skizze der SAP-Speicherbereiche
erg¨nzt. Es zeigt sich, dass in dieser Linux-Version der Programmcode bei
a
ca. 128 MB beginnt, s. S. 161. Der Bereich kleinerer Adressen wird nicht ge-

x
nutzt. Zudem werden in dieser Variante ab 1 GB (hexadezimal 0x40000000) die
Shared Libraries eingeblendet. Erst bei h¨heren Adressen k¨nnen damit die
o o
Le
gemeinsamen Speicherbereiche des SAP-Systems beginnen. In solchen Linux-
pp
sU

Abb. 3.16. Adressraumaufteilung bei ¨lteren Linux Versionen, Beispiel SuSE Linux
a
Enterprise Server 8

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

x
Abb. 3.17. Adressraumaufteilung bei neueren Linux-Versionen, Beispiel Red Hat
Le
Enterprise Linux 4

Versionen stehen f¨r das SAP-System damit de facto nur knapp 2 GB f¨r seine
u u
eigenen Speicheranforderungen im Shared Memory bereit.
pp

Etwas gr¨ßer wird der f¨r Shared Memory verf¨gbare Platz in den neueren
o u u
Versionen, die Ans¨tze des Linux-Kernels 2.6 aufgreifen, s. S. 117. Hier werden
a
die Bibliotheken an den R¨ndern des virtuellen Adressraums eingeblendet. Es
a
kann deshalb von einer Erh¨hung des f¨r Shared Memory verf¨gbaren Adres-
o u u
sU

sraums auf knapp 3 GB ausgegangen werden. Abbildung 3.17 zeigt ein typi-
sches System. Daraus ist aber auch ein potentielles Problemfeld dieses Layouts
ersichtlich: Zwar stehen die Bibliotheken nun dem gemeinsamen Speicher nicht
mehr im Weg, sind aber in die N¨he des Stacks ger¨ckt, der sich in ihre Rich-
a u
tung bewegt. Hier ist also eine sorgf¨ltige Planung des Layouts notwendig,
a
um nicht Kollisionen hervorzurufen.
Die Erweiterung des verf¨gbaren virtuellen Adressraums f¨r Shared Me-
u u
mory auf 3 GB sollte bei der Konﬁguration der SAP-Speicherparameter
ber¨cksichtigt werden. Zu beachten ist dabei, dass selbst das Zero Admi-
u
nistration Memory Management (ZAMM), s. S. 141, diese neuen Aspekte
nicht vollst¨ndig abdecken kann. Die Proﬁlparameter, die zur optimalen Aus-
a
nutzung des vergr¨ßerten virtuellen Adressraums angepasst werden m¨ssen,
o u
liegen nicht in der Verantwortung des ZAMM. Zu diesen Parametern geh¨ren o
• Der Parameter em/address space MB, der die maximale Gr¨ße des Exten-
o
ded Memory im virtuellen Adressraum eines Workprozesses angibt. Er ist
standardm¨ßig auf 512 MB eingestellt.
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
c u -tr a c k
• Die Parameter, die die Gr¨ße der SAP-Puffer bestimmen. Hier sind z.B.
o c u -tr a c k

die Parameter abap/buffersize f¨r den ABAP-Programmpuffer und
u
zcsa/table buffer area f¨r den generischen Tabellenpuffer zu nennen.
u
Sie m¨ssen manuell nachgestellt werden.
u
Eine Bemerkung ist abschließend noch angebracht: Aus den bisher gemach-
ten Aussagen darf nicht geschlossen werden, dass der Teil des Adressraums,
in dem kein SystemV oder POSIX Shared Memory allokiert werden kann,
brachliegt. Die meisten der vorhandenen L¨cken bilden den Vorrat, aus dem
u
Heap-Anforderungen befriedigt werden. Eine typisches Beispiel sind Work-
prozesse im PRIV-Modus, s. S. 127. Je nach Betriebssystemversion k¨nnen
o
im Heap zus¨tzlich zum Shared Memory noch ca. 850 MB (SLES 8) allokiert
a
werden.

Hüfige Probleme im Betrieb auf 32-Bit Linux
a

Einige Fehler bei der Konfiguration des SAP-Systems sind relativ einfach zu
bemerken. Dies sind vor allem die Fehler, die einen korrekten Start des SAP-
x
Applikationsservers verhindern. Hierzu z¨hlt z.B. die Allokierung von mehr
a
Speicherplatz als im virtuellen Adressraum verf¨gbar ist. Andere Fehler zeigen
u
Le
sich dagegen erst w¨hrend der Laufzeit des Systems, da Speicher dynamisch
a
allokiert und freigegeben wird. Im Folgenden gehen wir auf einige ABAP
Shortdumps ein, die direkt oder indirekt mit der Problematik eines kleinen
pp

virtuellen Adressraums im Zusammenhang stehen:

• TSV TNEW PAGE ALLOC FAILED
Dieser Kurzdump wird beim Erreichen einer von SAP gesetzten Grenze,
einer Quota ausgel¨st. Ein Beispiel einer solchen Quotierung ist der Pa-
o
sU

rameter abap/heap area dia. Bei ¨lteren SAP-Kerneln waren die SAP
a
Heapquotas standardm¨ßig noch sehr konservativ eingestellt, so dass eine
a
Vergr¨ßerung dazu f¨hren kann, dass auch gr¨ßere Benutzerkontexte noch
o u o
bearbeitet werden k¨nnen.
o
Im Developertrace im Workverzeichnis der SAP-Instanz üßert sich dieser
a
Fehler beispielsweise so:
A
A Tue Jul 5 13:28:18 2005
A Tue Jul 5 13:28:18 2005
A
A ABAP/4 Program ZUSMEM .
A Source ZUSMEM Line 17.
A Error Code TSV_TNEW_PAGE_ALLOC_FAILED.
...
A Function tsvAllocPages Line 1749.
A Kein Speicher f¨r Erweiterung einer internen Tabelle mehr
u
A verf¨gbar.
u
A

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

x
Le
pp

Abb. 3.18. Erreichen einer SAP-Quota:
sU

Kurzdump TSV TNEW PAGE ALLOC FAILED

Anhand dieser kurzen Fehlerbeschreibung ist zwar bereits erkennbar, wel-
ches Programm den Fehler verursacht hat (ZUSMEM), allerdings ist hier
nicht ersichtlich, welche Menge welchen Speichertyps zum Zeitpunkt des
Abbruchs angefordert worden war.
Dies wird allerdings beim genaueren Betrachten des Kurzdumps im SAP-
System selbst ersichtlich. Scrollt man in der Dumpanalyse der Transak-
tion ST22 beim entsprechenden Eintrag etwas herunter, erh¨lt man eine
a
¨
Ubersicht uber die Speicherbelegung zum Zeitpunkt des Abbruchs. Abbil-
¨
¨
dung 3.18 zeigt diese Ubersicht.
Im Beispiel werden 1,7 MB (1 708 928 Byte) im Roll-Bereich, 400 MB (419
166 904 Byte) Extended Memory und 76 MB (80 084 352 Byte) im Heap be-
legt. Oﬀensichtlich ist hier die Heapquota (abap/heap area dia) zu klein
eingestellt. Durch Erh¨hung dieses Parameters kann nun einem Benutzer-
o
kontext erlaubt werden, in Zukunft mehr Heapspeicher anzufordern.

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
pp
sU

Abb. 3.19. Erreichen der Adressraumgrenze:
Kurzdump STORAGE PARAMETERS WRONG SET

Hier zeigt sich auch wieder, dass die Global Area sich den verf¨gbaren
u
Platz mit den reinen Userdaten teilt: Obwohl em/address space MB
mit 512 MB konfiguriert war, konnten nur knapp 400 MB im Exten-
ded Memory angefordert werden. Die Differenz erkl¨rt sich dadurch,
a
dass die Parameter f¨r die globalen Bereiche em/global area MB bzw.
u
abap/shared objects size MB mit 96 MB bzw. mit 20 MB konfiguriert
sind.
• STORAGE PARAMETERS WRONG SET
Bei diesem Kurzdump bem¨ngelt das SAP-System, dass das Betriebs-
a
system keinen weiteren Heap-Speicher mehr zur Verf¨ gung stellt, ob-
u
wohl die SAP-Grenzen, die durch die Parameter abap/heap area dia und
abap/heap area nondia gesetzt sind, noch nicht erreicht wurden. Abbil-
dung 3.19 zeigt den zugeh¨rigen Screenshot.
o

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
Im Developertrace des betroffenen Workprozesses üßert sich dieser Fehler
a
beispielsweise so:
A
A Mon Jul 25 15:02:17 2005
A Mon Jul 25 15:02:17 2005
A
A ABAP/4 Program ZUSMEM .
A Source ZUSMEM Line 17.
A Error Code STORAGE_PARAMETERS_WRONG_SET.
...
A Function resize_0 Line 607.
A &INCLUDE INCL_INSTALLATION_ERROR.
A

Eine Empfehlung zur Vermeidung einer solchen Situation geht dahin, die
SAP Heapquotas zu verringern. Dazu k¨nnte man von der Menge des
o
Speichers, der gerade noch allokiert werden konnte, 10 MB abziehen und
den daraus resultierenden Wert als Quota von abap/heap area dia bzw.

x
abap/heap area nondia einstellen. Die Folge daraus ist meistens, dass
dann in der Tat der oben genannte Fehler nicht mehr auftritt. Die SAP-
Parameter sch¨tzen damit die Betriebssystemressourcen, ein g¨ngiges und
u a
Le
sinnvolles Muster bei der Einstellung der SAP-Profilparameter.
Im vorliegenden Fall tritt aber in der Regel daf¨r ein anderer Fehler auf,
u
da das eigentliche Problem nicht gel¨st wurde. Dieses besteht n¨mlich in
o a
pp

den großen Heap-Anforderungen eines Workprozesses. Durch Verkleine-
rung der Heap-Parameter werden diese SAP-Parameter nun zur begren-
zenden Gr¨ße, der Speicherverbrauch des Prozesses wird dadurch nicht
o
beeinflusst.
In manchen Situationen kann es also sinnvoll sein, die SAP-Heap-Parame-
sU

ter nicht zu verkleinern, sondern den Workprozess so viel Speicher vom
Betriebssystem anfordern zu lassen, wie es von Seiten des Betriebssystems
m¨glich ist. Das entspricht dann einer maximalen Ausnutzung des virtu-
o
ellen Adressraums. St¨ßt der Prozess an diese Grenze, wird der beschrie-
o
bene Dump STORAGE PARAMETERS WRONG SET ausgel¨st und man kann si-
o
cher sein, dass wirklich noch mehr Speicher ben¨tigt werden w¨ rde.
o u
In einer solchen Lage bleiben noch einige M¨glichkeiten. Wir skizzieren sie
o
in der ungef¨hren Reihenfolge ihres Einsatzes:
a
¨
1. Uberpr¨fung der restlichen Parameter des Speichermanagements und
u
der SAP-Puffer, ob noch weiterer Speicher zur Verf¨gung gestellt wer-
u
den kann
¨
2. Uberpr¨fung des (ABAP-) Programm-Codes auf unn¨tige Speicheran-
u o
forderungen. Ein Beispiel, das hüfig zu finden ist, sind unn¨tig weite/
a o
große Selektionsbedingungen bei Datenbank-Abfragen. Pr¨zisere a
WHERE-Bedingungen verkleinern die internen Tabellen oftmals erheb-
lich.
¨
3. Ubergang zur einer 64-Bit-Plattform.

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
Diese letzte M¨glichkeit ist zweifelsohne mit dem gr¨ßten Aufwand ver-
o o
bunden. Dennoch finden sich in zunehmendem Maße Kundensysteme, in
denen die Gr¨ße eines User-Kontexts den virtuellen Adressraum auf 32-
o
Bit-Plattformen sprengt. Bei User-Kontexten in der Gr¨ße von 2 GB oder
o
gr¨ßer kann kein noch so elaboriertes Speichermanagement auf 32 Bit
o
Plattformen mehr helfen.
• TEXTENV INVALID
Von der Wortbedeutung her zeigt dieser Shortdump eigentlich einen Loca-
lefehler an, s. Abschnitt 4.3.2. Auf einer 32-Bit Plattform kann die Ursache
jedoch auch ein Adressraumproblem sein. In diesem Fall soll zum Fehler-
zeitpunkt eine Locale in den virtuellen Adressraum eingeblendet werden.
Dies ben¨tigt zwar normalerweise nur wenige 100 KiloByte an Speicher, es
o
kann allerdings trotzdem vorkommen, dass selbst f¨r diese geringe Spei-
u
chermenge zeitweise nicht mehr ausreichend Adressraum vorhanden ist.
Wenn also g¨ngige Localeprobleme ausgeschlossen werden k¨nnen, s. Ab-
a o
schnitt 4.3.3, sollte zur Verbesserung der Situation die Speicherkonfigu-
ration uberpr¨ft werden. Es kann dann versucht werden, die Summe von
¨ u
SAP Puffer und Extended Memory unter die vom jeweils eingesetztem
x
Betriebssystem bestimmte kritische Grenze zu konfigurieren.
In den Developertraces üßert sich dieser Fehler verk¨rzt wie folgt:
a u
Le
A Thu Apr 28 10:45:13 2005
A *** ERROR => TEXTENV_INVALID environment
A *** ERROR => Locale=‘en_US.ISO-8859-1’ Lang=‘E’
A *** ERROR => Country=‘ ’ CodePage=‘1100’.
pp

A TH VERBOSE LEVEL FULL
M ***LOG R68=> ThIRollBack, roll back ()
A
A Thu Apr 28 10:45:16 2005
sU

A Thu Apr 28 10:45:16 2005
A
A ABAP/4 Program SAPLOCS_CRM .
A Source LOCS_CRMU08 Line 119.
A Error Code TEXTENV_INVALID.
...
A Function DoSetTextEnv Line 219.
A Fehler beim Einstellen der Textumgebung.
Genaueren Aufschluss, ob tats¨chlich ein Speicherproblem in diesem Fall
a
die Ursache ist, kann ein Blick auf den zugeh¨rigen Shortdump und vor
o
allem in den STORAGE-Bereich der Transaktion ST02 geben, s. Abb. 3.13.
Wenn z.B. die Summe der Puffer und des Extended Memories (Parameter
em/address space MB f¨r das neue Speichermanagement oder Parameter
u
em/initial size MB f¨r das Standard-Verfahren) in den Bereich von 2 GB
u
auf alteren Linux-Versionen kommt, sollte versucht werden, wieder 50 bis
¨
100 MB an Adressraum freizumachen. Diese werden f¨ r die Linux Shared
u
Libraries gen¨tigt, die auch in diesem Bereich des Adressraums abgelegt
o
werden.

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
Bei neueren Linuxversionen, bei denen die Linux Shared Libraries nicht
an einer festen Stelle mitten im Adressraum eingeblendet werden, steht
theoretisch der komplette 3 GB User Space f¨ r Shared Memory Segmente
u
zur Verf¨gung. Praktisch allerdings m¨ssen nun zus¨tzlich zu den Shared
u u a
Libraries auch noch die anderen Speicherbereiche, wie Code- und Daten-
segmente, um den Adressraum f¨ r Shared Memory konkurrieren, da auf
u
32 Bit Systemen selbstverst¨ndlich immer noch die User Space Grenze von
a
3 GB besteht.
• SYSTEM NO ROLL
Dieser Shortdump wird ausgel¨st, sobald ein ABAP-Report mehr Speicher
o
auf einmal anfordert, als das System ihm zuteilen kann. Der Titel des
Dumps ist dabei etwas irref¨hrend, da er noch aus Zeiten stammt, in denen
u
noch kein Extended Memory im SAP-System zur Verf¨gung stand und
u
die Speicheranforderungen im Roll-Bereich realisiert wurden. Heutzutage
beschreibt er allerdings eine Limitierung im Extended Memory.
Der Dump gibt an, dass eine Speicheranforderung von 266338304 Bytes
(254 MB) nicht mehr erf¨llt werden konnte. Der Developertrace liefert
u
a
¨hnliche Informationen und dar¨berhinaus noch ein weiteres Indiz uber
u ¨
die Fehlerursache:

A
x
Le
A Tue Jul 5 20:36:25 2005
A Tue Jul 5 20:36:25 2005
A
pp

A ABAP/4 Program ZUSMEM1 .
A Source ZUSMEM1 Line 29.
A Error Code SYSTEM_NO_ROLL.
...
A Function ResizeString Line 876.
sU

A Die Speicheranforderung von 266338304 Bytes konnte nicht
A erf¨llt werden.
u
A

Der Fehler wurde in einer Funktion ResizeString ausgel¨st, was auf Strin-
o
goperationen zum Zeitpunkt des Abbruchs schließen l¨sst. Diese Operation
a
ist auch die Ursache des Shortdumps. Er wird ausgel¨st, wenn ein Report
o
zu viel Speicher auf einmal anfordert, was gerade bei sehr großen Strings
leicht vorkommen kann. Die Menge an Speicher, die auf einmal angefordert
werden kann, wird uber den Parameter ztta/max memreq MB eingestellt.
¨
Dieser war in ¨lteren Releases daf¨ r gedacht, um eine Fragmentierung des
a u
Extended Memory bei großen Speicheranforderungen zu verhindern.
Auf 32-Bit Systemen ist der Defaultwert noch auf 250 MB eingestellt, auf
64 Bit Systemen jedoch schon auf 2048 MB erweitert. Tritt dieser Fehler
auf, kann er durch Erh¨hen der Quota normalerweise behoben werden.
o
Eine Besonderheit ist allerdings bei Stringoperationen noch zu beachten:
Speicher f¨r Strings muss immer zusammenh¨ngend allokiert werden, was
u a
auf 32 Bit Systemen dazu f¨hren kann, dass eine Speicheranforderung nicht
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
pp
sU

Abb. 3.20. Kurzdump SYSTEM NO ROLL

erf¨llt werden kann, obwohl eigentlich noch gen¨gend Adressraum zur
u u
Verf¨gung steht. Dies liegt dann daran, dass keine ausreichend große L¨cke
u u
im Adressraum gefunden werden konnte, um den angeforderten Speicher-
bereich an einem St¨ck ablegen zu k¨nnen.
u o
Mit diesen typischen Problemsituationen schließen wir die Behandlung der
32-Bit-Plattformen ab und wenden uns den Plattformen zu, die f¨r neuere
u
SAP-Releases wohl den Standard darstellen werden.

3.3.4 64-Bit-Plattformen

Im Kontext dieses Kapitels uber die Speicherverwaltung zeichnen sich 64-Bit-
¨
Systeme prim¨r durch die Verf¨gbarkeit eines deutlich gr¨ßeren virtuellen
a u o
Adressraums aus. Diese Verf¨ gbarkeit ist aber zun¨chst nur in der Hardware
u a
gegeben. Um von der Erweiterung Gebrauch machen zu k¨nnen, bedarf es
o

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
der Unterst¨tzung durch das Betriebssystem und durch die Anwendung. Wir
u
skizzieren kurz die verschiedenen Kombinationsm¨glichkeiten, die in diesem
o
Zusammenhang denkbar sind:
• Die Ausnutzung von 64-Bit Hardware erfordert auch ein 64-Bit Betriebs-
system. Eine 64-Bit-f¨hige Anwendung auf einem 32-Bit Betriebssystem
a
s¨he weiterhin nur einen 4 GB großen virtuellen Adressraum.
a
• Die Umkehrung macht demgegen¨ ber durchaus Sinn: Ein 64-Bit Betriebs-
u
system erlaubt nicht nur die Ausf¨hrung von 32-Bit Anwendungen, son-
u
dern kann diesen auch einen gr¨ßeren Adressraum bieten. Als Beispiel
o
kann hier die x86 64 Plattform dienen. Auf dieser Plattform kann ein
64-Bit Linux der Anwendung volle 4 GB an virtuellem Adressraum zuge-
stehen, da es nun nicht mehr das obere 1 GB im 4 GB-Bereich f¨r kernelin-
u
terne Strukturen verwenden muss. F¨r das SAP-System bedeutet das, dass
u
¨
ohne Anderungen an der SAP-Software ein Wechsel zu der oben genann-
ten Plattform mit einem 64-Bit Linux schon 1 GB mehr an z.B. Extended
Memory bringt. In vielen F¨llen reicht dies schon aus, um die großen User-
a
Kontexte zu verarbeiten.

a x
• Die Kombination eines 64-Bit f¨higen Betriebssystems und einer 64-Bit
a
f¨higen Anwendung stellt aber nat¨rlich den gr¨ßten virtuellen Adres-
u o
sraum zur Verf¨gung. Auf einer Intel Itanium Plattform sind es z.B.
u
Le
5 ∗ 261 Byte und auf x86 64 derzeit 512 GB. Damit sind aus SAP-Sicht
zumindest in den n¨chsten Jahren auch die gr¨ßten User-Kontexte zu
a o
bew¨ltigen.
a
pp

Unter Linux stehen f¨r SAP derzeit vier dieser vollen 64-Bit-Plattformen zur
u
Verf¨gung: IBM zSeries, IBM POWER, Intel Itanium und AMD, bzw. Intel
u
x86 64. Diese breite Basis macht die Frage notwendig, welche Auswirkungen
ein Wechsel auf eine 64-Bit-Plattform aus Sicht des SAP-Systems mit sich
sU

bringt.
Eine der ersten Fragen, die in diesem Zusammenhang gestellt werden, ist
die Frage nach der Wahl des Speichermanagements. Der große Adressraum ei-
nes 64-Bit-Systems macht sicherlich die Wahl der Standard-Implementierung
es/implementation = std m¨glich. Die Adressraum-schonendere map-Vari-
o
ante muss nicht zwingend eingesetzt werden. W¨hrend beide Formen auch die
a
Verwaltung großer User-Kontexte erlauben und somit keine gr¨ßenm¨ßigen
o a
Einschr¨nkungen mehr kennen, gibt es dennoch grunds¨tzlich Unterschiede
a a
zwischen den Varianten:
• Die std-Variante ist f¨r Administratoren anderer Unix-Systeme h¨uﬁg ver-
u a
trauter.
• Auf der anderen Seite bietet derzeit nur die map-Variante ein Zero Ad-
ministration Memory Management. Hier kann man aber argumentieren,
dass bei 64-Bit-Umgebungen die Parametrisierung nur eine untergeord-
nete Rolle spielt. Die Parameter k¨nnen initial bereits so eingestellt wer-
o
den, dass keine – oder nur noch minimale – Anpassungen im laufenden
Betrieb notwendig werden.

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 k.
c
c u -tr a c k ¨
• Uber die Bedienung hinaus w¨ren Performanceunterschiede in den beiden o c u - t r a c
a
Implementierungen eine deutlicheres Entscheidungskriterium. Hier zeigen
sich aber bisher auf keiner Plattform signifikante Laufzeitunterschiede zwi-
schen map und std.

Es l¨sst sich also sagen, dass die Wahl des Speichermanagements derzeit auch
a
eine Frage des Geschmacks ist.
Abgesehen von der 32-Bit-Plattform, wo nur noch map zum Einsatz kom-
men sollte, ist ein genereller Favorit also nicht erkennbar.
¨
Die Hinweise zu weiteren typischen Anderungen in 64-Bit-Umgebungen,
die sich nun anschließen, beziehen sich deshalb auf beide Implementierungs-
varianten. Sie erg¨nzen die Aussagen auf S. 143.
a
Der wesentliche Vorteil einer 64-Bit-Plattform ist der große virtuelle
Adressraum. Aus SAP-Sicht m¨ssen deshalb vor allem em/address space MB
u
in der map-Implementierung und em/initial size MB in der std-Variante
vergr¨ßert werden. Der Parameter ztta/roll extension muss ebenfalls in
o
beiden Varianten angemessen groß sein. Werte f¨ r einen Großteil der weiteren
u
Parameter, wie em/max size MB in der SAP-Speicherverwaltung folgen aus

x
diesen Setzungen und der physischen Ausstattung der Maschine. Die Heap-
Quotas, die durch die Parameterfamilie abap/heap area * gesetzt werden,
Le
sind ggf. auch anzupassen.
Neben dem User-Memory profitieren aber auch die SAP-Puffer vom großen
virtuellen Adressraum. Insbesondere der Programmpuffer, die Nametab- und
die Tabellenpuffer k¨nnen deutlich vergr¨ßert werden.
o o
pp

Auf der anderen Seite muss beachtet werden, dass die Summe aus physi-
schem Speicher und Swap-Bereich nun kleiner ist als der virtuelle Adressraum.
Das ist eine Umkehrung der 32-Bit-Situation. Im 64-Bit-Fall wird damit die
physische Ausstattung der Maschine zur Restriktion. Zu den Folgerungen, die
sU

daraus zu ziehen sind, geh¨ren:
o

• Die Gr¨ßenanforderungen des SAP-Systems, wie sie durch die Konfigura-
o
tion gegeben sind, sollten nicht um Gr¨ßenordnungen die physische Aus-
o
stattung der Maschine ubertreffen. Es besteht dann u.a. die Gefahr, dass
¨
es zu erh¨hter Paging-Aktivit¨t kommt.
o a
• Das Paging des Systems muss deshalb zumindest in der Anfangsphase
genauer beobachtet werden.
• Als notwendige Voraussetzung f¨r das Paging muss hinreichend viel Swap-
u
Space installiert werden. Dies best¨rkt noch einmal die Aussage, die auf
a
S. 165 gemacht wurde.
¨
Wie ein SAP-System, das den oben genannten Uberlegungen gefolgt
ist, auf verschiedenen 64-Bit-Plattformen aussieht, zeigen wir in den absch-
ließenden Listings der maps-Dateien von SAP-Workprozessen. Sie zeigen die
¨ ¨
Anderungen, die mit dem Ubergang zu 64-Bit-Plattformen einhergehen, schon
sehr deutlich. Als Vergleich kann jeweils das entsprechende Listing auf S. 161
dienen.

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
Wir beginnen mit einer Zwischenform eines 64-Bit-Systems, einem AMD-
64 basierten System, das ein 32-Bit SAP-System auf einem 64-Bit Linux-
System zeigt. Diese Kombination ist keineswegs exotisch, da sie immer dann
eintritt, wenn die ublichen 32-Bit-Executables der SAP auf ein vollst¨ndiges
¨ a
64-Bit-System kopiert werden. Diese Form der Portierung ist zweifelsohne
die einfachste. Sie bietet, wie das folgende Listing zeigt, einen Zugewinn von
1 GB an virtuellem Adressraum, ohne die SAP-Programme erneut zu compi-
lieren: Die Grenze bei 0xc0000000, die noch auf S. 161 vorhanden war, ist nun
weggefallen, da der 64-Bit-f¨hige Betriebssystemkernel nicht mehr in den un-
a
teren 4 GB auftreten muss. Extended Memory oder SAP-Puﬀer k¨nnen damit
o
um 1 GB wachsen.

08048000-08eae000 r-xp 08:13 109 disp+work
08eae000-094c2000 rwxp 08:13 109 disp+work
094c2000-09e6c000 rwxp 00:00 0
...........
5567b000-55784000 r-xp 08:02 26502 tls/libc.so.6
55784000-5578c000 rwxp 08:02 26502 tls/libc.so.6
5578c000-55790000 rwxp 00:00 0
55790000-557f7000
557f7000-5abe4000
5abe5000-5abe6000
rw-s
rw-s
rw-s
x
00:06
00:06
00:06
286523397
290095110
198934532
/SYSV000037b1 (deleted)
/SYSV00003782 (deleted)
/SYSV0382be84 (deleted)
Le
5abe6000-5ac38000 r-xp 08:13 107 dboraslib.so
5ac38000-5ac71000 rwxp 08:13 107 dboraslib.so
5ac71000-5ac7a000 rwxp 00:00 0
pp

5ac7a000-5b53f000 r-xp 08:16 23959 libclntsh.so.9.0
5b53f000-5b579000 rwxp 08:16 23959 libclntsh.so.9.0
5b579000-5b588000 rwxp 00:00 0
5b588000-5b589000 r-xp 08:16 23961 libwtc9.so
5b589000-5b58b000 rwxp 08:16 23961 libwtc9.so
sU

...........
5b5d6000-5b6be000 rw-s 00:06 290160648 /SYSV0000377a (deleted)
............
5d39f000-7d39f000 rw-s 08:02 95615 /dev/shm/SAP_ES_42_000
7d39f000-7d3e7000 rwxp 00:00 0
7d3e7000-816a9000 rw-s 00:06 293896206 /SYSV000037a0 (deleted)
............
9f2c4000-9f3a0000 r-xp 08:13 56 libsapsecu.so
9f3a0000-9f3b1000 rwxp 08:13 56 libsapsecu.so
9f3b1000-9f3b3000 rwxp 00:00 0
9f3b3000-9f423000 r-xp 08:02 98659 locale-archive
9f423000-9f429000 r-xp 08:02 23079 en_US/LC_COLLATE
9f429000-9f455000 r-xp 08:02 23078 en_US/LC_CTYPE
9f455000-9f855000 rw-s 00:06 294125589 /SYSV0000379a (deleted)
9f855000-9f857000 rwxp 00:00 0
9f857000-9f858000 rw-s 00:06 294158358 /SYSV000037b2 (deleted)
9f858000-9f8d3000 rwxp 00:00 0
fffe1000-ffffe000 rwxp 00:00 0
ffffe000-fffff000 ---p 00:00 0

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
Die Angaben in der letzten Spalte (dboraslib.so)zeigen auch, dass es sich
hier um ein Oracle-basiertes System handelt.
Etwas umfangreicher wird die Ausgabe bei einem System, bei dem sowohl
das Betriebssystem als auch die Workprozesse der SAP f¨r 64-Bit compiliert
u
wurden. Als Beispiel f¨r ein solches volles 64-Bit-System zeigen wir ein SUSE
u
SLES 9 auf einer Intel Itanium-Maschine.

00000000-00004000 r--p 00000000 00:00 0
2000000000000000-200000000002c000 r-xp ld-2.3.3.so
200000000002c000-2000000000030000 rw-p
2000000000038000-2000000000040000 rw-p ld-2.3.3.so
............
2000000000114000-2000000000490000 r-xp dw_xml.so
2000000000490000-2000000000494000 ---p dw_xml.so
2000000000494000-20000000004e0000 rw-p dw_xml.so
20000000004e0000-20000000008f8000 r-xp dw_xtc.so
20000000008f8000-2000000000900000 ---p dw_xtc.so
2000000000900000-2000000000928000 rw-p dw_xtc.so
2000000000928000-2000000000a9c000 r-xp dw_stl.so

x
2000000000a9c000-2000000000aa8000 ---p
2000000000aa8000-2000000000ac8000 rw-p
2000000000ac8000-2000000000c10000 r-xp
dw_stl.so
dw_stl.so
libstdc++.so.5.0.6
Le
2000000000c10000-2000000000c18000 ---p libstdc++.so.5.0.6
2000000000c18000-2000000000c28000 rw-p libstdc++.so.5.0.6
2000000000c28000-2000000000c3c000 rw-p
pp

............
2000000000f34000-2000000000f94000 rw-p
2000000001000000-2000000001080000 r--s /SYSV000037b1 (deleted)
2000000001080000-20000000010fc000 rw-p
2000000001100000-20000000051dc000 rw-s /SYSV00003782 (deleted)
sU

20000000051dc000-200000000532c000 r-xp dbadaslib.so
200000000532c000-20000000053ac000 rw-p dbadaslib.so
20000000053ac000-20000000053fc000 rw-p
2000000005400000-2000000005404000 rw-s /SYSV0382be97 (deleted)
............
2000000005490000-2000000005498000 rw-p
2000000005500000-2000000005504000 rw-s /SYSV00003779 (deleted)
............
2000000007e74000-2000000103a74000 ---p
2000000103a74000-2000000107a74000 rw-s /dev/shm/SAP_ES_19_000
2000000107b00000-200000010a4b8000 rw-s /SYSV000037b6 (deleted)
............
20000001284a4000-20000001284b0000 rw-p
4000000000000000-4000000002ae8000 r-xp disp+work
6000000000004000-60000000005c0000 rw-p disp+work
60000000005c0000-6000000001618000 rw-p
600007ffffffc000-6000080000000000 rw-p
60000fffffff4000-60000fffffffc000 rw-p
a000000000000000-a000000000020000 ---p

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
Auﬀallend sind zun¨chst die merklich l¨ngeren virtuellen Adressen. Die Dar-
a a
stellung muss denn auch stark verk¨rzt werden, um nicht den Seitenrahmen
u
zu sprengen. Die Spalten 3, 4 und 5, die in der vollen Darstellung unter
/proc/<pid>/maps die Lage im Dateisystem angeben, wurden hier ausge-
lassen. Die grunds¨tzliche Gestalt bleibt aber dennoch zu erkennen. Ge¨ndert
a a
hat sich unter anderem die Lage der Executables, die nunmehr an der Stelle
0x4000000000000000 beginnen. Der Bereich f¨r den gemeinsam genutzten
u
Speicher startet bei 0x2000000000000000. Damit sind ca. 2 ∗ 1018 Byte f¨r u
gemeinsame Speicherbereiche nutzbar. Der Linux-Kernel selbst ist ab der
Adresse 0xa000000000000000 eingeblendet und beansprucht den gesamten
Raum bis zum Ende des virtuellen Adressraums bei 0xffffffffffffffff.
Die Gr¨ße des User-Spaces liegt in dieser Architektur damit bei
o
0xa000000000000000 - 1, d.h. bei ca. 1019 Byte. Das sollte auch f¨r speicher-
u
intensive Anwendungen, wie das SAP-System, in den n¨chsten Jahren gen¨ -
a u
gend Platz bieten.

x
Le
pp
sU

Saponlinux

Weitere ähnliche Inhalte

Ähnlich wie Saponlinux

Saponlinux