VisualVM 是Netbeans的profile子项目,已在JDK6.0 update 7 中自带(java启动时不需要特定参数,监控工具在bin/jvisualvm.exe). https://visualvm.dev.java.net/   一.介绍 VisualVM,能够监控线程,内存情况,查看方法的CPU时间和内存中的对 象,已被GC的对象,反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的).   从界面上看还是比较简洁的,左边是树形结构,自动显示当前本机所运

1.获取dump文件 使用 以下命令 创建 进程PID = 16231的 dump文件,命名为 order.hprof jmap -dump:format=b,file=order.hprof 16231 将文件下载到本地. 2.使用jdk bin目录下的jvisualvm.exe 装入 order.hprof 分析对应对象的占用内存

生成dump文件的命令:jmap -dump:format=b,file=20170307.dump 16048file后面的是自定义的文件名,最后的数字是进程的pid 使用jvisualvm来分析dump文件:jvisualvm是JDK自带的Java性能分析工具,在JDK的bin目录下,文件名就叫jvisualvm.exe.jvisualvm可以监控本地.远程的java进程,实时查看进程的cpu.堆.线程等参数,对java进程生成dump文件,并对dump文件进行分析.像我这种从服务器上dum

转载: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]要注意的

开发调式时,对程序生成dump文件:1:需要生成的时机,加Thread.sleep(600*1000).2:打开jvisualvm找到该程序进程号.3:jmap.

转发自https://blog.csdn.net/MCC_MCC_MCC/article/details/80623156 1.Windows/Linux环境下查看Java进程ID方法 使用Java自带的工具VisualVM工具实现,在CMD或者是Linux终端下执行“jvisualvm”命令即可以进入VisualVM控制台,双击左侧的进程即可以查看到详细的信息. 2.生成DUMP文件 CMD执行“jmap -dump:format=b,file=F:/heamdump.out 16540”命令

一.背景 今天下午,正酣畅淋漓的搬砖,突然运维同事在群里通知,核心服务某个节点内存异常,服务假死.神经一下子紧张起来,赶紧跑到运维那边观察现象. 观察的结果是服务内存溢出,该服务是核心服务,分配了5G内存.运维在转存快照后,立刻重启服务后正常.在接下来的一段时间里,另一台服务节点也发生了同样的情况. 二.分析过程 这个服务是另外一个同事负责开发的,本着学习的态度,在拿到运维转存的dump文件后,就准备尝试着分析下问题,由于之前没有类似的经历,于是先在网上查了下一般怎么分析类似的问题. 首先尝试使

前言 在windows 下 系统核心态程序蓝屏,会产生dump文件. 用户级程序在设置后,程序崩溃也会产生dump文件.以方便开发者用windbg进行分析. so,linux 系统也有一套这样的东东----->Linux Core Dump Linux Core Dump 引用 文章 <Linux Core Dump>  http://www.cnblogs.com/hazir/p/linxu_core_dump.html 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

原文地址:http://gao-xianglong.iteye.com/blog/2173140?utm_source=tuicool&utm_medium=referral 前言 生产环境中,尤其是吃大内存的JVM,一旦出现内存泄露等问题是非常容易引发OutofMemory的,如果没有一个好的工具提供给开发人员定位问题和分析问题,那么这将会是一场噩梦.目前JDK其实自带有一些内存泄露分析工具专门用于帮助开发人员定位内存泄露等问题,但是这些工具往往并不是能够满足一些现状,这里笔者所指的现状更多是

  1.生成core dump文件的方法: $  ulimit -c //查看是否为0 如果为0 $   ulimit -c unlimited 这样在程序崩溃以后会在当前目录生成一个core.xxxx的文件 2.调试core dump文件 生成了core.xxx文件以后 $  gdb ./应用程序  core.xxxx 就会恢复现场到你的程序崩溃的那一刻 (gdb)bt          //这个命令会列出程序崩溃时的堆栈信息,一层一层会有标号  #0  #1  #2 ....... 如果你要

前言 在产品的实际应用环境中,如果我们的程序在客户那里出现了问题,例如程序异常了,而这个时候的现象又不能还原或者很难还原重现,那么只有使用dump文件来保存程序的当前运行信息,例如调用堆栈等,同时使用符号文件来定位问题了;这里主要讲解使用dbghelp库来生成输出dump文件,同时使用符号文件和windbg来分析问题.样例代码 1 #include "stdafx.h" 2 #include <Windows.h> 3 #include <iostream> 4

