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工作进程获取内存的路径是这样的：
- 首先尝试从共享内存池分配
- 如果共享内存不足，触发分页到文件系统
- 当两者都耗尽时，抛出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 = (物理内存 × 0.6) - SAP缓冲区需求
PG_MAXFS = PG_SHM × 2.5
例如对于64GB内存的服务器：
code复制PG_SHM = (64 × 0.6) - 8 = 30.4GB → 设置为30400MB
PG_MAXFS = 30400 × 2.5 = 76000MB
3.3 参数设置步骤
- 登录SAP系统
- 执行Tcode: RZ10
- 选择对应实例配置文件
- 修改参数：
code复制rdisp/PG_SHM = 30400 rdisp/PG_MAXFS = 76000 - 保存并生成新的配置文件
- 重启SAP实例
4. 常见问题排查手册
4.1 错误场景分析
案例1：批量作业运行时频繁报错
- 原因：PG_MAXFS不足导致分页区提前耗尽
- 解决方案：按3.2节公式重新计算并增大PG_MAXFS
案例2：系统响应变慢但无报错
- 原因：PG_SHM过小导致频繁分页
- 验证方法：ST02中检查分页命中率
- 解决方案：适当增大PG_SHM并监控效果
4.2 高级调优技巧
对于大型ERP系统，我推荐：
- 为不同服务器角色差异化设置：
- 对话实例：较高PG_SHM
- 批处理实例：较高PG_MAXFS
- 使用ST06监控操作系统级内存压力
- 定期使用DB13清理旧日志释放空间
5. 长效监控与维护策略
5.1 自动化监控方案
配置CCMS警报（Tcode: RZ20）：
- 创建"内存分页"监控树
- 设置关键指标阈值：
- 分页空间使用率 >80% 警告
- 分页命中率 <85% 警告
- 配置邮件通知
5.2 容量规划建议
根据我的经验，每100个并发用户需要：
- PG_SHM：1.5-2GB
- PG_MAXFS：4-5GB
对于HANA系统，可以适当降低这些比例，因为HANA本身更节省内存。
最后分享一个真实案例：某客户的生产系统每天下午3点准时崩溃。最终发现是PG_MAXFS设置过小，而当天3点正好有个大型报表作业启动。将PG_MAXFS从20GB调整到60GB后问题彻底解决。这个案例告诉我们：参数调优不能只看理论值，必须结合业务负载特点。