本系列基於 SAP S/4 HANA version 1709 - On Premise
本文基於 官方幫助文檔 SAP Memory Management (BC-CST-MM) (https://help.sap.com/viewer/f146e75588924fa4987b6c8f1a7a8c7e/7.5.13/en-US/49325d4ee93934ffe10000000a421937.html)
目錄
一、SAP 內存管理系統 的相關功能 (Functions of the SAP Memory Management System)
1.6 工作進程的虛擬內存空間(Virtual Address Space of a Work Process)
1.7 爲操作系統釋放SAP內存 (Release of SAP Memory for the Operating System)
二、特定操作系統下的內存管理(Platform-Specific Description of Memory Management)
本文目的(Use)
- 介紹了SAP內存管理系統(Memory Management System,MMS) 並解釋了相關profile參數(profile parameters),及適合用戶系統的最佳設置；
- 介紹了內存管理的基本功能，最佳的配置取決於使用的操作系統、硬件和網絡資源、及系統的主要用途；
- 介紹了硬件和操作系統的需求，如何對內存進行監控，如何定位和解決相關問題。
一、SAP 內存管理系統 的相關功能 (Functions of the SAP Memory Management System)
1.1 基本介紹
一個ABAP程序通常運行在一個工作進程(Work Process)中(事務碼 SM66或SM50 可查看 Work Process 的狀態)，Work Process 的運行需要內存，由操作系統分配內存，分配多少內存取決於 Work Process 的類型，及操作系統特點(在Linux系統中，以Linux進程體現，用 ps -ef|grep sap 查看)，
ABAP程序 在 Work Process 中運行時，會直接訪問 用戶上下文(User context) 作爲 ABAP程序 的上下文環境，User Context 的大小 會根據需要自動增加，其中的數據包括了 Extended Memory 中的內部表(internal tables)，因此你可以訪問User Context 中的所有數據，但 extract 和 export to memory 類型的數據仍保留在paging中（注：這段內容有些超前，可以在看完本文後回頭在看)
在 Work Process 執行每個 ABAP程序時，需要訪問兩種數據：用戶相關數據(User-specific Data) 和 用戶無關數據(Non-user-specific data)
1) User-specific Data 包括了 ABAP變量、內部表(Internal tables) 等信息，內存調度器(Dispatcher) 會在每個會話步驟(Dialog step) 前 將 用戶特定的數據(User-specific Data) 顯示給 Work Process 供其操作，這個操作被稱爲 Roll-In； 在 Dialog step 結束後，會從Work Process中隱藏這些數據，這個操作被稱爲 Roll-out。
2) Non-user-specific Data 包括了 程序代碼(Program code)、棧(Stack)、靜態數據(Static data)、SAP 緩存(SAP buffers)、ABAP程序(ABAP programs)、表緩存(Table buffers) 等數據，這些數據Work Process可以一直訪問 ，無需每次去Roll-In 和 Roll-Out
1.2 內存管理的基本概念
(注：此處介紹的更多的時操作系統層的內存管理機制，感興趣的可以去看《深入理解Linux虛擬內存管理》)
-
虛擬內存(Virtual Memory) 所有支持SAP的操作系統均支持虛擬內存，一個系統進程(Process) 能使用分配給他的地址空間(Address Space)，這些 Address Space 在操作系統進程間，是相互獨立的
-
尋址空間(Address Space) 在64位操作系統中，內存地址範圍位 0 ~ 2^64-1
-
內存分配(Memory Allocation) 內存分配分兩步執行：1.在 Virtual Memory 中分配一個段(Segment); 2.將 Virtual Memory Segment 映射到物理內存 Segment 中。
-
Virtual Memory 又分爲兩類：
-
本地進程內存(Local Process Memory) 此類型的內存僅供當前Process使用，Process直接調用API即可申請，無需關心分配的細節。
-
共享內存(Shared Memory) 不同的 Process 可以訪問同一內存，這段內存被稱爲 Shared Memory，不同於Local Process Memory，Shared Memory 內存的分配對 Process 而言是不透明的，且不同的操作系統會使用不同的處理方法、一般會創建一個對象用於管理這些用於共享的物理內存，Process從這個對象中映射全部或部分的內存地址空間(Adress Space)（注： SAP的擴展內存(Extend Memory) 就是一種 Shared Memory，下面有說明）。
1.3 SAP的內存的類型
內存管理系統會分配內存給 Work Process，主要分爲兩類：擴展內存(Extended memory) 和 私有內存(Private memory, 又稱 堆內存(heap memory))，並通過相關的Profile參數控制每個內存的大小：
擴展內存(Extend memory) 大部分的 User Context 會存儲在 Extended Memory 中，對於的內存頁(Page)由SAP系統直接管理，而不是由操作系統管理。每個User context 所有的 內表(internal tables) 和 ABAP變量 均會完整的存儲在 Extended memory 中，從而可以被直接尋址訪問，由於 Extended Memory 是一種 Shared Memory，因此Work Process 訪問 internal tables 和 lists 不再需要進行復制和 input/output 操作，從而保證了較快的訪問速度和較低的CPU佔用。
私有內存/堆內存(Private Memory/Heap Memory) 如果 Extended Memory 被完全使用，或者超過了Work Process的使用限制，Work Process 將使用 Private Memory,由於這些內存是 在系統進程(process)間是相互獨立的，因此通常也被稱作 heap memory，此時user context不能被其他的 work process 處理，此時又分爲兩種內存模式：PRIV memory 和 PROC memory
需注意的是，只有 Dialog類型的 Work Process纔會在 Extend Memory 耗盡後，分配Private Memory， 其他類型(Background, Update, Spool) 分配的直接就是 Private Memory，這是因爲這些類型的 Work Process 不涉及上下文切換(context switch)，因此給他們分配 extended memory 並沒有什麼額外的好處。
此外，需注意 SAP內存管理系統需要同時使用 swap sapce 和 main memory，由於 全部的內表和列表(Full-sized internal table and lists) 均會存儲在 virtual address space中， 因此swap space的需求會不斷增加，而爲了避免swap space請求導致過多的操作系統分頁(paging)操作，main memory 的需求也會不斷增加。(注：內容超前，請閱讀完全文後重新閱讀此段)。
PRIV memory 如果給某個Work Process 分配了 Private memory ，該 Work Process 將運行在 PRIV 模式，此時只能處理當前的 User context 直到請求結束，在此期間，其他用戶將不能使用該Work Process；如private memory被耗盡(取決於profile: abap/heaplimit 的限制)，那麼當前的user context將會被關閉，此Work process 會被自動重啓避免被鎖死，重啓後的 Work Process 可再次供其他用戶使用。
如果處於 PRIV模式的 work process 過多，則會導致系統性能降低，profile參數 rdisp/wppriv_max_no 用於定義最大允許多少Work Process 進入 PRIV 模式 ，SAP默認值爲 Work Process 總數 減 5 ，且最少爲1個；此外通過profile參數 rdisp/max_priv_time(默認爲600秒) 控制Work Process 可處在 PRIV模式的最長時間，超過這個時間將會被重啓，如需修改這些參數來解決性能問題，修改前請務必諮詢SAP的意見。
PROC memory PROC Memory 用於存儲未綁定到特定 User Context 的數據。 與 PRIV Memory 不同，分配 PROC Memory 不會導致 進程(Process) 被 特定的 User Context 獨佔。
(注：簡單來說，當Extended Memory 不足時，SAP會分配 Heap Memory，對系統性能影響較大， 在用事務碼 ST02 查看性能時，我們應關注 Heap Memory 一行，此處不應該有長時間的內存佔用。)
1.4 用戶上下文(User Context)
當SAP用戶執行一個事務碼時，實際上是運行了一個ABAP程序，Work Process會處理這個請求，處理時需獲取對應的User Context；每個SAP用戶最多允許建立16個SAP GUI窗口，及對應數量的ABAP會話(ABAP Session)。
每個用戶都有自己的 User context，包括了 該用戶的用戶信息、授權信息、ABAP會話(術語叫做:emode) 對應的上下文，每個ABAP會話通常又由多個內部會話(internal sessions, 術語叫做 imode)組成。
User Context 儲存在 Extend Memory 中，這樣可以實現快速的上下文切換 (注：我的理解是，當將用戶會話分配給某個Work Process執行時，這個Work Process可以快速的從Extend Memory 獲取 User Context 的訪問地址，而 PRIV Mode下，需要拷貝User Context到 Work Process 的Private Memory中，因此性能很差)
具體結構如下：
1.5 工作進程(Work Process)
一個SAP應用服務器(SAP Application Server, AS) 可以從處理從不同類型的客戶端(如SAPGUI、後臺任務，接口等)發起的請求，通常使用調度臺(Dispatcher)來獲取請求並分配給一個Work Process 去處理；
Work Process 主要有如下類型(可以在SM50/SM66的"類型(Type)"列查看) ：
| 類型 | 用途 | |
| 對話(Dialog) |
執行一個 Dialog程序(ABAP) Executes dialog programs(ABAP) |
|
| 更新(Update) |
處理異步數據庫請求(由 Dialog Work Process 的 COMMIT WORK 聲明確認) Asynchronous database changes (is controlled by a COMMIT WORK statement in a dialog work process) |
|
| 後臺(Background) |
執行定時或其他事件觸發的後臺作業 Executes time-dependent or event-driven background jobs |
|
| 假脫機(Spool) |
爲打印輸出，處理相關請求 Formatting spool request for printing |
Dispatcher 是 Application Server 的核心，當Dispatcher 啓動後，會啓動Work Process，可以通過 RZ10 查看當前實例的Profile 的“Basic maintenance”，去查看和修改 每種類型Work Process的數量。
一個 Work Process 通常由如下部分組成：屏幕處理器(Screen Processor)、ABAP解釋器(ABAP Interpreter)、數據庫接口(Database Interface)、任務處理程序(Task Handler that calls these programs)
1.6 工作進程的虛擬內存空間(Virtual Address Space of a Work Process)
（注：此處主要是解釋 Linux的內存管理機制，可以參考這篇文章：Linux內存管理機制（最透徹的一篇）(https://blog.csdn.net/qq_19525389/article/details/81430701)
對於 64位的操作系統，Virtual Address Space 可使用的地址範圍爲 0 到 2^64-1 (有些資料說是到 2^48-1，高16位是預留做符號擴展，不過對目前的硬件水平來說是足夠使用的)
Virtual Address Space 一般是由 文本段(Text segment)、數據段(Data segment)、動態擴展的 堆(heap)、動態擴展的 棧(Stack)組成，隨着程序的運行，Heap 從底向上佔用內存，Stack 自頂向下佔用內存。
SAP對 Work Process 做了一些特殊的內存管理：每個 Work Process 會預留兩個區域：1) 在 Heap 和 Data Segment 之間預留了一段用於 Private Memory，大小可以通過參數控制；2) 在 Heap 和 Stack 之間預留了很大一塊地址空間，用於映射Extended memory，具體如下圖：
1.7 爲操作系統釋放SAP內存 (Release of SAP Memory for the Operating System)
介紹(Use & Integration)
當分配給SAP組件(components)的 Extend Memory 空間被 釋放(Release) 時，操作系統仍認爲其處於佔用狀態，操作系統處理已釋放的 Extended Memory 空間 和 處理 被 SAP components 佔用的 Extended Memory 空間的方法完全一致（注：我的理解是，操作系統沒法區分出來 Extend Memory 中的哪些內存被釋放，因此也不會分別對待)。如果物理內存耗盡，操作系統會將這些 內存分頁(Memory Page) 寫入 分頁文件(Paging File) 中(這個文件位於 linux存儲的 swap分區)，如果這些 Memory page 被再次使用，則操作系統會在使用前將其從 paging file 中取回 ，這類操作通常被稱爲 分頁(Paging) (具體的原理和影響可以參考 Linux Swap交換分區介紹總結 - 瀟湘隱 https://www.cnblogs.com/kerrycode/p/5246383.html)
如果內存即將耗盡，以上的釋放過程會造成明顯的不利影響：操作系統並不知道要釋放的 Memory Page 是不是還在使用中，但此時不得不將一些 Memory Page 寫入 Paging File 中，從而釋放出一些物理頁(Physical Pages) 用於滿足新的需求；如果這些被寫入 Paging File 的 Memory Page 被再次使用，操作系統需要爲其準備空的物理空間，並將這些Memory Page 從 Paging File 中取回(注：這種情況會造成大量不必要的資源消耗)。
以上過程的前提是 Profile 參數 “ES/TABLE” 設置爲 "STD_UNIX"，如果設置爲了 "SHM_SEGS"則以上的過程將不會發生，在這種情況下，已經爲操作系統釋放了內存(注：RZ11中對此的解釋爲 該參數僅對AIX系統有用，其他系統請勿更改，估計是AIX特有的內存管理機制，不再研究)
控制功能點(Feature)
我們可以依據Extended Memory 使用的頻繁程度，決定操作系統可釋放的內存總量；從而儘可能的減少因爲Extended Memory佔滿導致的問題；
我們可以給 Extended Memory 設置上限，超過這個上限的內存會被操作系統釋放；但在某些特殊的時間段，即使沒超過上限，操作系統也會釋放 Extended Memory，涉及參數如下：
1) es/disclaim_threshold_MB (默認: 0,未激活) 當Extended Memory 超過這個限制時，會爲操作系統釋放；
2) es/disclaim_coasting_time_alloc (默認: 0, 未激活, 單位:秒) 當 Extended Memory 超過 參數 es/disclaim_threshold_MB 的限制時，將 EM Block 寫入 swap space 的最大時間, 然後這些block 將被釋放給操作系統；
3) es/disclaim_coasting_time_free (默認: 0, 未激活, 單位:秒) 當 Extended Memory 超過 參數 es/disclaim_threshold_MB 的限制時，必須等待一段時間後，纔開始釋放 EM Block；
當 Extended Memory 塊(EM Blocks) 被釋放時，可以將這個EM Block上方的部分內存也同時釋放，具體的大小可以通過參數控制；對於內存需求而言，他結合了小 EM Blocks(由 em/blocksize_KB 參數定義) 的優點，並且具備大的EM Blocks 的性能，參數如下：
1) es/blockdisclaimsize_KB (默認: 0, 未激活) 定義了 當 EM Block 被釋放時，其上方指定大小的部分也會同時被釋放；
此外，需注意參數：es/freelist_compactor (默認: 1) 這個參數必須不爲0，否則上面所描述的內存釋放機制不會完全生效。
釋放內存的默認過程和之前描述的過程一致，這是說，不會爲操作系統釋放任何內存(注：這段完全沒看懂。。原文：The default procedure when memory is released is the same as the procedure described earlier, that is, no memory is released for the operating system.)。
二、特定操作系統下的內存管理(Platform-Specific Description of Memory Management)
此處介紹了 UNIX、Windows 及 IBM i系列 相關的內存管理特點，由於我們用的是linux，因此跳過此章節
接下來的章節，我們瞭解如下章節：
三、內存管理的相關Profile參數(Profile Parameters of Memory Management)
四、內存監控(Monitoring the Memory Management System)
五、定位和解決問題(Identifying and Correcting Problems)