WinDbg使用有点麻烦,还要符号表什么的.试了下,感觉显示很乱,分析的也不够全面... 试试其他的吧!今天电脑蓝屏了,就使用其dump文件测试,如下: 1.首先,最详细的,要属Osr Online这个在线分析网站了: 打开其分析地址:http://www.osronline.com/page.cfm?name=analyze 下拉,找到上传按钮(上图),将需要分析的dump文件浏览上传即可...dump文件一般在C:\Windows\minidump下 分析完成后生成的内容非常多: 主要看第一

调试SQLSERVER (一)生成dump文件的方法 调试SQLSERVER (二)使用Windbg调试SQLSERVER的环境设置调试SQLSERVER (三)使用Windbg调试SQLSERVER的一些命令 我们知道调试程序主要有两种方法 一种是:live debugging (附加进程 使进程hang住) 生产环境最好不要live debugging 一种是:post-mortem debugging or reading dump files (生成dump文件然后进行分析) 现在介绍一

前言 在开始这篇文章之前我们先来讲讲如何从高度优化的Release版的Dump中找到正确的异常上下文地址,并手动恢复异常发生的第一现场. 1. 什么是异常上下文 简单来说,在windows体系的操作系统里面,每个线程都有自己的线程上下文来保存需要的信息,其中包括当前寄存器的值.我们这里需要找到的异常上下文就是当异常发生的时候,异常分发器帮我们保存的当前寄存器的值(也叫寄存器上下文),利用这些信息结合汇编代码的分析,我们就可以进一步找到发生异常的原因.关于寄存器上下文结构体的定义我们可以在winn

linux下生成core dump文件方法及设置    from:http://www.cppblog.com/kongque/archive/2011/03/07/141262.html core dump的概念: A core dump is the recorded state of the working memory of a computer program at a specific time, generally when the program has terminated a

dump文件可以在程序crash时,方便我们查看程序crash的地方和上下文信息.在window下,要能生成dump文件,需要自己编写相应的代码.不过现在网上可以找到相应的代码,只要把它下载后然后加到自己的工程中去,就可以了! 在linux下面就简单的许多.只要打开相应的开关,linux会自动在程序crash时生成相应的core文件.这个文件和window下的dump文件类似.  下面是简单的一些步骤: 1.查看当前是否已经打开了此开关   通过命令:ulimit -c 如果输出为 0 ,则代表

转载地址:http://erniu.sz.blog.163.com/blog/static/11517292220103282813176/ 把SVN的dump文件导入SVN数据库的方法: 在SVN Server Manager上新建一个Repositories,比如名字为ABCD,则导入命令如下: svnadmin load ABCD > dump文件的全路经 例如:svnadmin load c:\ABCD > d:\abcd.dump

在开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因.缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置: ulimit -c unlimited 上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制. 上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程

前言:通过drwtsn32.NTSD.CDB等调试工具生成Dump文件, drwtsn32存在的缺点虽然NTSD.CDB可以完全解决,但并不是所有的操作系统中都安装了NTSD.CDB等调试工具.了解了mini dump文件格式后,完全可以程序自动生成Dump文件. 本文主要讨论以下内容: 1.  运行原理 2.  程序修改 3.  注意事项 一.   运行原理 当程序遇到未处理异常(主要指非指针造成)导致程序崩溃死,如果在异常发生之前调用了SetUnhandledExceptionFilter(

前言:利用drwtsn32或NTSD进行程序崩溃处理,都可以生成可用于调试的dmp格式文件.使用VS2005打开生成的DMP文件,能很方便的找出BUG所在位置.本文将讨论以下内容: 1.  程序编译选项 2.  利用VS2005 分析dump文件 3.  常见问题讨论 一.       程序编译选项 PDB files contains all debug information like type definition and function prototype. When applicat

GBK Encoding Support 没有安装前打开ASNI格式编码文件会乱码,安装成功重启则可以打开正常 关于.dump文件生成的解释: 当打开一个非utf-8格式且包含汉字的文件时,sublime text 2会自动生成一个dump文件,文件修改过程中,不会修改原文件,只有按"保存"了才会将dump的数据更新到原文件里,关闭当前编辑的dump文件则会自动删除dump文件. 但是有时候 GBK Encoding Support 插件也会出些bug,就想这样,生成.dump文件后自