lmd0本身并非内存泄漏源，而是grd状态紊乱或节点通信异常导致其持续处理积压的全局队列请求；真正需关注的是vsz是否持续＞2gb、rss是否缓慢爬升，以及ora.crf是否频繁重启——若重启后缓解，则根源极可能是osysmond.bin内存泄漏引发crf抖动。
不是lmd0本身内存泄漏，而是它在持续处理异常积压的全局队列（grq）资源请求，本质是grd状态紊乱或节点间通信异常的表征。
怎么看LMD0是否真在吃内存
直接看进程RSS不准确——LMD0 是轻量级守护进程，正常 RSS 通常在 20–50MB。真正要盯的是：ps -eo pid,ppid,vsz,rss,comm | grep lmd0 中的 vsz（虚拟内存）若持续 >2GB，且伴随 rss 缓慢爬升，才值得怀疑；更关键的是查 crsctl stat res -t | grep ora.crf ——如果 ora.crf 资源反复 restart，那 LMD0 的异常几乎必与 osysmond.bin 内存泄漏引发的CRF服务抖动有关。
排查GRD资源未释放的三个实操动作
GRD（Global Resource Directory）状态异常会导致 LMD0 不断重试获取锁、协调缓存块，表现为高CPU+内存缓慢增长：
- 用
oradebug setmypid; oradebug dump global_name 1查当前 GRD 主控节点，确认是否漂移频繁 - 查
gv$ges_blocking_enqueue：若有大量ENQ: TX - row lock contention或ENQ: HW - contention且 blocking_instance 持续变化，说明 GES 协调失败 - 运行
crsctl check cluster -all和olsnodes -n -s -t，确认所有节点voting disk心跳正常；若某节点显示UNKNOWN或OFFLINE，LMD0就会不断尝试重建连接并堆积请求
为什么重启ora.crf能快速缓解
ora.crf 是 Cluster Ready Services 的子服务，负责采集集群运行时指标（通过 osysmond.bin）。当它因内存泄漏卡死或响应迟滞时，LMD0 无法及时从 CRF 获取节点健康状态，就会反复发起 GRD 同步请求，形成资源请求雪崩：
- 执行
$GI_HOME/bin/crsctl stop res ora.crf -init会强制终止osysmond.bin进程，清空其占用的堆内存 - 随后
start res ora.crf -init会重新加载干净的osysmond.bin实例，恢复 CRF 与各节点的指标上报通道 - 注意：该操作不中断数据库实例，但会短暂丢失 1–2 分钟的集群性能指标（如 AWR 中的 Cluster Wait Class 数据）
真正棘手的点在于：LMD0 异常往往不是起点，而是下游症状。必须顺着 osysmond.bin → ora.crf → GRD 状态 → LMD0 行为 这条链路逆向验证，否则容易在 gv$lock 或 AWR Top Events 里打转。补丁 18701017 虽然是 12.1 的，但在 11.2.0.4 上手动 backport 后已有多例证实可稳定压制 osysmond.bin 的每小时 0.23MB 内存增长——这是比反复 kill 进程更可持续的做法。
