本系列基于 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)