节点重启慢本质是集群等待心跳、投票和驱逐确认，需先定位网络抖动、磁盘延迟或ocssd.bin挂起；ocssd.log中“misscount exceeded”多因私网瞬时拥塞，建议先查日志确认是否IPC或网络心跳连续失败，再酌情将misscount设为45（≤60），disktimeout推荐设为300。
节点重启慢，本质是集群在“等”——等心跳、等投票、等驱逐确认。直接调大超时参数反而可能掩盖真实故障，必须先分清是网络卡顿、磁盘响应延迟，还是cssd进程自身挂起。
ocssd.log 里出现 “misscount exceeded” 怎么办
这是最常见的误判源头：节点没真丢心跳，只是 CSSD 认为它丢了。默认 misscount 是 30 秒（11g+），但实际私网抖动超过 5 秒就可能触发重试逻辑，导致重启流程拖长。
- 先别急着改参数，用
crsctl get css misscount确认当前值，再查ocssd.log中报错前 60 秒内是否有IPC timeout或network heartbeat failed连续出现 - 若确认是私网瞬时拥塞（比如交换机 buffer 溢出），可适度上调：例如
crsctl set css misscount 45，但绝不能 > 60，否则脑裂风险陡增 - 注意：RAC 只有 2 个节点时，
misscount必须严格对齐，否则小编号节点可能被无故驱逐
disktimeout 设置为 200 还是 400 更合适
disktimeout 控制的是“表决盘心跳失败后多久自动重启”，不是 I/O 延迟容忍阈值。设太高（如 400）会让节点在存储假死时迟迟不退出，拖累整个集群可用性；设太低（如 100）又容易因临时 IO 卡顿误重启。
- 生产环境建议统一设为
300：既避开短时存储抖动（ - 执行前务必确认表决盘路径稳定：
crsctl query css votedisk输出的设备必须是多路径聚合后的设备名（如/dev/mapper/vote01），而非底层物理盘（如/dev/sdb） - 如果使用 ASMFD 管理表决盘，
disktimeout实际生效值会受asmfd自身重试逻辑影响，此时优先调asmfd的reconnect_timeout
reboottime 设成 5 秒真的能加快重启吗
不能。这个参数只控制“驱逐命令下发后，节点必须在多少秒内完成关机动作”，和“从开始检测到最终重启完成”的总耗时不直接相关。真正拖慢的是 CSSD 在驱逐前的仲裁等待、资源清理、以及 OS 层面的进程终止顺序。
-
reboottime默认是 3 秒，设成 5 不会提速，反而可能让异常节点残留更久 - 若发现重启过程卡在 “Waiting for CSSD to stop…” 阶段，重点查
oclsomon.log和top -b -n1 | grep ocssd—— 很可能是 CPU 被占满或信号量死锁 - 真正影响重启速度的是内核参数：
kernel.sem中的第四个值（semmsl）必须 ≥ 1024，否则 CSSD 释放 IPC 资源时会阻塞
最常被忽略的一点：所有超时参数调整后，必须重启 CSSD 进程才能生效（crsctl stop crs; crsctl start crs），而不仅仅是 reload。且修改前务必备份原始值，因为不同版本 CRS 对参数敏感度差异极大——19c 中 disktimeout 超过 360 秒会触发强制 panic，但 11.2.0.4 却允许设到 600。
