Freigeben von SAP-Speicher gegenüber dem Betriebssystem 
Beim Freigeben von Speicher, der im SAP Erweiterungsspeicher (EM) von SAP-Komponenten allokiert wurde, bleibt der Speicher gegenüber dem Betriebssystem (Operating System, OS) im Zustand 'belegt'. Das Betriebssystem behandelt aus SAP-Sicht freigegebenen EM-Speicher genauso wie Speicher, der aktuell durch SAP-Komponenten in Verwendung ist und würde die betreffenden Speicherseiten (Pages) bei einem Speicherengpass auf die Auslagerungsdatei (Swap-Space, Paging-File des Betriebssystems) schreiben und vor erneuter Verwendung durch SAP-Komponenten wieder von dort einlesen.
Sie können durch Profilparameter steuern, dass der Speicher gegenüber dem Betriebssystem ab einer gewissen Schwelle freigegeben wird.
Integration
Der Nachteil des bisherigen, oben beschriebenen Verhaltens kommt bei einem Speicherengpass zum Tragen, weil dann das Betriebssystem nicht weiß, dass der Inhalt freigegebener Pages obsolet ist und den Inhalt auf das Paging-File sichern muss, bevor die physischen Pages für andere Zwecke verwendet werden können. Bei erneuter Verwendung muss das Betriebssystem nicht nur leere Seiten bereitstellen, sondern auch obsolete Inhalte vom Paging-File einlesen.
Voraussetzungen
Die Funktionalität wird durch einen Kernelpatch für SAP-Kernel 4.6D, 6.20 und 6.40 bereitgestellt. Die Profilparameter kommen durch Supportpackages in das System (Transaktion RZ11), Sie können diese aber auch verwenden, wenn Sie das erforderlichen Supportpackage nicht installiert haben.
Das hier beschriebene Verfahren ist nicht wirksam, wenn der Parameter ES/TABLE = SHM_SEGS gesetzt ist. In diesem Fall wird bisher schon Speicher gegenüber dem Betriebssystem freigegeben.
Funktionsumfang
Sie können das Freigeben von Speicher gegenüber dem Betriebssystem abhängig vom Füllstand des Extended Memory steuern und die damit verbundenen Nachteile minimieren.
Speicher, der oberhalb einer einstellbaren Schwelle im Extended Memory liegt, wird immer gegenüber dem Betriebsystem freigegeben. Sobald diese Schwelle überschritten wird, kann für eine einstellbare Zeit auch Speicher unterhalb dieser Schwelle gegenüber dem Betriebssystem freigegeben werden.
Darüber hinaus ist es möglich, beim Freigeben von EM-Blöcken einen oberen Teil des EM-Blocks mit einstellbarer Größe auch gegenüber dem Betriebssystem freizugeben.
Das Default-Verhalten beim Freigeben des Extended Memory ist mit dem bisherigen Verhalten identisch, d.h. es wird kein Speicher gegenüber dem Betriebssystem freigegeben.
Das Freigeben von Speicher gegenüber dem Betriebssystem wird durch folgende Parameter aktiviert:
es/disclaim_threshold_MB (Default: 0, unwirksam) gibt die Schwelle an, bei deren Überschreitung Memory gegenüber dem Betriebssystem freigegeben wird.
es/disclaim_coasting_time_alloc (Default: 0, unwirksam)
es/disclaim_coasting_time_free (Default: 0, unwirksam) gibt die Nachlauf-Zeit in Sekunden an, wie lange nach Überschreitung der Schwelle Speicher auch unterhalb der Schwelle beim Allokieren bzw. beim Freigeben gegenüber dem Betriebssystem freigegeben wird.
es/blockdisclaimsize_KB (Default: 0, unwirksam) gibt die Größe des oberen Teil eines EM-Blocks an, der beim Freigeben auch gegenüber dem Betriebssystem freigegeben wird. Dieser Parameter verbindet den Vorteil kleinerer EM-Blöcke (em/blocksize_KB) hinsichtlich Hauptspeicherbedarf mit dem Vorteil größerer EM-Blöcke hinsichtlich Performance.
es/freelist_compactor (Default: 1) sollte nicht 0 sein, damit das oben beschriebene Verfahren voll wirksam werden kann.
Aktivitäten
Spielen Sie den erforderlichen Kernel-Patch ein. Der Patch-Text lautet 'CST Patch Collection 15 2004'.
Setzen Sie die beschriebenen Profilparameter wie gewünscht.
Beispiel
em/blocksize_KB = 4096 (4MB, default bei 64-bit)
es/blockdisclaimsize_KB = 2048 (2MB, 1/2 von em/blocksize_KB)
es/disclaim_threshold_MB = 12000 (OS-Speicherfreigabe bei >12GB)
es/disclaim_coasting_time_alloc = 300 (Nachlauf OS-Freigabe vor Alloc)
es/disclaim_coasting_time_free = 60 (Nachlauf OS-Freigabe bei Free)