性能问题定位方法
2014-08-25 09:33
239 查看
1、使用命令jps //查看Bootstrap的进程号,或者ps -ef | grep java | grep $USER也可以。
命令格式:jps //进程Bootstrap的pid
或者ps –ef|grep java|grep $USER //portal应用的pid
2、使用命令jstack //打印线程堆栈
命令格式:jstack pid > jstack.txt
Checkpoint:
①是否存在死锁
e.g. 下面四没有死锁的情况。
②是否存在较多数量的blocked状态的同一线程。
3、使用命令jmap –heap //打印内存使用情况
命令格式:jmap -heap pid > heap.txt
Checkpoint:
①检查内存中的新生代Young Generation、老生代Old Generation、持久代Perm Generation的使用率。一般要注意老生代的内存使用率,如果出现了90%以上,就有可能出现了内存泄露。这时候可以结合gc日志检查一下full gc是否已经出现了问题。
【案例1】
在进行并发100个用户的wap门户浏览内容详情性能测试时,内存配置为2G,大约运行到12小时左右,TPS值开始出现下降的趋势,此时cpu使用率一直处于80%左右。由于打印的日志很多,运行到12小时的日志已经被覆盖掉了,因此也无法从日志入手定位。
1、先分析内存使用率
如上图,此时老生代已经几乎占满了。
2、再去检查gc日志,tomcat/bin/gc.txt如下图,full gc出现的频率也很高,而且其中一次full gc的时间长达315s,这种现象是不正常的。这里需要了解一下内存的使用顺序:先使用新生代,在新生代中中难以进行垃圾回收的线程会转移到老生代,再用full gc处理老生代中的线程。现在即使是做了full gc,但是老生代的空间仍然无法被清除,可能存在内存泄露的问题。
3、分析哪些对象占用的内存较多
如上图,定位出红笔标注的两个进程占用的内存较多,锁定可疑目标,打完收工。
4、使用命令jmap –heap:format=b //打印内存镜像,也叫内存堆栈
命令格式:jmap -heap:format=b pid
该命令使用后会在本目录下生成heap.bin,注意执行前先检查heap.bin是否已存在,避免覆盖。
备注:由于截取内存镜像信息的大小和catalina.sh配置的内存大小相近,因此需要预留足够的空间,内存为2G时,大约会耗费10min。
Checkpoint:
①还不知道怎么检查
5、使用命令jmap –histo//打印不同类型的对象各有多少个
命令格式:jmap -histo pid > histo.txt 打印不同类型的对象各有多少个
Checkpoint:
①检查哪些进程占用的内存较多
6、在tomcat/bin下面的catalina.sh文件中加入-Xloggc:gc.log可以打印gc日志
ps -fu $USER | grep sar | grep -v grep | awk '{print $2}' | xargs kill -9 >> /dev/null 2>&1
JAVA_OPTS="$JAVA_OPTS -server -Xms2048m -Xmx2048m -XX:PermSize=512M -XX:MaxNewSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true -Xloggc:gc.log"
#JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=14444"
JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
# jconsole args
#JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=29819 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
# get heap dumps
#JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnCtrlBreak"
#JVM debuging params
#JAVA_OPTS="$JAVA_OPTS -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails"
#JAVA_OPTS="$JAVA_OPTS -XX:+ShowMessageBoxOnError -verbose:gc -verbose:jni -Xprof -Xloggc:gc.log -XX:+PrintGCDetails"
命令格式:jps //进程Bootstrap的pid
或者ps –ef|grep java|grep $USER //portal应用的pid
2、使用命令jstack //打印线程堆栈
命令格式:jstack pid > jstack.txt
Checkpoint:
①是否存在死锁
e.g. 下面四没有死锁的情况。
②是否存在较多数量的blocked状态的同一线程。
3、使用命令jmap –heap //打印内存使用情况
命令格式:jmap -heap pid > heap.txt
Checkpoint:
①检查内存中的新生代Young Generation、老生代Old Generation、持久代Perm Generation的使用率。一般要注意老生代的内存使用率,如果出现了90%以上,就有可能出现了内存泄露。这时候可以结合gc日志检查一下full gc是否已经出现了问题。
【案例1】
在进行并发100个用户的wap门户浏览内容详情性能测试时,内存配置为2G,大约运行到12小时左右,TPS值开始出现下降的趋势,此时cpu使用率一直处于80%左右。由于打印的日志很多,运行到12小时的日志已经被覆盖掉了,因此也无法从日志入手定位。
1、先分析内存使用率
如上图,此时老生代已经几乎占满了。
2、再去检查gc日志,tomcat/bin/gc.txt如下图,full gc出现的频率也很高,而且其中一次full gc的时间长达315s,这种现象是不正常的。这里需要了解一下内存的使用顺序:先使用新生代,在新生代中中难以进行垃圾回收的线程会转移到老生代,再用full gc处理老生代中的线程。现在即使是做了full gc,但是老生代的空间仍然无法被清除,可能存在内存泄露的问题。
3、分析哪些对象占用的内存较多
如上图,定位出红笔标注的两个进程占用的内存较多,锁定可疑目标,打完收工。
4、使用命令jmap –heap:format=b //打印内存镜像,也叫内存堆栈
命令格式:jmap -heap:format=b pid
该命令使用后会在本目录下生成heap.bin,注意执行前先检查heap.bin是否已存在,避免覆盖。
备注:由于截取内存镜像信息的大小和catalina.sh配置的内存大小相近,因此需要预留足够的空间,内存为2G时,大约会耗费10min。
Checkpoint:
①还不知道怎么检查
5、使用命令jmap –histo//打印不同类型的对象各有多少个
命令格式:jmap -histo pid > histo.txt 打印不同类型的对象各有多少个
Checkpoint:
①检查哪些进程占用的内存较多
6、在tomcat/bin下面的catalina.sh文件中加入-Xloggc:gc.log可以打印gc日志
ps -fu $USER | grep sar | grep -v grep | awk '{print $2}' | xargs kill -9 >> /dev/null 2>&1
JAVA_OPTS="$JAVA_OPTS -server -Xms2048m -Xmx2048m -XX:PermSize=512M -XX:MaxNewSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true -Xloggc:gc.log"
#JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=14444"
JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
# jconsole args
#JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=29819 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
# get heap dumps
#JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnCtrlBreak"
#JVM debuging params
#JAVA_OPTS="$JAVA_OPTS -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails"
#JAVA_OPTS="$JAVA_OPTS -XX:+ShowMessageBoxOnError -verbose:gc -verbose:jni -Xprof -Xloggc:gc.log -XX:+PrintGCDetails"
相关文章推荐
- Java的WEB应用性能问题定位方法总结:常见的性能指标分析 .
- 【转载】WEB系统性能问题的分析定位方法
- oracle数据库性能问题定位方法
- Java的WEB应用性能问题定位方法总结(一):常见的性能指标分析
- WEB系统性能问题的分析定位方法
- SQL性能优化之定位网络性能问题的方法(DEMO)
- Java的WEB应用性能问题定位方法总结(二):常见性能问题处理工具
- 从某次测试过程中,得到的MySQL性能优化的建议,和定位问题的方法 推荐
- java性能问题的定位常用方法
- Java的WEB应用性能问题定位方法总结
- Web项目性能问题常见定位方法梳理
- SQL性能优化之定位网络性能问题的方法(DEMO)
- [原创]SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法
- vxworks下的问题定位及调试方法
- NO.28 要你命3000-宕机问题面面观:1.最简单定位分析方法
- SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法
- SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法
- 通过valgrind、gdb定位程序问题的几个方法小结
- SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法
- SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法