JVM研究
- - 开源软件 - ITeye博客每天接客户的电话都是战战兢兢的，生怕再出什么幺蛾子了. 我想Java做的久一点的都有这样的经历，那这些问题的最终根结是在哪呢. JVM全称是Java Virtual Machine，Java虚拟机，也就是在计算机上再虚拟一个计算机，这和我们使用 VMWare不一样，那个虚拟的东西你是可以看到的，这个JVM你是看不到的，它存在内存中.
jvm调优
标签：
jvm
| 发表时间：2016-07-18 10:10 | 作者：hadasione
出处：http://www.iteye.com
top -Hp pid
printf "%x\n" 21742 找到耗时最长的进程
jstack pid | grep 54ee 定位某个类的方法
jstack 10535|grep -A 10 2a1d (最后十行)
jmap 查询pid 内存线程
附：TOP命令中需要关注的值：
（1）load average：此值反映了任务队列的平均长度；如果此值超过了CPU数量，则表示当前CPU数量不足以处理任务，负载过高
（2）%us：用户CPU时间百分比；如果此值过高，可能是代码中存在死循环、或是频繁GC等
（3）%sy：系统CPU时间百分比；如果此值过高，可能是系统线程竞争激烈，上下文切换过多，应当减少线程数
（4）%wa：等待输入、输出CPU时间百分比；如果此值过高，说明系统IO速度过慢，CPU大部分时间都在等待IO完成
（5）%hi：硬件中断CPU百分比；当硬件中断发生时，CPU会优先去处理硬件中断；比如，网卡接收数据会产生硬件中断
（6）swap used：被使用的swap；此值过高代表系统因为内存不足在进行频繁的换入、换出操作，这样会影响效率，应增大内存量
（7）%CPU：进程使用CPU的百分比；此值高表示CPU在进行无阻塞运算等
"consumer_pt_parser_realtime_001_jmq318_1464086436552" daemon prio=10 tid=0x00007fa4a0009000 nid=0x2a1d runnable [0x00007fa568fac000]
java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOfRange(Arrays.java:2694)
at java.lang.String.<init>(String.java:203)
at java.lang.String.substring(String.java:1913)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.countBiaoShi(DefaultParserFactory.java:276)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.getReContent(DefaultParserFactory.java:194)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.parseAriticle(DefaultParserFactory.java:57)
at com.jdjr.crawler.clean.parser.control.ParserMessageListener.consume(ParserMessageListener.java:115)
at com.jdjr
.crawler.clean.parser.control.ParserMessageListener.onMessage(ParserMessageListener.java:71)
at com.jd.jmq.client.consumer.TopicConsumer$1.call(TopicConsumer.java:767)
注:
1，根据top命令，发现PID为2633的Java进程占用CPU高达300%，出现故障。
2，找到该进程后，如何定位具体线程或代码呢，首先显示线程列表,并按照CPU占用高的线程排序：
[root@localhost logs]# ps -mp 2633 -o THREAD,tid,time | sort -rn
显示结果如下：
USER %CPU PRI SCNT WCHAN USER SYSTEM TID TIME
root 10.5 19 - - - - 3626 00:12:48
root 10.1 19 - - - - 3593 00:12:16
找到了耗时最高的线程3626，占用CPU时间有12分钟了！
将需要的线程ID转换为16进制格式：
[root@localhost logs]# printf "%x\n" 3626
e18
最后打印线程的堆栈信息：
[root@localhost logs]# jstack 2633 |grep e18 -A 30
查看死锁
jstack -l 7412
-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
printf "%x\n" 21742 找到耗时最长的进程
jstack pid | grep 54ee 定位某个类的方法
jstack 10535|grep -A 10 2a1d (最后十行)
jmap 查询pid 内存线程
附：TOP命令中需要关注的值：
（1）load average：此值反映了任务队列的平均长度；如果此值超过了CPU数量，则表示当前CPU数量不足以处理任务，负载过高
（2）%us：用户CPU时间百分比；如果此值过高，可能是代码中存在死循环、或是频繁GC等
（3）%sy：系统CPU时间百分比；如果此值过高，可能是系统线程竞争激烈，上下文切换过多，应当减少线程数
（4）%wa：等待输入、输出CPU时间百分比；如果此值过高，说明系统IO速度过慢，CPU大部分时间都在等待IO完成
（5）%hi：硬件中断CPU百分比；当硬件中断发生时，CPU会优先去处理硬件中断；比如，网卡接收数据会产生硬件中断
（6）swap used：被使用的swap；此值过高代表系统因为内存不足在进行频繁的换入、换出操作，这样会影响效率，应增大内存量
（7）%CPU：进程使用CPU的百分比；此值高表示CPU在进行无阻塞运算等
"consumer_pt_parser_realtime_001_jmq318_1464086436552" daemon prio=10 tid=0x00007fa4a0009000 nid=0x2a1d runnable [0x00007fa568fac000]
java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOfRange(Arrays.java:2694)
at java.lang.String.<init>(String.java:203)
at java.lang.String.substring(String.java:1913)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.countBiaoShi(DefaultParserFactory.java:276)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.getReContent(DefaultParserFactory.java:194)
at com.jdjr.crawler.clean.parser.defaultparser.DefaultParserFactory.parseAriticle(DefaultParserFactory.java:57)
at com.jdjr.crawler.clean.parser.control.ParserMessageListener.consume(ParserMessageListener.java:115)
at com.jdjr
.crawler.clean.parser.control.ParserMessageListener.onMessage(ParserMessageListener.java:71)
at com.jd.jmq.client.consumer.TopicConsumer$1.call(TopicConsumer.java:767)
注:
1，根据top命令，发现PID为2633的Java进程占用CPU高达300%，出现故障。
2，找到该进程后，如何定位具体线程或代码呢，首先显示线程列表,并按照CPU占用高的线程排序：
[root@localhost logs]# ps -mp 2633 -o THREAD,tid,time | sort -rn
显示结果如下：
USER %CPU PRI SCNT WCHAN USER SYSTEM TID TIME
root 10.5 19 - - - - 3626 00:12:48
root 10.1 19 - - - - 3593 00:12:16
找到了耗时最高的线程3626，占用CPU时间有12分钟了！
将需要的线程ID转换为16进制格式：
[root@localhost logs]# printf "%x\n" 3626
e18
最后打印线程的堆栈信息：
[root@localhost logs]# jstack 2633 |grep e18 -A 30
查看死锁
jstack -l 7412
-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
-
本文附件下载:
- 性能调优.zip (147.1 KB)
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [jvm] 推荐：
jvm调优
- - 互联网 - ITeye博客printf "%x\n" 21742 找到耗时最长的进程. jstack pid | grep 54ee 定位某个类的方法. jstack 10535|grep -A 10 2a1d (最后十行). jmap 查询pid 内存线程. 附：TOP命令中需要关注的值：. （1）load average：此值反映了任务队列的平均长度；如果此值超过了CPU数量，则表示当前CPU数量不足以处理任务，负载过高.
学习JVM的References
- LightingMan - 淘宝JAVA中间件团队博客本blog中列举了我学习JVM的references，会不断的更新，为了避免版权问题，就不在blog上提供references的下载了，感兴趣的同学可自行下载或购买，:). |— [ Hotspot GC论文 ]. |— [ 其他JVM GC ]. |— Linux内核源代码情景分析. |— Linux 内核中断内幕.
深入理解JVM
- 小伟 - ITeye论坛最新讨论1 Java技术与Java虚拟机. 说起Java，人们首先想到的是Java编程语言，然而事实上，Java是一种技术，它由四方面组成: Java编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API). 图1 Java四个方面的关系. 运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件).
jvm垃圾回收
- Cano - 淘宝共享数据平台 tbdata.org在jvm中堆空间划分为三个代：年轻代（Young Generation）、年老代（Old Generation）和永久代（Permanent Generation）. 年轻代和年老代是存储动态产生的对象. 永久带主要是存储的是java的类信息，包括解析得到的方法、属性、字段等等. 我们这里讨论的垃圾回收主要是针对年轻代和年老代.
JVM内存分配
- - 移动开发 - ITeye博客计算机内存，它算是CPU与计算机打交道最频繁的区域，所有数据都是先经过硬盘至内存，然后由CPU再从内存中获取数据进行处理，又将数据保存到内存，通过分页或分片技术将内存中的数据再flush至硬盘. 那JVM的内存结构到底是如何呢. JVM做为一个运行在操作系统上，但又独立于os运行的平台，它的内存至少应该包括象寄存器、堆栈等区域.
Azul开源Zing Jvm
- - InfoQ cn4月末，继Zing 5.2 之后，. Azul Systems宣布他们将无停顿（pauseless ）的 Zing JVM提供给开源软件开发者和项目，以供开发和测试. Azul Systems 工程部副总裁和合作创始人Shyam Pillalamarri向InfoQ说明道：. 我们的部署很大一部分基于开源组件，所以我们认为：“假设我们不能将一些有价值的东西免费提供给开源项目贡献者，他们将一直受限于从Java虚拟机（JVM）视角所看到的内容”，他们将不会考虑额外的用例，或者选择其他能解决了所有内存或扩展性问题、类似Zing的系统.
JVM参数设置
- - 企业架构 - ITeye博客-Xms768m -Xmx1280m jvm堆的最小值和最大值设置，一般设成相同值，避免频繁分配堆空间. -XX:NewSize=128m -XX:MaxNewSize=128m 年轻代最小值和最大值设置（年轻代设定了，年老代也就定了），也可以用参数-XX:NewRatio=4，年老代和年轻代的大小比，这里128m有点小了，官方建议的是heap的3/8，差不多280m.
JVM的DirectMemory设置
- - 编程语言 - ITeye博客原文： http://dongliu.net/post/504141. 几台服务器的JVM占用内存总是持续增长，大大超过-Xmx设定的值，服务器物理内存几乎被耗尽. 使用jmap查看JVM的内存使用，发现jvm的堆大小完全在-Xmx参数设定的范围之内，那问题只能处在别的地方了. JVM除了堆内存之外，就只有栈内存和DirectMemory了.
JVM调优总结
- - Java - 编程语言 - ITeye博客JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制. 32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制. 我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m.