JVM_内存管理机制分析与OOM问题浅析.pptVIP

当weblogic出现问题的时候，作为一个support应当怎么做？做些什么呢？ * 进一步分析 Java 堆 OOM 如果迄今为止所进行的分析不起作用，请使用 JVM 性能探查工具： 该探查工具将实现 JVM 事件探查器接口 (JVM Profiler Interface, JVMPI)，如 Jprobe 或 OptimizeIt或者YourKit 确定占用堆的对象的类型、数量和大小 确定对象在代码中的创建位置 其用法的详细信息，请参考相应的JVM性能探查工具文档 不过，JVM 事件探查器通常需要较高的系统开销，因此在生产机器上很少使用这样子的探查方法，建议一定不要在生产环境中使用！ 与应用程序团队合作，查明可能存在的内存泄漏或改进对象的使用和/或生命周期状况。 处理本地内存 OOM（1） 对于本地内存 OOM 错误： 采用的探查方法与对 Java 堆 OOM 采用的探查方法相同： 通过 -verbosegc 开关收集 GC 信息 确认 GC 的运行合乎预期，例如，是在 OOM 发生前 运行 留意 JVM 堆的初始（和周期）可用性/占用率。 定期监视进程内存大小： 在 Unix/Linux 上，使用 ps -p PID -o vsz 或者top命令 在 Windows 上，使用 perfmon 工具。 确定是否使用了任何本地模块或 JNI 代码。 还要检查计算机的物理内存总量（RAM 和交换空间之和）是否足以满足所有正在运行的进程的需要 处理本地内存 OOM（2） 使用收集到的数据来解决 OOM 错误 如果怀疑发生了内存泄漏，集中精力查找泄漏源 第三方代码（例如，JDBC 驱动程序）或 JNI 代码可能会发生泄漏 排除法，不使用第三方代码 可能的情况下尝试替换纯 Java 实现，以确认泄漏源。 如果存在本地内存泄漏 增加物理内存，只能够延缓故障发生，无法根除问题 处理本地内存 OOM（3） 从GC日志中看到Heap实际使用大小远小于最大值，可以减少这个最大值，提供更多可用的本地内存 如果 RAM 和交换空间不足，添加内存或者升级计算机 JVM 使用本地内存： 加载类和生成代码，但在启动几小时后，内存使用量通常会稳定下来 可能会发生运行时类加载和代码优化（JIT很古老的技术） 禁用JIT功能： 如果使用的是 JRockit，-Xnoopt 如果使用的是 Sun/HP的JDK，-Xint 如果使用的是 IBM JDK，-Dpiler=NONE 处理本地内存 OOM（5） 最后，如果无法查明本地内存 OOM 错误的成因： 请与 JVM 供应商联系，找到跟踪本地内存分配调用的方法 请与第三方模块或 JNI 代码供应商联系，是否有调试/跟踪功能 继续收集和分析有关 OOM 错误发生时间和发生原因的信息 如果存在多个成因，缩小探查范围可能需要一些时间。 升级 升级JDK 升级操作系统 升级Weblogic Server 使用分析工具分析内存不足和内存泄露 第四讲 使用分析工具分析内存不足和内存泄露 使用分析工具分析内存不足和内存泄露 发生Java Heap OOM 问题时，无法定位到问题，最终的办法只能使用分析工具来做分析。 JDK本身的一些工具 Jmap Jconsole等等 常用内存分析工具 此类工具非常多 推荐使用轻量级分析工具 HeapAnalyzer or HeapRoots for IBM JDK Only－离线分析 BEA JRA Memory Leak Detector– JRockit YourKit －轻量级 OptimizeIt HeapAnalyzer HeapAnalyzer是一款针对IBM JDK的内存文本镜像HeapDump的分析工具 特性： 离线分析，不影响生产系统 需要得到IBM JDK内存镜像 只支持IBM JDK HeapRoots字符界面，HeapAnalyzer是HeapRoots的图形界面 只能静态分析，要求得到现场数据 启动方式： -XX：+HeapDumpOnOutOfMemoryError得到heapdump文件 启动HeapAnalyzer，加载heapdump文件 图形化分析 HeapAnalyzer(2) HeapDump是IBM JDK Heap内存的一个文本镜像，默认生成位置在Weblogic Server启动目录下，通常是Domain目录 如果得不到HeapDump，可能是禁止生成 HeapDump的生成开关 export IBM_HEAPDUMP=true export IBM_HEAP_DUMP=true export IBM_HEAPDUMP_OUTOFMEMORY=true export IBM_J