JMAP

jmap错误:unknown CollectedHeap type : class sun.jvm.hotspot.gc_interface.CollectedHeap

送分小仙女□ 提交于 2019-11-30 07:06:43
使用 jmap -heap 命令查看堆的详细信息报错 Caused by: java.lang.RuntimeException: unknown CollectedHeap type : class sun.jvm.hotspot.gc_interface.CollectedHeap [root@bangbet-java ~]# jmap -heap 27822 Attaching to process ID 27822, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.222-b10 using thread-local object allocation. Parallel GC with 4 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 1073741824 (1024.0MB) NewSize = 536870912 (512.0MB) MaxNewSize = 536870912 (512.0MB) OldSize = 536870912 (512.0MB) NewRatio = 2 SurvivorRatio

MAT使用-jvm内存溢出问题分析定位

烈酒焚心 提交于 2019-11-30 06:35:35
1.MAT简介: MAT 全称 Eclipse Memory Analysis Tools 是一个分析 Java堆数据的专业工具,可以计算出内存中对象的实例数量、占用空间大小、引用关系等,看看是谁阻止了垃圾收集器的回收工作,从而定位内存泄漏的原因。 2.什么时候会用到MAT? a)OutOfMemoryError的时候,触发full gc,但空间却回收不了,引发内存泄露 b)java服务器系统异常,比如load飙高,io异常,或者线程死锁等,都可能通过分析堆中的内存对象来定位原因 3.MAT安装: https://www.eclipse.org/mat/downloads.php --下载地址 http://help.eclipse.org/oxygen/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html --官网使用教程 #参数配置: 分析堆转储文件需要消耗很多的堆空间,为了保证分析的效率和性能,在有条件的情况下,建议分配给 MAT 尽可能多的内存资源。两种方式分配内存资源给 MAT: 1)修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g 2)编辑文件 MemoryAnalyzer.ini 添加 -vmargs – Xmx4g 4.MAT分析dump堆栈: #4.1dump文件生成: a

服务器性能指标 ——负载(Load)分析及问题排查

情到浓时终转凉″ 提交于 2019-11-30 06:25:35
平常的工作中,在衡量服务器的性能时,经常会涉及到几个指标,load、cpu、mem、qps、rt等。每个指标都有其独特的意义,很多时候在线上出现问题时,往往会伴随着某些指标的异常。大部分情况下,在问题发生之前,某些指标就会提前有异常显示。 对于这些指标的理解和查看、异常解决等,是程序员们重要的必备技能。本文,主要来介绍一下一个比较重要的指标——机器负载(Load),主要涉及负载的定义、查看负载方式、负载飙高排查思路等。 什么是负载 负载(load)是linux机器的一个重要指标,直观了反应了机器当前的状态。 来看下负载的定义是怎样的: In UNIX computing, the system load is a measure of the amount of computational work that a computer system performs. The load average represents the average system load over a period of time. It conventionally appears in the form of three numbers which represent the system load during the last one-, five-, and fifteen-minute

Java : Get heap dump without jmap or without hanging the application

六眼飞鱼酱① 提交于 2019-11-30 04:22:43
问题 In few circumstance, our application is using around 12 GB of memory. We tried to get the heap dump using jmap utility. Since the application is using some GB of memory it causes the application to stop responding and causes problem in production. In our case the heap usage suddenly increases from 2-3 GB to 12GB in 6 hours. In an attempt to find teh memory usage trend we tried to collect the heap dump every one hour after restarting the application. But as said since using the jmap causes the

Locating code that is filling PermGen with dead Groovy code

核能气质少年 提交于 2019-11-30 02:45:24
We have had our glassfish instance go down every two weeks for a while with a java.lang.OutOfMemoryError: PermGen space . I increased the PermGen space to 512MB and startet dumping memory usage with jstat -gc . After two weeks I came up with the following graph that shows how the PermGen space is steadily increasing (the units on the x-axis are minutes, y-axis are KB). I tried googling around for some kind of profiling tool that could pinpoint the error and a thread here on SO mentioned jmap, which proved to be quite helpful. Out of the approximately 14000 lines dumped from jmap -permstats

做JAVA开发的同学一定遇到过的爆表问题,看这里解决

