vm.min_free_kbytes设得过大（如256gb内存下设为300mb以上）会强制预留过多物理内存，导致ohasd、pmon等关键进程因无法分配内存而启动失败，引发系统卡死或反复重启；其安全值应不超过free -g中available列的1/4，而非简单按内存百分比硬算。
为什么改了vm.min_free_kbytes会导致系统崩溃
这不是oracle报错，而是linux内核直接拒绝分配内存——vm.min_free_kbytes设得过大（比如256g内存设成300mb以上），会强制预留大量物理内存不供用户进程使用，导致ohasd、pmon等关键进程因无法申请到页而启动失败，最终系统卡死或反复重启。
常见错误配置：vm.min_free_kbytes = 33554432（32MB）看似合理，但若系统总内存仅8GB，该值已占约0.4%，叠加大页占用后极易触达临界点。
- 不要用“物理内存×0.4%”硬算，应参考
free -g输出的Available列，预留值不超过其1/4 - 修改后必须
sysctl -p生效，并用cat /proc/sys/vm/min_free_kbytes确认写入成功 - 若已崩溃，需进单用户模式删除或注释
/etc/sysctl.conf中相关行，再reboot
vm.nr_hugepages配多大才算安全
大页配置错误是RAC安装阶段最隐蔽的杀手。11g RAC要求SGA必须用大页锁定，但vm.nr_hugepages不是按SGA大小直接填数字——它取决于大页尺寸（通常2MB）和SGA实际需求，且不能超过可用物理内存的75%。
例如SGA设为12GB，用2MB大页：12×1024÷2 = 6144页；但若系统总内存24GB，已用掉6GB给OS和其他进程，则最多只能配(24-6)×1024÷2 ≈ 9216页，6144是安全的；若盲目配10000页，系统就可能OOM。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 查当前大页使用：
grep HugePages_ /proc/meminfo - 查SGA实际占用：
ps -eo pid,comm,args --sort=-vsz | head -10看ora_pmon_*进程的VSZ - 配完必须
reboot才生效，中途改参数无效
改错参数后Grid安装卡在root.sh怎么办
root.sh执行失败后，不能简单重跑——它依赖的IPC资源、OLR状态、临时socket文件都已污染。强行继续只会让ohasd反复崩溃，报ORA-29701或CRS-4535。
- 先清空残留：
rm -f /var/tmp/.oracle/* /tmp/.oracle/* - 再彻底卸载：
/u01/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig -force -verbose（注意是rootcrs.pl，不是roothas.pl） - 确认输出含
Successfully deconfigured Oracle clusterware stack，否则说明OCR还在被其他节点引用，需先在正常节点执行crsctl delete node -n - 最后重跑
root.sh，别跳过验证步骤
修复后怎么验证没埋雷
参数改回来、Grid重装完，不代表万事大吉。真正要盯住的是ohasd是否稳定存活超5分钟，以及crsctl check crs能否返回CRS-4638而不是CRS-4535。
- 检查
ohasd进程：ps -ef | grep ohasd，确认UID是root且无Z状态 - 看IPC是否就绪：
ipcs -q | grep ohasd应有队列，ls -l /var/tmp/.oracle/npohasd权限应为prw-rw---- 1 root root - 查
$GRID_HOME/log/<hostname>/client/ohasd.log</hostname>末尾是否有ohasd is starting且无failed to bind类错误
最关键的其实是ocssd.log里有没有持续的心跳记录——没有这个，集群随时可能再次驱逐节点。
