赞
踩
想学习架构师构建流程请跳转:Java架构师系统架构设计
安装途径:
https://www.ej-technologies.com/products/jprofiler/overview.html
方式一:
直接在IDEA上下载File–Settings–plugins–Browse repositories ,找到jprofiler然后点击安装。
看到如下图片则说明安装完成
官方下载地址:
https://www.ej-technologies.com/download/jprofiler/version_92
下载完成后点击运行,然后一直next就可以了
Settings–Tools–JProflier–JProflier executable选择JProfile安装可执行文件。(如果系统只装了一个版本,启动IDEA时会默认选择)保存
如果没有执行这一步,首次点击下图JProfiler图标时,也会提醒选择JProfile可执行文件。
启动完成会自动弹出JProfiler窗口,在里面就可以监控自己的代码性能了。
JProfiler的内存视图部分可以提供动态的内存使用状况更新视图和显示关于内存分配状况信息的视图。所有的视图都有几个聚集层并且能够显示现有存在的对象和作为垃圾回收的对象。
在JProfiler的堆遍历器(Heap Walker)中,你可以对堆的状况进行快照并且可以通过选择步骤下寻找感兴趣的对象。堆遍历器有五个视图.
Ps:在工具栏点击"Go To Start"可以使堆内存重新计数,也就是回到初始状态。
JProfiler 提供不同的方法来记录访问树以优化性能和细节。线程或者线程组以及线程状况可以被所有的视图选择。所有的视图都可以聚集到方法、类、包或J2EE组件等不同层上。
JProfiler通过对线程历史的监控判断其运行状态,并监控是否有线程阻塞产生,还能将一个线程所管理的方法以树状形式呈现。对线程剖析。
系统的内存消耗过多往往有以下几种原因:
内存溢出:第1、2中情况。程序向系统申请的内存空间超出了系统能给的。比如内存只能分配一个int类型,我却要塞给他一个long类型,系统就出现oom。又比如一车最多能坐5个人,你却非要塞下10个,车就挤爆了。
内存泄漏:第3种情况。 所谓内存泄漏是指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并不是指内存在物理上的消失,而是应用程序分配某段内存后,因为设计错误,失去了对该段内存的控制,因而造成了内存的浪费。
针对1、2种情况,可以通过 Live Memory 视图来分析
首先通过观察Size列可以找到系统中占用内存最大的对象,然后再分析Instance count列.
如果Size过大并且它对应的Instance Count比较小则说明该对象是大对象,如果Size过大同时它对应的Instance Count 也很大,着说明这个对象再被频繁创建,这时可以对应Name列指示的Java类路径找到项目里的Java类进行分析,如果发现有不合理的地方则改之。
在该视图下方的Recorded Objects子视图可以记录对象,从而查看类在一段时间里的总共实例数、GC数和活动数,但是在使用这些功能时会导致系统的性能严重降低,例如:没开此功能时,1000并发响应时间为1s,开此功能后500并发时响应时间才能达到1s,因此只有当存在内存泄漏时才开启该功能。
针对第3中情况,
如果怀疑内存泄漏的第一步就是查看 “Memory"和"Recorded objects” 遥感勘测视图。当应用程序出现内存泄漏时,视图中会显示出带有震荡的线性积极趋势。大多数的内存泄漏可以被追溯到对象集群。这将产生一些大的retained size的对象。最大的对象视图列出了带有最大retained size的对象。你可以利用该树形向下钻取从而发现错误引用。
首先查看Memory
在Memory中可以指导JVM的总共内存分配大小、内存占用大小和内存空闲大小以及GC后内存占用的变化。蓝色区域表示占用的内存,下坡表示此时刻可能经历了一次GC。
当发现GC后回收的力度越来越小,则说明很有可能存在内存泄漏。
这时需要开启Live Memory视图下的Recorded Objects子视图。
右键不断切换GC、Live和GC Live这三种模式,并结合项目的Java类,找出本该被回收但却没有得到回收的对象的对应Java类,从而找出问题根源。
内存泄露的真因是:持有对象的强引用,且没有及时释放,进而造成内存单元一直被占用,浪费空间,甚至可能造成内存溢出!
通常一个方法的执行时间越长则占用CPU的资源则越多,在JProfiler里就是通过方法的执行时间来描述对CPU的使用情况。
通过CPU views视图的Method Statistics子视图可以看到一段时间里涉及类方法的执行时间,这些时间是从开始记录到查看该视图这段时间所发生的执行时间的合计,如此可以准确反映出真实场景下的方法执行情况。
一般是用LoadRunner压一段时间后再查看该视图,通过占用时间的不同,找出系统里最耗时的类方法进行调优解决问题。
发现执行一次请求,响应时间不能满足需求时,通过这种CPU时间占有的方式分析可优化点是一种简单而有效的方式。
线程的运行情况可以直接反应出系统的瓶颈所在,对线程一般有以下三个关注点:
Web容器的线程最大数管理,Web容器允许开启的线程数与系统要求的最大并发数有一定的对应关系,通常是Web容器运行的线程数略大于最大并发数,以Tomcat为例,在{$tomcat}/conf/server.xml文件的Connector选项里配置maxThreads,它的默认值时150;
线程阻塞;
线程死锁。
通过Threads视图可以观察到项目的线程情况
如图在Threads 的Thread History视图里可以查看Web容器共打开的线程数以及这些线程的使用情况。
官网地址,选择:
选择对于对应版本
下载后上传到被测服务器的/opt 下,解压,重命名为:jprofiler11
export INSTALL4J_JAVA_HOME=/server/jdk1.8.0_151/jre #jdk安装目录下
export LD_LIBRARY_PATH=/opt/jprofiler11/bin/linux-x86 #jprofile的安装目录下
然后source一下,使立即生效:
# source /etc/profile
# sudo -u tomcat /opt/jprofiler11/bin/jpenable
如果出现如下报错:
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 11.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
需要修改jpenable文件,执行:vim jpenable 编辑文件,修改后如下:
# Uncomment the following line to override the JVM search sequence
INSTALL4J_JAVA_HOME_OVERRIDE=/server/jdk1.8.0_151/
# Uncomment the following line to add additional VM parameters
# INSTALL4J_ADD_VM_PARAMS=
再次执行,成功。先选择mode:1,然后输入连接端口号:8849:
# sudo -u tomcat /opt/jprofiler11/bin/jpenable
Connecting to /server/application/xw-web/ef9c48.../jprofiler11/bin/agent.jar [20480] ...
Please select the profiling mode:
GUI mode (attach with JProfiler GUI) [1, Enter]
Offline mode (use config file to set profiling settings) [2]
1
Please enter a profiling port
[35634]
8084
You can now use the JProfiler GUI to connect on port 8084
//先查询出项目启动进程并杀死
# ps -ef | grep /server/application/xw-web |grep -v grep|grep tomcat|awk '{print $2}'
19205
# kill -s 9 19205
//进入项目包存放目录,执行启动命令
# su - tomcat -c
4、既然指定端口为8084,那么本地的端口就需要填写这个。如下:
5、如何关闭JProfiler 监控?
只有一种方式:重启被监控的进程,JProfiler 自动关闭。
6、好了,已经成功了。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。