rsyslog配置不当会加剧RAC节点崩溃：未启用$ActionFileEnableSync导致日志缓冲延迟，ocssd心跳超时先于日志落盘而被驱逐；应禁用rsyslog捕获GI进程日志，改由ocssd等直接写入独立SSD上的$GRID_HOME/log路径，并调优文件系统挂载选项。
不是 syslog 本身导致重启，而是它掩盖了真正致命的底层异常——比如 ocssd.bin 因内存/IPC 超时被内核 kill 后，系统连日志都来不及刷到 /var/log/messages 就已僵死。
为什么改了 rsyslog.conf 会让节点更易崩溃
Oracle RAC 的关键进程（如 ocssd.bin、ohasd）依赖实时响应能力。若 rsyslog.conf 中启用了 $SystemMaxFileSize + $SystemMaxFiles 但没配 $ActionFileEnableSync on，日志写入会走 page cache 缓冲；当系统突遭内存压力或磁盘 I/O 延迟飙升时，ocssd 的心跳超时检测（NHB/DHB）会先于日志落盘失败，触发驱逐逻辑，而 /var/log/messages 里却只留下“reboot advisory”这种马后炮记录。
常见错误配置：
-
$ActionFileEnableSync off（默认值），写日志不强制刷盘 -
$SystemMaxFileSize 50m+$SystemMaxFiles 10，但私网抖动期间日志暴增，rsyslog 自身卡在 rotate 上，进一步抢占 CPU 和文件描述符 - 未隔离 GI 日志路径：
/u01/app/grid/diag/被和系统日志混用同一块慢盘，iostat 显示%util > 95持续 10 秒以上
ocssd.log 为空或滞后时，该查哪些替代日志源
当 ocssd.log 显示空白或最后时间戳早于节点重启时间 2 分钟以上，说明日志写入链路已断裂。此时必须跳过 syslog，直取内核级证据：
- 运行
dmesg -T | grep -i "killed process"—— 查看是否出现Out of memory: Kill process <code>ocssd.bin或Kernel panic - 检查
/var/log/mcelog（如有）—— 硬件级 ECC 错误、内存模块故障常在此暴露 - 读
/proc/sys/kernel/msgmax和ipcs -q—— 若消息队列满且msgmax过小（如仍为默认 65536），gipc通信失败不会报错，只会静默丢包 - 确认
/dev/shm是否被其他进程占满：df -h /dev/shm—— RAC 启动阶段若此处空间不足，oraagent无法创建 IPC socket，root.sh卡死并残留损坏状态
systemd-journald 替代方案的风险点
在 SLES 12+ 或 RHEL 7+ 上启用 journald 后，若未调整其资源限制，反而会加剧问题：
-
SystemMaxUse=512M（默认）会导致 journal 轮转频繁，journalctl 查询时触发大量磁盘 seek，拖慢整个ocssd心跳周期 - 未设置
ForwardToSyslog=no，造成日志双写：journald → rsyslog → disk，I/O 放大三倍 -
Storage=volatile时所有日志仅存内存，节点一重启，journalctl -u ohasd查不到任何线索
真正安全的做法是：禁用 rsyslog 对 GI 进程的捕获，让 ocssd、crsd 等直接写 $GRID_HOME/log/<node>/<component>/<logname>，这些路径必须挂载在低延迟 SSD 上，且禁止与其他服务共享。
最易被忽略的是：即使 syslog 配置正确，ocssd.bin 崩溃前 3 秒内产生的 trace 文件（如 ocssd.trc）可能因 ext4 默认挂载选项 data=ordered 而延迟写入——这不是配置问题，是文件系统行为，必须用 mount -o remount,data=writeback /u01 才能降低风险。
