SAP内存分页机制解析与MEMORY_NO_MORE_PAGING错误处理

1. 理解ST22短转储与MEMORY_NO_MORE_PAGING错误

当SAP系统突然抛出MEMORY_NO_MORE_PAGING错误时，很多管理员的第一反应是"服务器内存不够了"。但实际情况往往复杂得多——这其实是SAP特有的分页机制（Paging）达到上限的表现。我处理过数十起这类案例，发现90%的问题都源于对PG_SHM和PG_MAXFS参数的误解。

SAP的分页机制不同于操作系统的虚拟内存。它采用双层存储结构：

• 第一层是共享内存（Shared Memory），相当于高速缓存
• 第二层是文件系统分页（Filesystem Paging），作为溢出区

当程序需要内存时，SAP会优先使用共享内存。当共享内存耗尽，系统开始将不活跃的内存页交换到文件系统分页区。MEMORY_NO_MORE_PAGING错误意味着这两个区域都已耗尽——就像同时塞满的仓库和临时堆放区。

2. SAP分页机制深度解析

2.1 内存分配的核心流程

SAP工作进程获取内存的路径是这样的：

1. 首先尝试从共享内存池分配
2. 如果共享内存不足，触发分页到文件系统
3. 当两者都耗尽时，抛出MEMORY_NO_MORE_PAGING

这个机制带来一个关键特性：即使物理内存充足，如果分页参数设置不当，同样会触发错误。我曾遇到一台128GB内存的服务器频繁报错，最终发现是PG_MAXFS设置只有默认值导致的。

2.2 关键参数解析

rdisp/PG_SHM：

• 控制共享内存分页区大小
• 建议值为物理内存的50-70%
• 设置过高会导致操作系统内存紧张

rdisp/PG_MAXFS：

• 控制文件系统分页区上限
• 建议值为PG_SHM的2-3倍
• 需要确保文件系统有足够空间

重要提示：修改这些参数后必须重启SAP实例才能生效

3. 参数调优实战指南

3.1 诊断当前状态

首先通过ST02检查内存使用情况：

code复制Tcode: ST02 → 进入"详细分析"模式
重点关注：
- 已用/最大分页空间
- 分页命中率
- 交换活动统计

如果分页命中率低于90%，说明分页活动过于频繁，需要调整参数。

3.2 计算推荐值

我总结的公式：

code复制PG_SHM = (物理内存 ×