玩过性能优化的朋友都清楚，性能优化的关键并不在于怎么进行优化，而在于怎么找到当前系统的性能瓶颈。admin管理员组文章数量:1531792
性能优化分为好几个层次，比如系统层次、算法层次、代码层次...JVM 的性能优化被认为是底层优化，门槛较高，精通这种技能的人比较少。笔者呆过几家技术力量不算弱的公司，每个公司内部真正能够进行 JVM 性能调优的人寥寥无几、甚至没有。如是乎，能够有效通过 JVM 调优提升系统性能的人往往被人们冠以"大牛"、"大师"之类的称呼。
其实 JVM 本身给我们提供了很多强大而有效的监控进程、分析定位瓶颈的工具，比如 JConsole、JMap、JStack、JStat 等等。使用这些命令，再结合 Linux 自身提供的一些强大的进程、线程命令，能够快速定位系统瓶颈。本文以一次使用这些工具准确定位到某系统瓶颈的实战经验为例，希望能为大家掌握 JVM 调优这项技能起到一些借鉴作用。
本文背景：
- Linux：RedHat 6.1
- Weblogic：11g
- JRokit：R28.2.4
- JDK：1.6.0_45
1. LoadRunner 压测结果
该系统其实早已跑在生产上好多年，虽然没有做过压力测试，但稳定性还是可以的。公司进行架构调整，有一些新系统将对接该系统。公司领导担心对接后该系统的并发性能问题，于是开始对该系统进行并发压力测试。50 个用户并发压十几个小时，TRT 在 20 左右，TPS 在 2.5 左右。领导对这个结果不满意，要求进行优化。但这是个老系统，开发在之前明显已经对其代码做过很多优化，如今面对这种状况也束手无策。
2. Oracle 的 awr 报告分析
有句老话，优化来优化去，系统的性能瓶颈还是会在数据库上面。在这里我们首先想到的也是数据库的问题。并发压测的时候 Spotlight 查看数据库服务器各项性能指标，很清闲。
分析 awr 报告，结果显示也是很清闲。
并发压测的时候去相关数据表执行一些 sql 的速度很快也证明着问题不在 Oracle 这边。
3. Weblogic 服务器的性能指标
使用 Spotlight 查看并发压测时的 Weblogic 所在的 Linux 服务器，除了 CPU 之外其它各项指标显示，Linux 也很清闲。虽然 CPU 利用率始终在 200% 左右徘徊，但这对于 16 核的系统来讲也算是正常的吧？
4. JStack 报告分析
事情到了这里，大家已经想到了线程死锁、等待的问题了。没错，JStack 隆重登场。JStack 能够看到当前 Java 进程中每个线程的当前状态、调用栈、锁住或等待去锁定的资源，而且很强悍的是它还能直接报告是否有线程死锁，可谓解决线程问题的不二之选。
$ /opt/jdk1.6.0_45/bin/jstack -l 10495 > ~/10495jstack.txt
JRokit 堆栈的拉取，可以直接用 JDK 的 JStack，10495 是 Weblogic 服务的进程 ID。注意一定要用该进程的启动用户去拉，否则会报 Unable to open socket file: target process not responding or HotSpot VM not loaded 错误。
JStack 拉取的文件信息基本分为以下几个部分：
- 该拉取快照的服务器时间
- JVM 版本
- 以线程 ID(即 tid)升序依次列出当前进程中每个线程的调用栈
- 死锁(如果有的话)
- 阻塞锁链
- 打开的锁链
- 监视器解锁情况跟踪
4.1. TLA 空间的调整
多次拉取 JStack，发现很多线程处于这个状态：at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
at java/util/HashMap.resize(HashMap.java:564)[inlined]
at java/util/LinkedHashMap.addEntry(LinkedHashMap.java:414)[optimized]
at java/util/HashMap.
版权声明：本文标题：JVM 性能调优实战之：一次系统性能瓶颈的寻找过程 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/dianzi/1724998424a1001732.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论