dump文件

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> core dump在应用crash掉之后对问题的诊断是很有帮助的。而在默认安装的时候core dump是关闭状态的。 问题一：如何查看系统是否打开了core dump 使用【ulimit -c】查看core dump是否打开。如果结果为0，则表示此功能处于关闭状态，不会生成core文件 问题二：如何打开core dump 方法一：命令行方式【ulimit -c 1024】，在这个例子中打开了core dump 同时限制文件大小为1024k，现在的程序占用内存都比较凶猛，以前写C程序需要计算内存的时代已经过去了。如果不加限制，可能一个core文件，几个G就出去了～，当然没有限制的方式还是有的【ulimit -c unlimited】 方法二：配置profile文件，打开/etc/profile文件，在里面可以找到【ulimit -S -c 0 > /dev/null 2>&1】，将它改成【ulimit -S -c unlimited > /dev/null 2>&1】 方法三：修改/etc/security/limits.conf文件，添加【* soft core 0】，这个方法可以针对指定用户或用户组打开core dump【user soft core 0或 @group soft core 0】

转载： http://blog.csdn.net/kevin_luan/article/details/8447896 http://liulinxia02.blog.163.com/blog/static/26868772009111861834942/ http://zhumeng8337797.blog.163.com/blog/static/100768914201242410583187/ 其中jmap是java自带的工具 查看整个JVM内存状态 jmap -heap [pid] 要注意的是在使用CMS GC 情况下，jmap -heap的执行有可能会导致JAVA 进程挂起 查看JVM堆中对象详细占用情况 jmap -histo [pid] 导出整个JVM 中内存信息 jmap -dump:format=b,file=文件名 [pid] jhat是sun 1.6及以上版本中自带的一个用于分析JVM 堆DUMP 文件的工具，基于此工具可分析JVM HEAP 中对象的内存占用情况 jhat -J-Xmx1024M [file] 执行后等待console 中输入start HTTP server on port 7000 即可使用浏览器访问 IP：7000 eclipse Memory Analyzer Eclipse 提供的一个用于分析JVM 堆Dump文件的插件

转自：http://blog.csdn.net/normallife/article/details/53818997 今天程序Crash,去追踪，找core dump,始终没有找到，后来到了/proc/sys/kernel/core_pattern这个文件夹下找到。 在linux平台下，设置core dump文件生成的方法： 1) 在终端中输入ulimit -c 如果结果为0，说明当程序崩溃时， 系统 并不能生成core dump。 2) 使用ulimit -c unlimited命令，开启core dump功能，并且不限制生成core dump文件的大小。如果需要限制，加数字限制即可。ulimit - c 1024 3) 默认情况下，core dump生成的文件名为core，而且就在程序当前目录下。新的core会覆盖已存在的core。通过修改/proc/sys/kernel/core_uses_pid文件，可以将进程的pid作为作为扩展名，生成的core文件格式为core.xxx，其中xxx即为pid 4) 通过修改/proc/sys/kernel/core_pattern可以控制core文件保存位置和文件格式。例如：将所有的core文件生成到/corefile目录下，文件名的格式为core-命令名-pid-时间戳. echo "/corefile/core-%e-%p-%t"

　　也不知道曾几何时，Windows就为了调试应用程序崩溃、蓝屏等错误加了很多log和dump。所谓dump，就是将内存里的部分或全部数据写到文件中，以便开发者、程序员查看和调试，发现问题所在。比如在系统属性里，高级——启动和故障恢复——写入调试信息，一般用户版本的Windows（Win2000 Pro, WinXP）都是小内存转储（Small memory dump, 64K），而服务器版本的Windows默认是完全内存转储。又比如Drwatson（华生医生，在附件——系统工具——系统信息，工具菜单中可以找到），默认是应用程序崩溃后创建崩溃的dump文件，一般在C:\Documents and Settings\Administrator\Local Settings\Application Data\Microsoft\Dr Watson\目录下会有user.dmp文件，如果不删除，会占用越来越大的空间。当然可以通过配置drwatson，让它不产生dump文件。其实普通用户根本用不着这些转储文件，最多看看log就行了。而过多的dump文件除了占用硬盘空间，一点用处都没有。 　　但现在又多了个PCHealth（好像从WinME开始就有的？），似乎也是用来记录系统运行情况的，但没有对外可以配置的界面（？），而且它会不声不响地在应用程序崩溃时也进行dump，在C:\WINDOWS

