jStat

平常的工作中，在衡量服务器的性能时，经常会涉及到几个指标，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

命令可用选项 ➜ ~ jstat -options -class -compiler -gc -gccapacity -gccause -gcmetacapacity -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcutil -printcompilation 查看 ➜ ~ jstat -gcutil 65007 500 7 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 81.25 59.60 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 64.72 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 64.94 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 66.43 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 66.65 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 68.67 89.21 93.54 87.75 97 0.369 4 0.257 0.626 0.00 81.25 69.26 89.21 93

欢迎大家前往 腾讯云+社区 ，获取更多腾讯海量技术实践干货哦~ 本文由 净地 发表于 云+社区专栏 记一次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文件夹下面

We recently upgraded from JDK6u20 (Linux, 32bit and 64bit) to JDK6u23. Since then, we cannot longer use the tools jstack and jstat to get monitoring information from the running process. If we switch back to JDK6u20, everything works fine. We are running Tomcat 6. According to this forum post, others have the same problem: http://forums.oracle.com/forums/thread.jspa?threadID=2151967&tstart=0 Running simple plain Java processes and using the tools works. Jstack says: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target

平时出现内存溢出以及死锁,一般处理方式都是查看日志,找到抛出异常的代码行,然后本地分析代码,但是这样对于线上排查十分糟糕,这段时间在研究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),最后选择多个文件夹标志

NAME jstat - Monitors Java Virtual Machine (JVM) statistics. This command is experimental and unsupported. SYNOPSIS jstat [Options] vmid [interval] [count] Options，选项 vmid，VM的进程号，即当前运行的java进程号 interval，间隔时间，单位为秒或者毫秒 count，打印次数，如果缺省则打印无数次 示例： jstat –class <pid> //显示加载class的数量，及所占空间等信息 Loaded: 装载类的数量 Bytes: 装载类所占用的字节数 Unloaded: 卸载类的数量 Bytes：卸载类的字节数 Time: 装载和卸载所花费的时间 jstat -gc <pid> //显示gc的信息，查看gc的次数，及时间 S0C: 年轻代中第一个survivor（幸存区）的容量 (字节) S1C: 年轻代中第二个survivor（幸存区）的容量 (字节) S0U: 年轻代中第一个survivor（幸存区）目前已使用空间 (字节) S1U: 年轻代中第二个survivor（幸存区）目前已使用空间 (字节) EC: 年轻代中Eden（伊甸园）的容量 (字节) EU: 年轻代中Eden（伊甸园）目前已使用空间

概述 Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。 jstat 用法 option： 参数选项 -t： 可以在打印的列加上Timestamp列，用于显示系统运行的时间 -h： 可以在周期性数据数据的时候，可以在指定输出多少行以后输出一次表头 vmid： Virtual Machine ID（ 进程的 pid） interval： 执行每次的间隔时间，单位为毫秒 count： 用于指定输出多少次记录，缺省则会一直打印 option 可以从下面参数中选择 -class 显示ClassLoad的相关信息； -compiler 显示JIT编译的相关信息； -gc 显示和gc相关的堆信息； -gccapacity 　　 显示各个代的容量以及使用情况； -gcmetacapacity 显示metaspace的大小 -gcnew 显示新生代信息； -gcnewcapacity 显示新生代大小和使用情况； -gcold 显示老年代和永久代的信息； -gcoldcapacity 显示老年代的大小； -gcutil　　 显示垃圾收集信息；

1. jps 在JDK的bin目录下，jps是参照Unix系统的取名规则命名的，功能和ps的功能类似，可以列举正在运行的虚拟机进程并显示虚拟机执行的主类以及这些进程的唯一ID（对应本机来说和PID相同）. 示例： jps -m 输出JVM启动时传给主类的方法 jps -l 输出主类的全名，如果是Jar则输出jar的路径 jps -v 输出JVM的启动参数 2. jstat 在JDK的bin目录下，jstat主要用于监控虚拟机的各种运行状态信息，如类的装载、内存、垃圾回收、JIT编译器等，在没有GUI的服务器上，这款工具是首选的一款监控工具。 用法： jstat [option vmid [interval [s|ms] [vount] ] ] jstat 监控内容 线程号 刷新时间间隔 次数 示例： jstat –gc PID 1 20 监视Java堆，包含eden、2个survivor区、old区和永久带区域的容量、已用空间、GC时间合计等信息 jstat –gcutil PID 1 20 监视内容与-gc相同，但输出主要关注已使用空间占总空间的百分比 jstat –class PID 1 20 监视类的装载、卸载数量以及类的装载总空间和耗费时间等 3.jinfo 在JDK的bin目录下，jinfo的作用是实时查看虚拟机的各项参数信息 用法：jinfo [option] pid

文章目录 1. jstat查看堆内存使用情况 1.1 查看class加载情况 1.2 查看编译情况 1.3 垃圾回收统一 2. jmap的使用及内存溢出分析 2.1 查看内存使用情况 2.2 查看内存对象数量及大小 1. jstat查看堆内存使用情况 jstat查看堆内存各部分使用量，以及加载类的数量。 命令格式 jstat [-命令选型] [vmid] [时间间隔/毫秒] [查询次数] 1.1 查看class加载情况 [root@localhost bin]# jps 7811 Jps 7725 Bootstrap [root@localhost bin]# jstat -class 7725 Loaded Bytes Unloaded Bytes Time 3476 7544.4 0 0.0 9.61 Loader：加载class数量 Bytes：所占用空间大小 Unloaded：未加载class数量 Bytes：未加载占用空间大小 Time：时间 1.2 查看编译情况 [root@localhost bin]# jps 7835 Jps 7725 Bootstrap [root@localhost bin]# jstat -compiler 7725 Compiled Failed Invalid Time FailedType FailedMethod 2141 0 0 6

1、本文背景 本文会给大家讲解一个比较特殊的JVM优化案例，这个优化案例本身是因为新手工程师对JVM优化可能了解了一个半吊子，然后不知道从哪里找来了一个非常特殊的JVM参数错误的设置了一下，就导致线上系统频繁的出现Full GC的问题。 但是我们后续大量的优化案例其实都是各种各样奇形怪状的场景，因为正是各种奇怪场景才能让大家逐步积累出来较为丰富的JVM优化实战经验 了解的场景越多，自己未来在处理JVM性能问题的时候才能更是得心应手。 2、问题的产生 这个场景的发生大致如下过程：某天团队里一个新手工程师大概是心血来潮，觉得自己网上看到了某个JVM参数，以为学会了绝世武功秘籍，于是就在当天上线一个系统的时候，自作主张设置了一个JVM参数 这个参数是什么呢？ 不用急，跟着看下面的案例分析即可，现在只要知道他设置了一个奇怪的参数，接着事故就发生了。 因为一般中大型公司都是接入类似Zabbix、OpenFalcon或者公司自研的一些监控系统的，监控系统一般都做的很好，可以让你的系统直接接入进去，然后在上面可以看到每台机器的CPU、磁盘、内存、网络的一些负载。 而且可以看到你的JVM的内存使用波动折线图，还有你的JVM GC发生的频率折线图。包括如果你自己上报某个业务指标，也可以在监控系统里看到。 而且一般都会针对线上运行的机器和系统设置一些报警，比如说