用 IBM HeapAnalyzer 和 MOD4J 分析 Java 内存泄漏（2009 年 7 月 5 日）
使用的较多的是 Memory Dump Diagnostic for Java (MDD4J)和 IBM HeapAnalyzer，这两个工具都能支持几乎所有 JDK 版本所生成的堆转储文件。 先说一下 IBM HeapAnalyzer， 下载之后首先阅读一下 readme， 详细写了 HeapAnalyzer 的使用方法。 可以在命令行中输入
第一行 https://www.doczj.com/doc/fb12936405.html,ng.ref.Refenrence 这个 class 及它的 76 个 children 占用了 67%的已用堆大小（31M/46M），它本身仅占用了 76bits。双击 https://www.doczj.com/doc/fb12936405.html,ng.ref.Refenrence，我们可以看到它 所引用的两个子节点。其中一个子节点 https://www.doczj.com/doc/fb12936405.html,ng.ref.Finalizer 后的 67%指引我们内存泄漏的问题应该在它的引用上。
接下去你可以逐级展开，或者右键点击“Locate a leak suspect”，让 HeapAnalyzer 帮你找到泄漏可能发生的地方。泄漏一般发生在那些拥有“超乎寻常多”的引用（子节点）的 class 上，正是 这些创建后没有释放、累积了成千上百的对象，造成了 OutOfMemory。右键中的“Go to the largest drop subtrees”也是以此为原理而设的，它的解释为： “Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent. 因为出现泄漏的点，每个子节点占用的内存空间不大，但是巨大的数量会导致父节点占用的 total size 很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的，否则也不需要我们 来分析了。 更多细节的内容，可以看这篇 PPT Memory Dump Diagnostic for Java (MDD4J)则是 IBM Support Assistant（ISA）里的一个工具，可以在 ISA 里加载。它的使用方法和 HeapAnalyzer 类似，不过它会自动列出“可 疑泄漏点”供分析。所依据的，是“分析算法查找父对象与子对象之间对象大小的显著变化。这些发生显著变化的父对象可能是基于数组的容器对象，它们包含大量不断增大的子对象。” 具体的使用方法可以参考《WebSphere Application Server 中的内存泄漏检测与分析:第 2 部分：用于泄漏检测与分析的工具和功能》一文中的实际案例。（不过文中的版本应该比较低，现 在能下到的 2 和 3 版本有些不同，不过不妨碍使用）.
Heapdump 工具的使用很简单，难点在于找到“内存泄漏的真正原因”，一般需要通过多个 heapdump 文件的对比才能找到。 比较分析用于对运行内存泄漏应用程序期间（即可用 Java 堆内存流失时）获取的两个内存转储进行分析。在运行泄漏应用程序的早期触发的内存转储被称为基线内存转储，发生泄漏的应用程序运行 一段时间（以允许泄漏程度加大）后触发的内存转储被称为主内存转储。在发生了内存泄漏的情况下，主内存转储可能包含大量对象，而这些对象占用的 Java 堆空间量会比基线内存转储大很多。 为了获得更好的分析结果，建议使主内存转储的触发点与基线内存转储的触发点在时间上拉开一定距离，从而使总耗用堆大小在两个触发点之间大幅增长。 如果发现“主内存转储”中的某个对象数量大大大于“基线内存转储”，那么这个对象一般就是发生泄漏的点。但是要避免在 appserver 刚启动时就做 heapdump，否则会把正常需要分配的对 象当作泄漏嫌疑点。比如原先运行 3 天会发生 OOM，那么可以：缩小堆大小，让 OOM 提早发生；在运行 4 个小时后每隔 4 小时手动做一次 Heapdump 直到 OOM 发生。这些动作也许不适合在生 产环境下进行，可以另建测试环境进行。 之前几篇文章中介绍的分析 gc log，和本文讲到的分析 heapdump，都是脱机分析法。它们的缺陷就是无法找到代码引起的“性能低下”的原因，正如《用 HPjtune 分析 GC 日志》里所看到的 那样，系统性能很差，但是没有 OOM 发生，可用堆在每次 full gc 后还不断减少的现象不能简单怪罪为内存泄漏，毕竟最后都回收下来了，如果手动做 heapdump，可能有问题的对象已被回收，无 法得到正确的结果。这种情况下要使用诸如 Jprofile 这样直接附加到 JVM 上的工具来监测了。 最后附一下手动生成 heapdump 的方法，免得事到临头在 google。 在 Linux/AIX 环境下 使用 Kill -3 pid 命令来调用堆转储. Windows 环境下 1． 找到 JVM 对象名字。
2． 对 JVM MBean 调用 generateHeapDump 操作。
如果上述方法是没有生成，那么进行下面的设置。 ? 访问管理控制台
? 转到“服务器”>“应用程序服务器”> Server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“环境条目”。 ? 单击“新建”。 ? 在“名称”字段中，输入 IBM_HEAPDUMP（默认是开启的）。在“值”字段中，输入 true。 ? 单击“确定”。 ? 重复步骤 3 至 5，但将 IBM_HEAPDUMP_OUTOFMEMORY 设置为 true。 ? 缺省情况下，将在 ~/WebSphere/AppServer/ 目录中创建内存转储（对于 WebSphere Application Server V6.x 而言，缺省目录是：~/WebSphere/AppServer/profiles/default）。要 将堆转储目标定向到另一个目录，请转至“环境条目”，单击“新建”，将 IBM_HEAPDUMPDIR 设置为适当的目录（例如 /heapdumps），然后单击“确定”。 ? 单击“保存”，然后在下一个屏幕中再次单击“保存”。 ? 转到“服务器”>“应用程序服务器”> server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“Java 虚拟机”。 ? 选择“详细垃圾回收”。 ? 单击“保存”，然后在下一个屏幕中再次单击“保存”。 ? 重新启动服务器。 ? 打开命令提示符并转至 /WebSphere/AppServer/bin 目录。 ? 通过发出 kill -3 XXXXX 命令来调用堆转储，其中 XXXXX 是进程标识。 如果 WebSphere 运行在 HP-UX 上，那么需要
? ? ? ? ? ? ? ? ? ?
访问管理控制台 转到“服务器”>“应用程序服务器”> Server1（或者要获取其堆转储的服务器的名称）>“进程定义”>“环境条目”。 在“常规参数”中，输入：-Xrunhprof:depth=0,heap=dump,format=a,thread=n,doe=n 缺省情况下，将在 ~/Websphere/AppServer/ 目录中创建内存转储。要将堆转储目标定向到另一个目录，请添加 HProf 参数 file=/heapdumpdir/hprof.txt，其中 heapdumpdir 是 适当的目录，而 hprof.txt 是适当的文件名。如果创建了多个内存转储，那么将把每个内存转储追加到同一个 hprof.txt 文件中。 选中“启用详细垃圾回收方式”。 重新启动服务器。 通过发出 kill -3 XXXXX 命令创建堆转储，其中 XXXXX 是进程标识。 除非另有指定，否则将在 ~/WebSphere/AppServer/ 目录中创建 hprof 转储，并且文件名看起来类似于 java.hprof.txt。 关闭应用程序服务器，然后移动 hprof 转储文件。直到正确关闭应用程序服务器之后，hprof 转储文件才完整。 注意：请检查是否每个 hprof 转储都包含 HEAP DUMP BEGIN 和 HEAP DUMP END 这两组标记。如果 hprof 转储的这两组标记不齐全，那么表明该转储不完整且不能用于分析。
需求动机：解决 OOM（ Object Out of Memory）问题以及系统调优 1. 如何产生 java heap dump 当 JVM 中对象过多， java 堆 java heap） （ 耗尽时， 就会产生 java heap dump 文件。 另外， 可以使用工具或命令显示地产生该文件。 在命令行中程序执行过程中按 ctrl+break 可以产生，使用工具如， IBM HeapAnalyzer， Sap Memory Analyzer 以及 eclipse memory analyzer 都可以在指定状态产生 dump 文件。 2. 如何分析 java heap dump 文件 这里以使用 ibm heapAnalyzer 工具为例说明；在 ibm 网站 https:// 文件，后面数字是版本号。解压后用命令行进入到解压目录，使用如 java –Xmx800m –jar 启动工 具，如果启动过程中发现控制台有 出现，可以适当加大上面的数字（ 800） ，给予更多的空间。 然后“ Open”产生的 dump 文件，打开画面如下，文件很大的话需要等待一段时间 ibm heapAnalyzer 工具在打开时已经进行了基本的分析，上面全部完成后，会出现如下结果： 除了显示该要结果外，还生成了一棵树。这个画面先不要关，直到你不再需要这个 dump 了。 基本术语： 然后对上面的界面做一下简单的介绍。 每个节点树的大小占总的堆栈大小，如 94%，然后是这个类的在内存中的大小，后面 5 个子对象，注意这个子对象的意思不是继承关系中的子类，而是上面定义的： 如果 A 对象参考 B 对象，则 B 对象是 A 对象的字对象。 然后该工具根据分析结果把可能产生泄漏的对象显示了出来。如下图： 分析根据主要是 child object 和 parent object 的大小差别程度，如果子对象不大，而父对象超级大，很可能是因为父对象是一个集合类（如数组） ，包含了大量子对象作 为元素。 工具栏： 点击分析工具栏的表格图标，显示出下面的统计表格，可以点击栏标题进行排序。各标题意思简单介绍如下： TotalSize：这个对象，以及这个对象的所有子对象（以及子对象的子对象，也就是从这个对象可以参考到的所有对象）的大小的总和，单位为 bits； Size: 这个对象的大小，如第一个 56bits = 56/8bytes = 7b； ：子对象的个数，不包括子对象的子对象； ：父对象的个数，不包括父对象的对象； Name：对象的名称。 Address：对象在 heap 中的地址。 3. 分析结果 3.1 大量的以 java/util/HashMap$Entry 为元素的数组，占据了总堆栈的 8%，很高的比例。 3.2 大量的 java/util/Hashtable$HashtableEntry 为元素的数组，占据总堆栈的 5%。 3.3 3.2 里面的数组大量指向 java/util/Hashtable$HashtableCacheHashEntry 对象。 根据分析，最有嫌疑的对象应该是 java/util/HashMap$Entry 。 4. 其他经验收集：
“ Heapdump 工具的使用很简单，难点在于找到 “内存泄漏的真正原因 ” ，一般需要通过多个 heapdump 文件的对比才能找到 。 ” “ ObjectInputStream/ObjectOutputStream 要注意内存泄漏 . reset()” “因为 JDK 的问题， 如果使用的是： J2RE 5.0 IBM J9 ppc-32 build j9vmap3223-20070201 ， 这个 SR4 的版本有个问题就是， 限定了类加载器可加载的类数量， 默认为 8192 ， 如果超过此限制，就会抛出 OutOfMemory 的错误 。 ” 对于这个问题，可以设置增加类加载器可加载的类数量解决。 5. 知识补充介绍 5.1 堆 (Heap) 和非堆 (Non-heap) 内存 按照官方的说法： “Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。 ” 在 JVM 中堆 “ 之外的内存称为非堆内存 (Non-heap memory)” 。可以看出 JVM 主要管理两种类型的内存：堆和非堆。简单来说堆就是 Java 代码可及的内存，是留给开发人员使用的； 非堆就是 JVM 留给自己用的，所以方法区、 JVM 内部处理或优化所需的内存 ( 如 JIT 编译后的代码缓存 ) 、每个类结构 ( 如运行时常数池、字段和方法数据 ) 以及方 法和构造方法的代码都在非堆内存中。 5.2 堆内存分配 JVM 初始分配的内存由 -Xms 指定， 默认是物理内存的 1/64 ； JVM 最大分配的内存由 -Xmx 指定， 默认是物理内存的 1/4 。 默认空余堆内存小于 40% 时， JVM 就 会增大堆直到 -Xmx 的最大限制；空余堆内存大于 70% 时， JVM 会减少堆直到 -Xms 的最小限制。因此服务器一般设置 -Xms 、 -Xmx 相等以避免在每次 GC 后调整堆 的大小。 5.3 非堆内存分配 JVM 使用 -XX ： PermSize 设置非堆内存初始值，默认是物理内存的 1/64 ；由 XX:MaxPermSize 设置最大非堆内存的大小，默认是物理内存的 1/4 。 5.4 JVM 内存限制 ( 最大值 ) 首先 JVM 内存限制于实际的最大物理内存 ，假设物理内存无限大的话， JVM 内存的最大值跟操作系统有很大的关系。简单的说就 32 位处理器虽然可控内存空间有 4GB, 但是具体的操作系统会给一个限制，这个限制一般是 2GB-3GB （一般来说 Windows 系统下为 -2G ， Linux 系统下为 2G -3G ） ，而 64bit 以上的处理器就不会有限 制了。
在errpt中出现E87EF1BE的dump不够的报错 在errpt中出现 E87EF1BE 0926082807 P O dumpcheck The largest dump device is too small. 信息.断定为存放dump文件的lg_dumplv容量不够.一般推荐的dump device 值大小为sysdumpdev –e 估计值的1.5 倍。 需要扩容.扩容步骤如下: 1.查看lg_dumplv大小的估计值 #sysdumpdev -e 0453-041 Estimated dump size in bytes: 1287651328 即1.2G 2.现在lg_dumplv大小 #lslv lg_dumplv 其中PP SIZE: 256 megabyte(s) PPs: 4 经计算,现在容量为1G.需要扩容0.2G 3.查看lg_dumplv所在的vg的容量是否够用 #lsvg rootvg 其中PP SIZE: 256 megabyte(s) TOTAL PPs: 1092 (279552 megabytes) FREE PPs: 826 (211456 megabytes) 经计算,vg剩余容量为206.5G,因为根盘做了镜像.故,可用剩余容量为103G左右.因pp size为256m,故扩容2pps,即0.5G(其实扩1个pp也可以.2个放心点.) 4.扩容操作 extendlv lg_dumplv 2 5.检查当前lg_dumplv的大小. #lslv lg_dumplv 其中PP SIZE: 256 megabyte(s) PPs: 6 即,现在容量为1.5G. 6.使用dumpcheck命令查看,是否还出现errpt信息
Windbg-分析Windows蓝屏原因利 软件启动点File——Open Crash Dump,如图： 然后找到你的minidump文件夹，dump文件一般是"时间.dmp"如图： 打开后就会自动分析了。分析完后，看最下面，找到3.probably caused by这一行，如图：看，出来了吧那个myfault.sys文件就是罪魁祸首。 再补充点东西，
导入dump文件分析完毕后，不要关闭，在后面输入!analyze -v ，这个命令可以查看dump 文件的详细情况，如图： 对普通用户有用的还有下面一些信息： 第一行DEFAULT_BUCKET_ID: 错误类型，这个懂点编程和操作系统知识的朋友用得上点第三行PROCESS_NAME: XXX.exe 这个是导致错误的进程，查出是什么文件导致的蓝屏后，再看这里就知道是谁调用了错误文件，比如你查出123.sys导致蓝屏，但你查不到123.sys是哪个程序调用的，就可以用这个方法来看看，比如查出了是456.exe，你就可以在机子上或者网上搜索相关信息了。 好了，到这里相信大家已经学会怎么找到导致系统蓝屏的文件了，接下来怎么办呢？上网查资料，把导致蓝屏的那个文件名在网上搜索，基本就知道是什么文件了，一般网上也有相关的解决办法，看看要删除些什么插件、打什么补丁或者重装软件等等。导致问题的不一定是.sys文件也有可能是.dll，这篇文章只能帮你找出导致蓝屏的元凶，具体的解决办法得上网查。如果是查不到什么信息的.sys或者.dll就要当心了，有可能是病毒或者rootkit 附： windbg基本调试命令： r 可以显示系统崩溃时的寄存器，和最后的命令状态。 dd 显示当前内存地址，dd 参数：显示参数处的内存。 u 可以显示反汇编的指令 ！analyze -v 显示分析的详细信息。 kb 显示call stack 内容 .bugcheck 可以显示出错的代码 windbg诊断蓝屏的一点补充
了解转储（dump）设备 David Tansley, 系统管理员, Ace Europe 2012 年7 月30 日 如果发生意外，IBM AIX? 操作系统会崩溃，此时您可能希望能够自动搜集相关信息。利用转储（dump）设备，可在这些设备上部署核心转储功能，从而准备转移到IBM 支持。 简介 如果由于意外事件导致系统崩溃，则会发生核心转储。事实上，并非总在出现系统崩溃时才发生核心转储。然而，在本文中，假定系统崩溃是由于严重事件或用户强制性动作所引起的。转储包含了达到崩溃时内存的内容。就其本质而言，崩溃总是不期而至，因而当崩溃发生时，系统管理员还是应当事先做好防范措施。能够确定崩溃的发生是否是由系统重启引起，此时在错误日志里存在具有标签为SYSDUMP的条目。 在本演示中，我使用的是AIX 7.1。不过，我所讨论的原理也适用于AIX 5.3 和 6.1。 回页首做好准备 要想防范意外的系统崩溃，需要确保具有转储设备逻辑卷(LV)，用于在系统恢复时存放转储。然而，如果转储设备不可用，那么应该指定第二转储设备来存放转储。可能人们并不关心系统崩溃何时发生，因而也对进一步研究转储文件不感兴趣。这完全取决于系统所有者。但是，为保障系统正常运行，在rootvg 中包含主转储设备是很好的做法，也是很有必要的。可为转储设备执行镜像，但是，IBM AIX 支持对此发出警告。这是因为崩溃可能会被执行镜像或同步相关，这会导致转储设备上的镜像无效。在某些情况下，转储文件仅会被复制到镜像转储设备（位于镜像磁盘中）的其中一个副本，当系统重启时，很可能仅恢复转储文件副本一半的内容，最好的做法是，将主转储设备放到一个非镜像的磁盘中，将第二设备放到另一个非镜像磁盘中。然而，对rootvg 转储设备执行镜像比较常见。只要第二转储设备不在分页空间中，或不在磁带设备之类的外部设备中，则它可以位于rootvg 内部，也可位于其外部。 回页首转储设备
Linux上Core Dump的机制、内容和分析 Psqa 左玉龙 Core，又称之为Core Dump，是Unix/Linux操作系统的一种机制，对于线上服务而言，Core令人闻之色变，因为出Core的过程意味着服务暂时不能正常响应，需要恢复，并且随着吐Core进程的内存空间越大，此过程可能持续很长一段时间（例如当进程占用60G+以上内存时，完整Core文件需要15分钟才能完全写到磁盘上），这期间产生的流量损失，不可估量。 凡事皆有两面性，OS在出Core的同时，虽然会终止掉当前进程，但是也会保留下第一手的现场数据，OS 仿佛是一架被按下快门的相机，而照片就是产出的Core文件。里面含有当进程被终止时内存、CPU寄存器等信息，可以供后续开发人员进行调试。 关于Core产生的原因很多，比如过去一些Unix的版本不支持现代Linux上这种GDB直接附着到进程上进行调试的机制，需要先向进程发送终止信号，然后用工具阅读core文件。在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出Core并退出。如果从浅层次的原因上来讲，出Core意味着当前进程存在BUG，需要程序员修复。从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出Core，实际上是触犯了OS的内存管理，访问了非当前进程的内存空间，OS需要通过出Core来进行警示，这就好像一个人身体内存在病毒，免疫系统就会通过发热来警示，并导致人体发烧是一个道理（有意思的是，并不是每次数组越界都会出Core，这和OS的内存管理中虚拟页面分配大小和边界有关，即使不出Core，也很有可能读到脏数据，引起后续程序行为紊乱，这是一种很难追查的BUG）。 说了这些，似乎感觉Core很强势，让人感觉缺乏控制力，其实不然。控制Core产生的行为和方式，有两个途径： 1.修改/proc/sys/kernel/core_pattern文件，此文件用于控制Core文件产生的文件名，默认情况下， 此文件内容只有一行内容：“core”，此文件支持定制，一般使用%配合不同的字符，这里罗列几种：?%p 出Core进程的PID ?%u 出Core进程的UID ?%s 造成Core的signal号 ?%t 出Core的时间，从1970-01-0100:00:00开始的秒数 ?%e 出Core进程对应的可执行文件名 更强大的是，我们可以在此文件中配置管道，来将产生的Core文件作为输入，送给某个特定的处理程序，例如网络传输程序，可以将产出的Core直接送到另一台服务器上，这对于小硬盘服务器来说，是一个不错的选择。 2.Ulimit –C命令，此命令可以显示当前OS对于Core文件大小的限制，如果为0，则表示不允许产生 Core文件。如果想进行修改，可以使用： Ulimit –cn 其中n为数字，表示允许Core文件体积的最大值，单位为Kb，如果想设为无限大，可以执行：Ulimit -cunlimited 产生了Core文件之后，就是如何查看Core文件，并确定问题所在，进行修复。为此，我们不妨先来看看Core文件的格式，多了解一些Core文件。
AIX的Dump文件学习笔记(原创) DUMP文件概述 为了增强故障分析能力，IBM的服务器增加了对设备故障当前环境的保存功能，就是保存一份设备故障时的内存、CPU寄存器、IO等设备的数据和状态信息，如果系统并没有停住，只是某个程序死掉，会产生CORE DUMP，在当前目录下产生一个CORE文件。而如果操作系统死掉，则产生System DUMP或者System Crash，通常会引起系统停机。DUMP的记录如下图所示。 作为一般客户通常只需要收集DUMP信息，并反馈给IBM工程师即可。当发生系统DUMP时，机器将会被宕下来。可能的原因包括：系统在进行内核操作时发生了未知的意外或者不能对其进行正常处理，都会引起DUMP。也可以由系统管理员发出命令，强制系统DUMP。 当系统进行DUMP时，DUMP管理设施自动将内核相关的数据(kernel segment0及其他由内核或者内核扩展程序记录在主DUMP表中的内存块)复制到主DUMP设备。可以把DUMP理解为系统当时的一个快照，供以后分析，分析DUMP可以在其他机器上进行，但需要复制一份此机器的内核程序，即unix_mp或unix_mp64.没有对应于DUMP的内核程序是午饭进行DUMP分析的。 DUMP的生成过程 CORE DUMP的生成过程 在进程运行出现异常行为时，例如无效地址访问、浮点异常、指令异常等，将导致系统转入内核态进行异常处理（即中断处理），向相应的进程发出特定信号例如SIGSEGV、SIGFPE、SIGILL 等。如果应用进程注册了相应信号的处理函数（例如可通过sigaction 注册信号处理函数），则调用相应处理函数进行处理（应用程序可以选择记录信息后生成core dump 并退出）；否则将采取默认动作，例如SIGSEGV 的默认动作是生成core dump 并退出程序。 进程coredump 的时候，操作系统会将进程终止并释放其占用的资源，正常情况下，应用进程coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程，则这些进程会受到影响，至于后果则视其对此异常的具体处理而定。 由于相关指令已经包含在可执行文件中，core 文件一般只包含进程异常时相关的内存信息。其格式可参考/usr/include/sys/core.h 或者AIX 帮助文档的“Files Reference”章节。我们一般需要结合core 文件以及可执行程序，来分析问题所在 注：由于进程信号处理本质上是异步的，应用进程注册的信号处理函数中使用的例程需要保证是异步信号安全的，例如不能使用诸如pthread_ 开头的例程。 系统dump 生成过程 系统异常dump 的具体过程与应用进程类似，但由于更接近底层，为了避免问题所在的资源（例如文件系统）正好包含在生成dump 需要使用的资源中，造成dump 无法生成，操作系统一般会用最简单的方式来生成dump。例如系统内存小于4G 的情况下，一般直接将dump 生成在pagingspace 中；大于4G 时，会建专门的lg_dumplv 逻辑卷（裸设备），默认的dump设备/dev/hd6，次设备是/dev/sysdumpnull 保存dump 信息。在系统重启的时候，如果设置的DUMP 转存目录（文件系统中的目录）有足够空间，它将会转存成一个文件系统文件，缺省情况下，是/var/adm/ras/ 下的vmcore* 这样的文件。 下面是常见的转储设备大小规则 当服务器的内存大于4GB时，在安装AIX时，就会为系统dump 创建一专用区域，该逻辑卷名就是lg_dumplv. 其缺省大小是按以下规则分配的： 4GB < = 服务器的内存〈12GB lg_dump 的大小为1GB 12GB < = 服务器的内存〈24GB lg_dump 的大小为2GB 24GB < = 服务器的内存〈48GB lg_dump 的大小为3GB 48GB < = 服务器的内存lg_dump 的大小为4GB 系统dump 一般可以通过升级微码、提高系统补丁级别、升级驱动等方式解决。
当主机crash后，会在这个目录下生成vmcore，也就是dump，如何分析这个dump来定位宕机的原因呢? 可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式（vnlinux这里要指定的） 他会报错，原因应该是缺乏kernel-debuginfo包，我们安装下后再尝试： 要想crash可以分析core-dump，必须要安装这三个包： 安装完后，我们可以利用find / -name vmlinux 上面的crash爆出了： 报错，这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。 （说下：要想使用crash，只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样，任意一个不一致都会导致不能分析dump）
# # 选择包和版本 # 再选择show debug package
找到debug包 下载就可以了 ---------------------------------------- 然后安装一下： #安装包开始 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本，可以cd /var/crash/127.0.0.1---------/ 然后执行 strings vmcore |grep 'OSRELEASE' 可以显示出vmcore的内核版本 顺便附一下内核版本和系统版本的对应关系 CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71 CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131 CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220 CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279 CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358 CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431 CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump
查看文章 Tcpdump文件格式和结构 2009-04-13 14:07 前言：层层剖析Tcpdump文件格式。 当你在Windows或者Linux环境下用tcpdump命令抓取数据包时，你将得到如下格式的tcpdump文件： 文件头| 数据包头 | 链路层数据 | 数据包头 | 链路层数据 | 数据包头 | 链路层数据 |...... 1. 文件头：每一个文件都以一个24字节的文件头开头。前四个字节是tcpdump 文件标志“A1 B2 C3 D4”或为“D4 C3 B2 A1”。 2. 数据包头 | 链路层数据：文件头之后，就是“数据包头 | 链路层数据”为一组的这样一组组数据。 3. 数据包头长度16个字节，它不是网路上真正传输的数据，它包含的信息主要是截获这个包的时间等信息。数据包头的第8-11和12-15字节（按编程习惯，第一个字节为0字节）表示后面链路层数据包的长度。8-11字节是其理论长度，12-15字节为其实际长度，如果存在截断情况，两者可能不同。如果在tcpdump 命令中使用了 -s 0 参数，则8-11字节和12-15字节应该相等。 从数据包头结束，到长度指明的字节数为止，是实际在网络中传输的链路层数据包。然后，就是下一个数据包头。 4. 链路层数据 链路层数据包格式和传输的方式有关：局域网共享上网，则是RFC894以太网协议，少数情况下是RFC 1042和802.3协议；如果是Modem拨号上网，则是RFC 1055的SLIP协议；如果是ADSL，则是RFC 1548的PPP协议。RFC894/RFC 1042/RFC 1548这三种协议的格式都是： 包头 | IP数据包 |（包尾） 对于RFC894,包头长度为14字节； ------>局域网方式上网； 对于RFC1042,包头长度为22字节； 对于RFC1548,包头长度为5字节；------>ADSL方式上网； 跨过这些包头字节，就是IP数据包了。 5.IP数据包： IP数据包格式为： IP包头 | IP包数据
关于分析DUMP文件的一些想法： 在分析一个驱动蓝屏的时候，如果有驱动的PDB文件就很容易找到出错的地方，然是如果没有PDB文件，往往比较麻烦，只能给出个大题的东西，今天调试了一下DUMP文件，有点感触，先来分析一下， 双机调试的方法不说了，直接开始调试：加载驱动文件，直接蓝屏了，这个时候WINDBG 给出了一下提示： FOLLOWUP_IP: HelloDDK+5ae f7c455ae 8be5 mov esp,ebp BUGCHECK_STR: 0x7E DEFAULT_BUCKET_ID: NULL_DEREFERENCE LAST_CONTROL_TRANSFER: from f7c455ae to 8060d589 STACK_TEXT: f7a01c54 f7c455ae 00000000 0000000a 0000000a nt!ProbeForWrite+0x39 WARNING: Stack unwind information not available. Following frames may be wrong. f7a01c74 f7c45504 f7a01d4c 805777f1 864d2b10 HelloDDK+0x5ae f7a01c7c 805777f1 864d2b10 860cd000 00000000 HelloDDK+0x504 f7a01d4c 80577901 800008a8 00000001 00000000 nt!IopLoadDriver+0x66d f7a01d74 80535c32 800008a8 00000000 865b4020 nt!IopLoadUnloadDriver+0x45 f7a01dac 805c71e0 f7a69cf4 00000000 00000000 nt!ExpWorkerThread+0x100 f7a01ddc 80542e12 80535b32 00000001 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: HelloDDK+5ae FOLLOWUP_NAME: MachineOwner MODULE_NAME: HelloDDK IMAGE_NAME: HelloDDK.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4d60d8a6 STACK_COMMAND: .cxr 0xfffffffff7a01880 ; kb FAILURE_BUCKET_ID: 0x7E_HelloDDK+5ae
Linux网络协议分析工具tcpdump和tshark用法Tcpdump是网络协议分析的基本工具。tshark是大名鼎鼎的开源网络协议分析工具wireshark（原名叫ethereal）的命令行版本，wireshark 可对多达千余种网络协议进行解码分析。Wireshark和tcpdump均使用libpcap库（参见libpcap编程教程）进行网络截包。TCPDUMP 详细manpage参见tcpdump网站。基本用法Tcpdump的参数基本分为两块:选项（options）和过滤器表达式（filter_expression）Tcpdump是网络协议分析的基本工具。tshark是大名鼎鼎的开源网络协议分析wireshark（原名叫ethereal）的命令行版本，wireshark可对多达千余种网络协议进行解码分析。Wireshark和tcpdump均使用libpcap库（参见libpcap编程教程）进行网络截包。 TCPDUMP 详细manpage参见tcpdump网站。 基本用法 Tcpdump的参数基本分为两块:选项（options）和过滤器表达式（filter_expression）。
# tcpdump [options] [filter_expression] 例如 # tcpdump -c 100 -i eth0 -w log tcpdst port 50000 其中options部分参数： -c 100 指定截取的包的数量 -i eth0 指定监听哪个网络端口 -w log 输出到名为log的文件中（libpcap格式） filter_expression参数为tcpdst port 50000，即只监听目标端口为50000的tcp包。 更多的例子： /* 监视目标地址为除内网地址(192.168.3.1-192.168.3.254)之外的流量*/ # tcpdumpdst net not 192.168.3.0/24 /*
使用dump文件分析系统蓝屏原因 出处：https://www.doczj.com/doc/fb12936405.html,/746253/709702 目录 1 什么是dump文件 2 如何让系统在崩溃时记录dump文件 3 使用Debugging Tools for Windows (windebug)来分析dump文件 3.1 什么是windebug 3.2 windebug最新版安装方法（此方法为在线安装） 3.3 windebug的symbol符号文件的路径配置 3.4 dump文件的分析
1 什么是dump文件 当系统崩溃在蓝屏瞬间，系统会形成一个扩展名为dmp的存储器转储文件，默认存储位置为C：\WINDOWS\Minidmp。 2 如何让系统在崩溃时记录dump文件 A．右击“我的电脑”选择“属性”，在“系统属性”对话框中选择“高级” B.在“启动和故障恢复”中选择“设置”，具体设置如下图所示
3 使用Debugging Tools for Windows (windebug)来分析dump文件 3.1什么是windebug windebug是微软发布的一款相当优秀的源码级(source-level)调试工具，可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。 3.2 windebug最新版安装方法（此方法为在线安装） A.从https://www.doczj.com/doc/fb12936405.html,/download/en/details.aspx?displaylang=en&id=8279下载 B.安装netFramework2.0 C.运行1中下载的winsdk_web.exe
调试SQLSERVER生成dump文件的方法 我们知道调试程序主要有两种方法 一种是：live debugging （附加进程使进程hang住）生产环境最好不要live debugging 一种是：post-mortem debugging or reading dump files （生成dump文件然后进行分析） 现在介绍一下如何生成dump文件，以及各种方法的差异 第一步：确定SQLSERVER的进程ID 由于我的机器安装了四个SQLSERVER实例，所以看到会有四个进程 方法1：在cmd窗口输入下面命令 tasklist | find /i "sqlservr" 方法2：打开任务管理进行查看
方法3：在SSMS里执行下面sql语句 SELECT SERVERPROPERTY('PROCESSID') AS sqlpid 方法4：从SQL errorlog里获取进程ID EXEC[sys].[sp_readerrorlog]
第二步：生成DUMP文件 方法1：使用SqlDumper 最一般的方法就是使用SQLSERVER内部的SqlDumper程序，如果使用默认安装路径default installation path 会是 C:\Program Files\Microsoft SQL Server\100\Shared
语法如下： SqlDumper
j a v a d u m p分析
Java 的线程 线程是指能独立于程序的其它部分运行的执行单元。 JAVA语言能够很好的实现多线程的程序。我们在调试程序，或者在开发后期需要做性能调优的时候，往往也需要了解当前程序正在运行的线程的状态，正在执行的操作，从而分析系统可能存在的问题。 在阅读本文之间，应对 Java线程的编程原理，同步机制有一定了解 . 产生 JAVA线程 dump JAVA 的线程 DUMP，就象当前 JAVA进程的一个快照，打印出所有线程的状态和调用堆栈，以及 Monitor的状态。在不同的操作系统下，产生线程 DUMP 的方式是不同的。 在启动程序的控制台里敲： Ctrl - Break，线程的 dump会产生在标准输出中（缺省标准输出就是控制台，如果对输出进行了重定向，则要查看输出文件）。在 unix， linux和 MacOS 环境中，在控制台中敲： Ctrl-\，或者， 用“kill -3
1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。本文中，只以 SUN的 hotspot JVM 5.0_06 为例。 2. 在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。线程分析： 1. JVM 线程 在线程中，有一些 JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等等任务，这些线程往往在 JVM初始化的时候就存在，如下所示： "Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000] "CompilerThread0" daemon prio=10 tid=0x08143c58 nid=0x6 waiting on condition [0x00000000..0xfb5fd798] "Signal Dispatcher" daemon prio=10 tid=0x08142f08 nid=0x5 waiting on condition [0x00000000..0x00000000] "Finalizer" daemon prio=10 tid=0x08137ca0 nid=0x4 in Object.wait() [0xfbeed000..0xfbeeddb8] at https://www.doczj.com/doc/fb12936405.html,ng.Object.wait(Native Method) - waiting on <0xef600848> (a https://www.doczj.com/doc/fb12936405.html,ng.ref.ReferenceQueue$Lock) at https://www.doczj.com/doc/fb12936405.html,ng.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0xef600848> (a https://www.doczj.com/doc/fb12936405.html,ng.ref.ReferenceQueue$Lock) at https://www.doczj.com/doc/fb12936405.html,ng.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at https://www.doczj.com/doc/fb12936405.html,ng.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
系统蓝屏，死机抓取dump方法 1：首先声明，介于很多情况下机器不明原因死机，重启或者蓝屏。影响了很多问题的排查。于此，写此贴跟进，以方便对此问题有应对之策，乃下下策。实在无招的情况下，才建议是用。 2：暂时我们先不讨论在有网维大师客户端的情况下的一些设置，先对正常系统状态下的蓝屏设置进程系统调校。 3：蓝屏文件需要debugview查看，要有一定的反向工程基础，代码编写能力和汇编理解能力。 废话不多说。请看实际内容： 1：先在注册表里添加一项键值，以实现机器死机的情况下，触发蓝屏的操作。 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Param eters] "PollingIterations"=dword:00002ee0 "PollingIterationsMaximum"=dword:00002ee0 "ResendIterations"=dword:00000003 "LayerDriver JPN"="kbd101.dll" "LayerDriver KOR"="KBD101A.DLL" "CrashOnCtrlScroll"=dword:00000001 含义：是在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters 下面新建一个DWORD的值CrashOnCtrlScroll为1 重新引导后，寻找两次scrolllock键击，同时右ctrl键也被压下。 这样就可以提取到死机，无响应的dump文件 注意:使用手动提取dump文件，必须是ps2键盘 2：下图的相关设置:
Java线程dump分析 金蝶中间件有限公司 2013年3月14日
版本历史 (2) 目录 (3) 第1章JAVA线程DUMP (4) 1.1什么是J AVA线程D UMP (4) 1.2如何生成 (4) 第2章线程DUMP分析 (5) 2.1JVM线程 (5) 2.2线程状态分析 (5) 2.2.1Runnable (5) 2.2.2Waiting on condition (5) 2.2.3Waiting for monitor entry 和in Object.wait() (6) 2.3JDK5.0的LOCK (8) 第3章案例分析 (9) 3.1死锁 (9) 3.2热锁 (9)
1.1 什么是Java线程Dump 线程Dump是非常有用的诊断Java应用问题的工具，每一个Java虚拟机都有及时生成显示所有线程在某一点状态的线程Dump的能力。虽然各个Java虚拟机线程dump打印输出格式上略微有一些不同，但是线程dump出来的信息包含线程基本信息；线程的运行状态、标识和调用的堆栈；调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。 JVM（java虚拟机）中的许多问题都可以使用线程Dump文件来进行诊断，其中比较典型的包括线程阻塞，CPU 使用率过高，JVM Crash，堆内存不足，和类装载等问题。 1.2 如何生成 在不同的操作系统下，产生线程DUMP的方式是不同的： 1)在windows环境中 在启动程序的控制台里敲：Ctrl - Break，线程的dump会产生在标准输出中（缺省标准输出就是控制台，如果对输出进行了重定向，则要查看输出文件）。 2)在unix，linux和MacOS 环境中 在控制台中敲：Ctrl-\，或者，用“kill -3
1关键字 Tcpdump，丢包，抓包 2Tcpdump抓包的作用 Tcpdump是linux系统自带的抓包工具，功能： >抓进出Linux服务器的IP包 >抓下的IP包，可由WireShark等工具，解码为UDP和RTP包。 >抓下的IP包，可由WireShark等工具分析丢包情况 3Tcpdump常用方法 Tcpdump是linux系统自带的抓包工具，需要root权限才能运行。 //抓网卡eth2上所有进出的数据包，如果没有数据包，则通常会抓到广播包 数会保留所有TS数据包，故重要。 3.4指定入向端口 设入向端口为11866，转换为十六进制，即是0x2e5a，所以： 其中,ether[36]和ether[37]为接收端口的16进制表示。 3.5指定出向端口 其中, Ether[34]和ether[35]为发送端口的16进制表示。 3.6长时间抓包 在抓包命令后加“-C 100”，它会满100M后写到下一个新的文件。直到磁盘满。 3.7后台执行 在抓包命令最后面再加一个&，这样可以后台一直抓。这样的话，登录窗口可以关掉。你想停止抓包，则得用PS把进程杀死。
4抓包分析快进快退 4.1找关键帧 RTP包是否为关键帧的标识保存在RTP扩展位中。WireShark查看RTP包是否为关键帧。 00或者10：普通帧 20或者30: 关键帧首包 40或者50: 关键帧中间包 80或者90: 关键帧尾包 注：以上判断之所以有“或者”，是因为关键帧位只占了3比特。 4.2判断时戳 如果抓包为32倍速，要判断时戳是否正常，则可以用抓包里的： （最大时戳-最小时戳）/90000/倍速=倍速播放时常
产生时间 Java程序运行时，有时会产生JavaCore及HeapDump文件，它一般发生于Java程序遇到致命问题的情况下。 ?有时致命问题发生后，Java应用不会死掉，还能继续运行； ?但有时致命问题发生，Java进程会死掉； 为了能够保留Java应用发生致命错误前的运行状态，JVM在死掉前产生两个文件，分别为JavaCore及HeapDump文件。 有何区别 JavaCore是关于CPU的，而HeapDump文件是关于内存的。 ?JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。它是一个文本文件，打开后可以看到每一个线程的执行栈，以stack trace的显示。通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，例如数据库查询，长期得不到响应，最终导致系统崩溃等情况。 ?HeapDump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况，这种文件需要相应的工具进行分析，如IBM Heap Analyzer这类工具。这类文件最重要的作用就是分析系统中是否存在内存溢出的情况。 怎么生成 这两个文件可以用手工的方式生成，当我们会遇到系统变慢或无响应的情况，这时就以采用手工的方式生成JavaCore及HeapDump文件。 在Unix/Linux上，产生这两个文件的方法如下： # ps -ef | grep java user 46164582017:30 pts/0 00:00:00 grep java root 558010 Oct27 ? 00:02:27/usr/bin/java -server -XX:PermSize=64M-XX:MaxPermSi ze=128m-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.uti l.logging.config.file=/usr/local/tomcat8090/conf/logging.properties-Djava.endorsed.dirs=/u sr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar -Dcatali na.base=/usr/local/tomcat8090-Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/ usr/local/tomcat8090/temp org.apache.catalina.startup.Bootstrap start # kill -3 5580
简单分析dump出来的oracle数据块 一．dump数据块 oracle的rowid中包含着这条数据对象号，数据文件号，数据文件中的块号以及块中的行号，并且这些都可以通过dbms_rowid这个包转成具体的数字出来 SQL>select dbms_rowid.ROWID_RELATIVE_FNO(rowid)as file#,dbms_rowid.ROWID_BLOCK_NUMBER(rowid)as block#,dbms_rowid.ROWID_ROW_NUMBER(rowid)as row#,a.*from paololiu.test1a; FILE#BLOCK#ROW#AAA BBB ------------------------------------------------------------------------------------- 61310abc abc 61311111111 61312ab12ab12 可以看tset1表中的三条记录都在第6号文件的131号块上，并分别在这个块的第0,1,2行上。通过dump命令就可以把这整个块都dump出来的： SQL>alter system dump datafile6block131; System altered. dump出来的文件在user_dump_dest参数设定的目录内，以
使用Crash 工具分析Linux dump 文件江卫, 系统工程师, 西艾（广州）软件开发有限公司 简介： Linux 内核由于其复杂性，使得对内核出现的各种异常的追踪变得异常困难。本文将介绍内核中的内存转储机制，以及如何使用crash 工具对内核产生的内存存储文件进行分析。通过对本文的学习，读者可以像专业内核开发者那样去追踪和修复内核的错误。 本文的标签：crash, dump, linux, 使用, 工具分析, 文件 标记本文！ 发布日期： 2010 年3 月29 日 级别：中级 访问情况： 8721 次浏览 评论： 0 (查看 | 添加评论 - 登录) 平均分(23个评分) 为本文评分 前言 Linux 内核（以下简称内核）是一个不与特定进程相关的功能集合，内核的代码很难轻易的在调试器中执行和跟踪。开发者认为，内核如果发生了错误，就不应该继续运行。因此内核发生错误时，它的行为通常被设定为系统崩溃，机器重启。基于动态存储器的电气特性，机器重启后，上次错误发生时的现场会遭到破坏，这使得查找内核的错误变得异常困难。 内核社区和一些商业公司为此开发了很多种调试技术和工具，希望可以让内核的调试变得简单。其中一种是单步跟踪调试方法，即使用代码调试器，一步步的跟踪执行的代码，通过查看变量和寄存器的值来分析错误发生的原因。这一类的调试器有gdb，kdb，kgdb。另一种方法是在系统崩溃时，将内存保存起来，供事后进行分析。多数情况下，单步调式跟踪可以满足需求，但是单步跟踪调试也有缺点。如遇到如下几种情况时： ?错误发生在客户的机器上。 ?错误发生在很关键的生产机器上。 ?错误很难重现。 单步调试跟踪方法将无能为力。对于这几种情况，在内核发生错误并崩溃的时候，将内存转储起来供事后分析就显得尤为重要。本文接下来将介绍内核的内存转储机制以及如何对其进行分析。 回页首内核的内存转储机制 由于Linux 的开放性的缘故，在Linux 下有好几种内存转储机制。下面将对它们分别做简要的介绍。 LKCD LKCD(Linux Kernel Crash Dump) 是Linux 下第一个内核崩溃内存转储项目，它最初由SGI 的工程师开发和维护。它提供了一种可靠的方法来发现、保存和检查系统的崩溃。LKCD 作为Linux 内核的一个补丁，它一直以来都没有被接收进入内核的主线。目前该项目已经完全停止开发。