Dify容器因OOM Killer终止，根源是JVM内存参数超出容器限制；需先用dmesg确认内核级OOM，再检查cgroup内存上限与-Xmx匹配性，按容器大小合理分配堆、元空间、直接内存等，并启用UseContainerSupport自动适配。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
线上Dify容器突然退出，日志显示exit code 137，宿主机free -h显示内存剩余充足，但dmesg | grep -i "killed process"明确指出Out of memory: Kill process dify-worker (PID XXXX)——这不是JVM堆溢出，而是Linux内核OOM Killer主动干掉了进程，根源在容器内存限制与JVM内存参数不匹配。
确认Dify容器是否被OOM Killer终止
执行dmesg -T | grep -i "killed process"，查找时间戳最接近Dify崩溃时刻的记录。若输出中包含dify-worker或java进程名，并带有Out of memory字样，说明是内核级OOM，不是JVM抛出的OutOfMemoryError。
这一步必须先做。如果跳过直接去查JVM堆日志，会误判为Java堆溢出，后续所有调优方向全错。
检查Docker容器内存限制与JVM堆参数是否冲突
进入运行中的Dify容器（如docker exec -it dify-worker bash），执行cat /sys/fs/cgroup/memory.max（cgroup v2）或cat /sys/fs/cgroup/memory/memory.limit_in_bytes（cgroup v1）。该值即容器实际可用内存上限。
再执行ps aux | grep java，找到启动命令，提取-Xmx参数值。若-Xmx设为3g，而容器limit为4g，看似留有1g余量——但JVM还会额外占用元空间、直接内存、线程栈、CodeCache等，总内存消耗常达Xmx + 1.5g以上。
【关键冲突点】：当-Xmx ≥ 容器内存限制 × 0.7，且应用使用NIO或加载大量类时，极易触发内核OOM Killer。Dify默认配置常踩此坑。
重配JVM参数以适配容器内存限制
第一步：确定容器真实内存上限。例如docker inspect dify-worker | grep Memory返回"Memory": 4294967296，即4GB。
第二步：按比例分配JVM各区域。对4GB容器，推荐配置：-Xms2g -Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=512m -Xss256k
第三步：禁用堆外内存自动增长。添加-XX:+UseContainerSupport -XX:MaxRAMPercentage=50.0，让JVM自动感知容器限制并按50%比例设堆，比硬编码-Xmx更安全。
第四步：强制生成OOM现场快照。追加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof -XX:+ExitOnOutOfMemoryError。注意/tmp需挂载到宿主机持久路径，否则容器退出后文件丢失。
验证JVM实际内存占用是否超限
方法一：容器内执行jstat -gc $(pgrep -f "dify.*worker") 1s 5，观察OU（老年代使用量）是否持续逼近OK（老年代容量），且FGCT（Full GC次数）陡增——这是堆内耗尽信号。
方法二：用docker stats dify-worker实时查看RSS（Resident Set Size）。若RSS稳定在3.8–4.0GB并频繁抖动，说明已触顶，内核随时可能kill。
方法三：抓取进程内存映射快照：cat /proc/$(pgrep -f "dify.*worker")/smaps_rollup | grep "^MMU.*:"，重点关注MMUPageSize和RSS行，确认真实物理内存占用。
注意：不要依赖top里VIRT值，它包含未分配的虚拟地址空间，无参考价值。
针对Dify高频OOM场景的专项加固
场景1：解析加密PDF导致DirectBuffer爆满
在Dify配置中关闭pdf_parser.use_streaming（若存在），强制启用流式分页解密；同时将-XX:MaxDirectMemorySize从默认值（通常等于-Xmx）显式压至256m，避免NIO缓冲区吞噬全部剩余内存。
场景2：Excel百万行导入引发堆外+堆内双溢出
升级Dify至v0.12.0+，启用excel_parser.chunk_size: 5000配置项；并在JVM参数中加入-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=detail，后续用jcmd $(pgrep java) VM.native_memory summary定位DirectBuffer泄漏源头。
场景3：Worker并发任务堆积引发线程栈溢出
检查dify-worker的celery_worker_concurrency是否超过CPU核心数×2。若容器仅分配1核，却设concurrency=8，每个线程栈默认1MB，仅线程栈就占8MB，叠加GC压力极易触发unable to create new native thread——此时需同步调小-Xss至128k并降低并发数。