一般我们抓取的dump文件后堆栈大都是这样的： 0:028> kb *** ERROR: Symbol file could not be found. Defaulted to export symbols for kernel32.dll - ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 027acff8 7c802542 00000c34 ffffffff 00000000 ntdll!KiFastSystemCallRet *** WARNING: Unable to verify timestamp for baidubrowser.exe 027ad00c 00401711 00000c34 ffffffff 4ca336f9 kernel32!WaitForSingleObject+0x12 027af13c 00401440 4ca31791 00000000 7c885780 baidubrowser!BDExceptionHandler::GenerateExceptionReport+0x261 027af164 7c864191 027af3fc 00000000 00000000

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 当服务器挂起 , 崩溃或者性能底下时 , 就需要抓取服务器的线程堆栈 (Thread Dump) 用于后续的分析 . Thread dump 提供了当前活动的线程的快照 . 它提供了 JVM 中所有 Java 线程的栈跟踪信息 有很多方式可用于获取 Thread Dump, 一些是操作系统特定的命令 . 操作系统命令获取 ThreadDump: Windows: 1. 转向服务器的标准输出窗口并按下 Control + Break 组合键 , 之后需要将线程堆栈复制到文件中 UNIX/ Linux 首先查找到服务器的进程号 (process id), 然后获取堆栈 . 1. ps –ef | grep java 2. kill -3 <pid> 注意一定要谨慎 , 一步不慎就可能让服务器进程被杀死 ! JVM 自带的工具获取线程堆栈 : JDK 自带命令行工具获取 PID 并做 ThreadDump: 1. jps 2. jstack <pid> 使用 JVisualVM: Threads 标签页 à ThreadDump 按钮 . WebLogic 自带的获取 thread dump 的工具 : 1. webLogic.Admin 工具 a. 打开命令提示符 , 通过运行 <DOMAIN_HOME>/bin

一. dump基本概念 在故障定位(尤其是out of memory)和性能分析的时候，经常会用到一些文件来帮助我们排除代码问题。这些文件记录了JVM运行期间的内存占用、线程执行等情况，这就是我们常说的dump文件。常用的有heap dump和thread dump（也叫javacore，或java dump）。我们可以这么理解：heap dump记录内存信息的，thread dump是记录CPU信息的。 heap dump： heap dump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况。HeapDump文件是指定时刻的Java堆栈的快照，是一种镜像文件。Heap Analyzer工具通过分析HeapDump文件，哪些对象占用了太多的堆栈空间，来发现导致内存泄露或者可能引起内存泄露的对象。 thread dump： thread dump文件主要保存的是java应用中各线程在某一时刻的运行的位置，即执行到哪一个类的哪一个方法哪一个行上。thread dump是一个文本文件，打开后可以看到每一个线程的执行栈，以stacktrace的方式显示。通过对thread dump的分析可以得到应用是否“卡”在某一点上，即在某一点运行的时间太长，如数据库查询，长期得不到响应，最终导致系统崩溃。单个的thread dump文件一般来说是没有什么用处的

现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。 A、 jps(Java Virtual Machine Process Status Tool) jps主要用来输出JVM中运行的进程状态信息。语法格式如下： 1 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： 1 -q 不输出类名、Jar名和传入main方法的参数 2 -m 输出传入main方法的参数 3 -l 输出main类或Jar的全限名 4 - v 输出传入JVM的参数 比如下面： 1 root @ubuntu :/ # jps -m -l 2 2458 org.artifactory.standalone.main.Main /usr/ local

Core dump: 在程序运行过程中异常终止或崩溃，操作系统将当时的内存状态记录下来，保存在一个文件中。 其中会包含寄存器信息（包括程序指针，栈指针等），内存管理信息，操作系统状态等信息。 linux 中默认忽略 Stop信号、Terminate信号、Ignore信号等，如果信号在默认情况下，在下列几种信号发生时 会产生core dump: SIGQUIT(quit from keyboard ), SIGILL(illegal instruction), SIGABRT(abort signal), SIGSEGV(invalid memory reference), SIGTRAP(trace/breakpoint trap) ctrl+z 挂起进程 SIGTSTP信号(默认为暂停进程) ctrl+c终止进程 SIGINT信号(默认为终止进程) ctrl+\ （默认SIGQUIT信号）产生core dump 打开core dump： 在终端输入 ulimit -c ,输出为0，说明默认是关闭core dump的 输入 ulimit -c unlimited 开启core dump功能，并且不限制core dump文件的大小，如果要限制文件大小， 将unlimited改成需要的文件大小，单位为blocks(KB) 以上命令支队当前终端有效，如果永久有效，可以修改/etc

最近在做QT相关的项目，发现QT插件创建的工程生成的pdb文件没有有效信息，于是与普通工程对比了一下发现了问题所在。所以总结一下pdb文件生成的配置： 配置这两项之后就会生成具有有效格式的pdb了，这里面应该会包含编译时代码的路径，exe和pdb文件的路径。但是实际上在调试dump的时候这些路径不一定还存在。所以需要手动配置，VS很友好，缺少信息时会自动报出。 上面的信息提示没有找到pdb，提示了原始exe的位置，所以这里需要手动设置pdb位置 在这里直接将exe和pdb都放在这个目录下，就不需要设置多次了。点击加载之后: 这里已经打印出了堆栈，但是并没有详细的源代码信息，所以这里需要设置一下对应版本的源代码位置: 右键解决方案->属性->调试源文件->设置路径: 重新启动调试dump: 源代码这样也加载进来了，情况一清二楚。 最近在做QT相关的项目，发现QT插件创建的工程生成的pdb文件没有有效信息，于是与普通工程对比了一下发现了问题所在。所以总结一下pdb文件生成的配置： 来源： CSDN 作者： Freedom3568 链接： https://blog.csdn.net/zhanggqianglovec/article/details/103456713