查看整个JVM内存状态 jmap -heap [pid]要注意的是在使用CMS GC 情况下,jmap -heap的执行有可能会导致JAVA 进程挂起 查看JVM堆中对象详细占用情况jmap -histo [pid] 只打印活跃对象 jmap -histo[:live] <pid> 导出整个JVM 中内存信息 dump堆 当OLD区域占用大于90%的时候dump下来用MemoryAnalyzer分析用jmap -dump:live,format=b,file=tai.dump pidjmap

背景:很多情况下程序崩溃我们只能看到程序抛出来的异常信息,但是有时候异常信息不清不楚我们处理异常还是一头雾水,这种情况下我们就很希望能有种办法获取程序运行时的内存进行调试,查看其中的变量.参数.方法执行情况等信息,这里就提供一种异常时将程序的异常时内存信息导出到文件的方法,这是当初设计渲染监控日志时的一个初步设想,想错误内存导出保存起来帮助分析处理异常,但是与渲染的同事接触后了解到渲染时内存达10G,导出太占资源便放弃了,这里只抛砖引玉跟大家介绍有这种东西如有需要再进行深入研究,这种方法在C++

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

调试技巧 —— 如何利用windbg + dump + map分析程序异常 逗比汪星人2011-09-04上传   调试技巧 —— 如何利用windbg + dump + map分析程序异常 http://blog.csdn.net/wangningyu/article/details/6748138 http://download.csdn.net/detail/wangningyu/3575167

原文地址: http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Obje

原文链接:http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html 转来当笔记^_^ jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象

背景 用jmap打dump文件经常遇到如下异常,打不出来,哥今天告拆大家一个终极解决方法,嘘,不要告拆别人.. Attaching to core -F from executable 421442, please wait...Error attaching to core file: cannot open binary filesun.jvm.hotspot.debugger.DebuggerException: cannot open binary file at sun.jvm.hot

Dump 文件分析很大程度上就是分析蓝屏产生的原因.这种系统级的错误算是Windows提示错误中比较严重的一种(更严重的还有启动黑屏等硬件或软件兼容性错误等等).说它是比较严重,是因为毕竟Windows还提供了dump文件给用户分析,至少能比较容易的找到错误的原因.一般蓝屏要么是内核程序中的异常或违规,要么是数据结构的损坏,也有boot或shutdown的时候内核出错.有时候蓝屏是一闪而过,紧接着是系统重启:有时候是蓝屏等待.总之蓝屏的时候都提示了一些停止代码和错误信息,不过这些提示是不全面的,

jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Object.wait() 或 TIMED_WAITING 阻塞,Blocked(重点关注)   停止,Parked 下面我们先从第一个例子开始分析,然后再列出不同线程

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

登录系统(注意这里启动 tomcat 的用户) # 获取 tomcat 的 pid 号 ps -ef|grep tomcat # 例如这里 pid 号为 13133 jmap -dump:live,format=b,file=dump.hprof 13133 使用 MAT 分析 # MAT 下载地址:https://www.eclipse.org/mat/downloads.php # 我这里下载的 windows 版本,解压后,按需更改 MemoryAnalyzer.ini 里面的配置,我改成

jhat 是Java堆分析工具(Java heap Analyzes Tool). 在JDK6u7之后成为标配. 使用该命令需要有一定的Java开发经验,官方不对此工具提供技术支持和客户服务. 用法: jhat [ options ] heap-dump-file 参数: options 可选命令行参数,请参考下面的 Options heap-dump-file 要查看的二进制Java堆转储文件(Java binary heap dump file). 如果某个转储文件中包含了多份 heap d

前言 我们在发布了自己的App以后,Windows Phone的Error Report机制会帮助我们收集程序的崩溃信息并发送到微软的服务器上,这可以辅助开发者提高App的稳定性. 那么如何利用这些dump file呢?首先我们需要下载这些dump file从微软开发者网站,然后借助调试工具进行分析,我们这里选用Windbg. 下载步骤 1. 登录http://dev.windows.com/en-us/dashboard 2. 选择Windows Phone Store 3. 进入Report

一.Thread Dump介绍 1.1什么是Thread Dump? Thread Dump是非常有用的诊断Java应用问题的工具.每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread dump略有不同,但是大多都提供了当前活动线程的快照,及JVM中所有Java线程的堆栈跟踪信息,堆栈信息一般包含完整的类名及所执行的方法,如果可能的话还有源代码的行数. 1.2 Thread Dump特点 1. 能在各种操作系统下使用 2.

转载:https://www.cnblogs.com/firstdream/p/8109352.html 这里对linux下.sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结: linux环境下,当发现java进程占用CPU资源很高,且又要想更进一步查出哪一个java线程占用了CPU资源时,按照以下步骤进行查找: (一):通过[ top  -p 12377 -H] 查看java进程的有哪些线程的运行情况:       和通过[jstack 12377 > stack.log]

作者:张振华(Jack) 这里对linux下.sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结: linux环境下,当发现java进程占用CPU资源非常高,且又要想更进一步查出哪一个java线程占用了CPU资源时,依照下面步骤进行查找: (一):通过[top -p 12377 -H] 查看java进程的有哪些线程的执行情况.       和通过[jstack 12377 > stack.log]生成Java线程的dump具体信息. 先用top命令找出占用资源厉害的java进程

Bulk异常引发的Elasticsearch内存泄漏 2018年8月24日更新: 今天放出的6.4版修复了这个问题. 前天公司度假部门一个线上ElasticSearch集群发出报警,有Data Node的Heap使用量持续超过80%警戒线. 收到报警邮件后,不敢怠慢,立即登陆监控系统查看集群状态.还好,所有的结点都在正常服务,只是有2个结点的Heap使用率非常高.此时,Old GC一直在持续的触发,却无法回收内存.   Heap Used % 初步排查 问题结点的Heap分配了30GB,80%的

一.背景 今天下午,正酣畅淋漓的搬砖,突然运维同事在群里通知,核心服务某个节点内存异常,服务假死.神经一下子紧张起来,赶紧跑到运维那边观察现象. 观察的结果是服务内存溢出,该服务是核心服务,分配了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 的话: 当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的

Java and Thread 一个 web 服务器使用几十到几百个线程来处理大量并发用户,如果一个或多个线程使用相同的资源,线程之间的竞争就不可避免了,并且有时候可能会发生死锁. Thread contention 是一个线程等待锁的一个状态,这个锁被另外一个线程持有,等待被释放,不同的线程频繁访问 WEB 应用的共享资源.例如,记录一条日志,线程尝试记录日志之前必须先获取锁来访问共享资源. 死锁是线程竞争的一个特殊状态,一个或是多个线程在等待其他线程完成它们的任务为了完成它们自己的任务. 线