章晓红如果你在 Unix 上维护过 SAP 系统，下面这个场景应该不陌生：系统上线跑了半年，日常监控看起来一切正常，负载不高、数据库命中率不错、用户也没怎么投诉，结果一到月底结账、大批量物料账务处理的时候，用户开始掉线，后台作业整批失败，SAP 的短转储和数据库日志看起来都“正常”，可系统就是不稳。折腾到后半夜，最后查到原因不在 SAP 应用层，也不是数据库 Bug，而是操作系统层面的资源限制——OS Limits——把 SAP 的进程、文件句柄或者内存给卡死了。
这类问题最大的特点就是“悄悄”。系统在平时负载低，限制不会暴露；一旦并发上来，OS Limits 会先于 SAP 自己把资源切断。而 SAP 的报错又常常不会直接提示“资源超限”，反而像业务逻辑问题、连接超时、内存不足，甚至是数据库写入失败。我在几个项目里都遇到过类似的场景，所以今天想把 Unix 平台下 OS Limits 和 SAP 稳定性之间的关系讲透，包括它是怎么影响的、不同平台怎么查、上线前怎么评估，以及出了问题怎么排查。这篇文章主要面向 SAP BASIS、系统运维和负责 SAP 底层环境的同事，对 Unix/Linux 管理员同样有参考价值，毕竟两边配合起来才能把这类问题提前消灭在萌芽里。
1. 先理解关键点：OS Limits 究竟卡在 SAP 的哪一层
1.1 SAP 进程在 Unix 上并不是“特殊公民”
很多人会下意识觉得，SAP 是很重型的商业套件，Unix 操作系统肯定会给足资源。实际上，操作系统根本不认识 SAP，内核只按照进程、用户、文件句柄和内存这些基础对象来管资源。SAP 应用服务器、数据库进程、SAP HANA、Java 实例在 Unix 上最终都体现为一堆普通进程，每个进程又有自己的限制。
举一个接地气的类比：整个 Unix 系统就像一家大型餐厅，SAP 是这个餐厅里超大规模的宴会团队。宴会的桌数取决于厨房能同时出多少菜，每个厨师（进程）能同时拿多少个盘子（文件描述符）、能站多少人（进程数上限）、后厨的储物间能放多少货（内存限制）。一旦超过后厨允许的“人/盘/货”规模，出菜速度就会骤降，但前厅得到的反馈只是“顾客等太久”。
OS Limits 就是这些“人/盘/货”的内核级配额，它不允许应用超额使用资源。SAP 和数据库不会针对“资源被限制”做复杂兜底，往往只是简单地把某次调用失败返回给上层，于是 SAP 层收到错误后显示成各种让人摸不着头脑的故障。
1.2 四类资源限额最容易影响 SAP
从实际排障经验看，影响 SAP 稳定性的 OS Limits 可以分成四类：文件、进程/任务、内存、进程间通信。它们各自的症状完全不同。
第一类是文件描述符，Unix/Linux 下叫 file descriptor，AIX 上有时叫 open file descriptors，Solaris 也有类似概念。SAP 启动时要写开发日志、系统日志、审计日志，数据库要打开数据文件、控制文件、重做日志，应用服务器进程要管理大量 Socket 连接，每一个都占文件描述符。文件描述符耗尽后，轻则新事务无法继续，重则 DB 文件写入失败、实例宕掉。
第二类是进程和线程数限制。Unix 通常按用户统计总进程数，比如 Linux 的 RLIMIT_NPROC 限制同一个真实用户 ID 下能创建的进程总数，AIX 则通过用户属性里的 maxuprocs/processes 限制。SAP 一个应用实例往往有几类工作进程：Dialog、Background、Update、Spool、Enqueue、Gateway，数据库服务器还会有大量 Server Process，一旦同一 OS 用户下的总进程数到顶，新进程会直接创建失败。
第三类是内存和虚拟地址空间。比如 RLIMIT_AS、RLIMIT_DATA 控制进程能往地址空间里堆多少数据；RLIMIT_MEMLOCK 和大页内存/锁定内存相关；Linux 上还有一个容易被忽略的 vm.max_map_count，它限制单个进程能创建的 mmap 映射区域数量，SAP HANA 跑高并发查询时特别受影响。
第四类是 System V IPC 和共享内存、信号量、消息队列。传统 SAP 数据库（比如 Oracle、Db2）高度依赖这些内核资源，信号量集合数不足的时候数据库进程可能启动失败，消息队列不够、共享内存不够也会使应用服务器的某些通信组件无法初始化。
1.3 为什么测试环境不炸，生产环境总在关键时刻炸
这是“悄悄决定”这个词里最关键的部分。开发和测试环境通常并发用户少、数据量小，限制设成默认值 1024 也可能够用。生产环境则完全不同：用户会同时登录、后台作业会批量执行、接口会在整点涌入大量请求、数据库还要做并行查询和备份。
很多客户的生产系统确实不是一开始就不稳定，而像是“病来如山倒”的样子，但实际上 OS Limits 早就已经在高位运行了。平时可能只用到 60% 的资源配额，看起来数据健康；一旦月底、季末并发冲起来，瞬间超过 100%，故障就发生了。SAP 自带的事务代码，比如 ST03N 看工作负载、SM50 看进程、DBACOCKPIT 看数据库，这些能反映应用资源消耗，但基本不会