一世执手 提交于 2019-11-30 01:19:05
欢迎大家前往 腾讯云+社区 ,获取更多腾讯海量技术实践干货哦~ 本文由 净地 发表于 云+社区专栏 记一次Java线上服务器CPU过载问题的排查过程,详解排查过程中用到的Java性能监测工具:jvisualvm、jstack、jstat、jmap。 背景:Java线上服务运行一周后,某个周六晚上CPU使用率突然持续99%,Java进程处于假死状态,不响应请求。秉着先恢复服务再排查问题的原则,在我连接VPN采用重启大法后,CPU使用率恢复正常,服务也正常响应了,如下图一所示: (图一)CPU使用率图 但是,当晚的并发量也没有比平时高出许多,为什么会突然出现这种CPU爆表的情况?带着这个疑问,我走上了问题排查的道路。 首先,我查了相关的错误日志,发现故障的时间段内有大量的ckv请求超时,但请求超时并不是ckv server的问题,而是ckv client的请求并没有发出去。那么,为什么ckv client的请求没有发出去呢?日志并没有提供更多的信息给我。 于是,我在Java服务上开启了JMX,本地采用jvisualvm来观察Java进程运行时的堆栈内存、线程使用情况。JMX(Java Management Extensions,即Java管理扩展)是Java平台上为应用程序、设备、系统等植入管理功能的框架;jvisualvm是JDK内置的性能分析工具,位于JDK根目录的bin文件夹下面

线上应用故障排查之二:高内存占用

孤街醉人 提交于 2019-11-30 01:16:36
上一篇介绍了 线上应用故障排查之一:高CPU占用 ,这篇主要分析高内存占用故障的排查。 搞Java开发的,经常会碰到下面两种异常: 1、java.lang.OutOfMemoryError: PermGen space 2、java.lang.OutOfMemoryError: Java heap space 要详细解释这两种异常,需要简单重提下Java内存模型。 Java内存模型 是描述Java程序中各变量(实例域、静态域和数组元素)之间的关系,以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。 在Java虚拟机中,内存分为三个代:新生代( New )、老生代( Old )、永久代( Perm )。 (1)新生代New:新建的对象都存放这里 (2)老生代Old:存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。 (3)永久代Perm:是非堆内存的组成部分。主要存放加载的Class类级对象如class本身,method,field等等。 如果出现java.lang.OutOfMemoryError: Java heap space异常,说明Java虚拟机的堆内存不够。原因有二: (1)Java虚拟机的堆内存设置不够,可以通过参数-Xms、-Xmx来调整。 (2)代码中创建了大量大对象,并且长时间不能被垃圾收集器收集

JVM学习手册(X):查看堆内存使用情况以及排错

亡梦爱人 提交于 2019-11-29 23:57:07
平时出现内存溢出以及死锁,一般处理方式都是查看日志,找到抛出异常的代码行,然后本地分析代码,但是这样对于线上排查十分糟糕,这段时间在研究JVM发现了几个比较好的工具和指令. 1.针对频繁GC和内存溢出: (1).首先找到有哪些线程在执行,使用指令jps. (2).查看堆内存使用情况,使用指令jstat -gc 进程ID 刷新毫秒 刷新次数(PS: jstat -gc 1111 250 5,即对于线程1111在堆中使用情况,250毫秒刷新一次,总共刷新5次) (3).可以将堆内存使用情况生成堆转储文件,使用指令jmap -dump:format=b,file=文件名 进程ID (4).使用jhat或者Memory Analyzer分析堆转储文件,这里使用Memory Analyzer来分析. (5).首先需要安装Memory Analyzer,地址为http://archive.eclipse.org/mat/1.2/update-site/ 或者 下载插件版都可以 (6).将堆转储文件加载进Eclipse. (7).过段时间再次生成一个堆转储文件. (8).将两个文件都用Memory Analyzer加载进去, (9).选择柱状图标志(Create a histogram...),选择最后一个标志(compare to another Heap Dump),最后选择多个文件夹标志

jmap 命令

二次信任 提交于 2019-11-29 21:54:16
NAME jmap - Prints shared object memory maps or heap memory details for a process, core file, or remote debug server. SYNOPSIS jmap [ options ] pid jmap [ options ] executable core jmap [ options ] [ pid ] server-id@ ] remote-hostname-or-IP 参数说明: options: executable Java executable from which the core dump was produced.(可能是产生core dump的java可执行程序) core 将被打印信息的core dump文件 remote-hostname-or-IP 远程debug服务的主机名或ip server-id 唯一id,假如一台主机上多个远程debug服务,用此选项参数标识服务器 基本参数: <no option> 如果使用不带选项参数的jmap打印共享对象映射,将会打印目标虚拟机中加载的每个共享对象的起始地址、映射大小以及共享对象文件的路径全称 -dump:[live,]format=b,file=<filename> 使用hprof二进制形式

Windows下jmap命令报错问题

◇◆丶佛笑我妖孽 提交于 2019-11-29 18:48:12
最近换了笔记本,新的工作环境下jmap命令居然在报错,而jps、jstat、jinfo、jstack都能正常使用,所以初步排除进程号的问题。 Attaching to core 17536 from executable heap, please wait... Error attaching to core file: Windbg Error: OpenDumpFile failed! sun.jvm.hotspot.debugger.DebuggerException: Windbg Error: OpenDumpFile failed! at sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.attach0(Native Method) at sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.attach(WindbgDebuggerLocal.java:160) at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:673) at sun.jvm.hotspot.HotSpotAgent.setupDebuggerWin32(HotSpotAgent.java:569) at sun.jvm