怎样配置limits.conf满足Oracle安装内存限制？-Oracle-PHP中文网

memlock 必须与 HugePages 对齐，因为 Oracle 实例启动时需锁定 SGA 到大页内存，若 soft/hard memlock 值小于 SGA_MAX_SIZE（字节），将触发 ORA-27123 错误；且 systemd 环境下 limits.conf 无效，须在 service 文件中显式配置 LimitMEMLOCK=。

怎样配置limits.conf满足oracle安装内存限制？

limits.conf 中 memlock 设置为什么必须和 hugepages 对齐？

Oracle 推荐启用 hugepages，而 memlock 限制直接决定 Oracle 进程能否成功锁定 SGA 到大页内存。如果 oracle soft memlock 或 hard memlock 小于 SGA 总大小（尤其是启用了 AMM/ASMM 后的 target memory），实例启动时会报 ORA-27123: unable to attach to shared memory segment，且 ipcs -m 显示共享内存段未被锁定。

常见错误是照搬文档写死 134217728（128MB），但该值只适用于 SGA ≤128MB 的极小配置。实际应按物理内存和规划 SGA 计算：

memlock hard 值 ≥ SGA_MAX_SIZE（字节），建议再上浮 10% 预留内核页表开销
若使用 hugepages，需确保 vm.nr_hugepages 已预分配足够页数（grep HugePages_ /proc/meminfo 验证）
CentOS 7+ 上，systemd 会忽略 limits.conf 中的 memlock，必须在 /usr/lib/systemd/system/ohasd.service 和 oracle-rdbms.service 中显式加 LimitMEMLOCK= 字段

nofile 和 nproc 值设太高反而导致 crs 启动失败？

很多人把 oracle hard nofile 65536 当成“越大越好”，却忽略了 RAC 环境下 root 用户启动的 CRS 进程（如 ohasd、crsd）并不继承 oracle 用户的 limits —— 它们由 systemd 或 init 启动，受 root 的资源限制约束。一旦 root hard nofile 仍为默认的 4096，crsd.bin 在打开大量 OCR/Voting Disk 句柄、ASM 磁盘路径、网络连接时就会静默失败，日志里只有 ERROR: Failed to start CRSD，根本不会提示句柄不足。

正确做法是：

同时设置 root soft nofile 和 hard nofile 至少 65536（RHEL7/CentOS7 要求 ≥ 65536 才能通过 CRS 自检）
nproc 不宜盲目拉高：Oracle 11gR2 单实例线程数通常不超过 2000，设 oracle hard nproc 16384 足够；但 root hard nproc 若超过 8192，可能触发 systemd 的 TasksMax 限制（默认 512），需同步调大 /etc/systemd/system.conf 中的 DefaultTasksMax
验证是否生效：用 sudo -u oracle bash -c 'ulimit -n' 和 sudo -u root bash -c 'ulimit -n' 分别检查

为什么改了 limits.conf 还是不生效？三个关键漏点

limits.conf 不是改完就生效的配置文件，它依赖 PAM 模块加载、会话类型、以及进程启动方式。最常踩的坑是：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

PAM 配置没覆盖所有登录路径：/etc/pam.d/login 只管 tty 登录；SSH 登录走 /etc/pam.d/sshd，GUI 登录走 /etc/pam.d/gdm 或 lightdm，必须全部补上 session required pam_limits.so
非登录 shell（如 cron、systemd service、su -c）默认不读 limits.conf：cron job 需在脚本开头加 ulimit -n 65536；systemd 服务必须在 unit 文件中用 LimitNOFILE= 显式声明
用户组限制被忽略：若 oracle 用户属于 @dba 组，但 limits.conf 写的是 oracle 用户行，组级规则（@dba soft nofile 65536）不会自动合并——PAM 是“先匹配用户名，再匹配组名”，且只取第一个匹配项，不会叠加

memlock 单位是 KB 还是 bytes？官方文档为何前后矛盾？

Oracle 官方文档（如 11gR2 Installation Guide）示例中写 oracle hard memlock 134217728，这个数字单位是 bytes，不是 KB。但很多 Linux 发行版（如 RHEL6）的 pam_limits.so 实现会把该值当作 KB 解析，导致实际锁定内存只有预期的 1/1024 —— 这就是为什么有些环境明明配了 128MB 却仍报 ORA-27123。

安全做法是统一用 bytes，并验证：

执行 ulimit -l 查看当前生效值（单位 KB），再乘以 1024 对应到 bytes
启动数据库后运行 cat /proc/$(pgrep ora_pmon)/limits | grep memlock，确认 Max locked memory 行的 Max 列数值与配置一致
若发现值异常小，检查是否被 /etc/security/limits.d/*.conf 中其他文件覆盖（RHEL7+ 默认有 20-nproc.conf 限制普通用户进程数）

真正麻烦的从来不是参数怎么填，而是你永远不知道哪个进程在哪一层绕过了你设的限制。