文章目录

  • JVM调优
  • 调优描述
  • 1. 背景
  • 2. JVM调优的过程
  • 3. 性能监控复盘
  • 1. 性能监控工具
  • 2. 性能指标
  • 3. 性能分析
  • 4. 性能调优
  • 5. 垃圾回收器选择
  • 6. 运行时参数的设定
  • 7. 实战案例
  • 1.单体应用在大内存硬件上部署
  • 2. 集群同步导致内存溢出
  • 3. 堆外内存导致溢出的错误
  • 4. 外部命令导致系统缓慢
  • 5. 服务器虚拟机进程崩溃
  • 6. 不恰当的数据结构导致内存占用过大
  • 7. 由Windows虚拟机导致长时间停顿(存在问题)
  • 8. 由安全点导致的长时间停顿
  • 实战：Eclipse运行速度调优
  • 0. 使用工具
  • 1. 初始状态
  • 2. 解决方案
  • 3. 总结


JVM调优

调优描述

JVM Direct memory 打印 jvmdump032i_java

JVM Direct memory 打印 jvmdump032i_java_02

1. 背景

  • 硬件层面
  • 软件层面
  • JVM部署层面

2. JVM调优的过程

  • 部署之前
  • GC的选择
  • 运行时参数的设定
  • 部署之后
  • 性能的监控
  • 性能分析
  • 性能的调优

3. 性能监控复盘

  • 性能对比
  • 性能监控、分析、调优的经验总结
  • 对软件设计和硬件要求的总结

1. 性能监控工具

  • jps [-v] [-l] [-q] [-m]
  • -v : 打印日志信息
  • -l : 打印详细信息
  • -q : 打印简略信息
  • -m：输出传给main类的参数
  • root:node2:支持远程连接 [主机名:端口号]
  • jstat -option :产看JVM的统计信息
  • option参数和普通的参数
  • 普通参数
  • inteval
  • count
  • -t : 程序运行的时间
  • -h
  • 顺序 jstat -option [-普通参数] 进程号 inteval count
  • 比如 jstat -class [-t] 9000 1000 10

JVM Direct memory 打印 jvmdump032i_调优_03

  • option的日志内容

JVM Direct memory 打印 jvmdump032i_调优_04

  • 使用-gc或者-gcutil进行内存泄漏或者内存占比的分析
  • OU一直上升，说明内存有可能泄漏了
  • 用gc时间/运行时间占比20%说明内存压力比较大。占比90%说明随时可能溢出内存。
  • jinfo的使用
  • 一些可以动态修改的参数 java -XX:+PrintFlagsFinal -version | findstr "manageable"

JVM Direct memory 打印 jvmdump032i_调优_05

  • java -XX:+PrintFlagsInitial:查看所有JVM参数启动的初始值
  • java -XX:+PrintFlagsFinal：产看所有JVM参数的最终值
  • java -XX:+PrintCommandLineFlags :产看被用户或者JVM设置过的详细的XX参数的名称和值

JVM Direct memory 打印 jvmdump032i_死锁_06

  • jmap:
  • -heap pid :显示堆的配置信息和使用信息。可以和jstat对比使用
  • -dump 导出内存镜像文件 jmap -dump:live,format=b, filename="d:\1.txt" pid # 导出存活的对象
  • -histo：类的大小和对象实例的个数
  • 自动方式导出 -XX:+HeapDumpOnOutMemoryError 或者 -XX:HeapDumpPath=文件名

JVM Direct memory 打印 jvmdump032i_java_07

JVM Direct memory 打印 jvmdump032i_死锁_08

JVM Direct memory 打印 jvmdump032i_java_09

JVM Direct memory 打印 jvmdump032i_调优_10

和jstat的对比

JVM Direct memory 打印 jvmdump032i_java_11

  • jhat ，再7000端口进行分析

JVM Direct memory 打印 jvmdump032i_java_12

JVM Direct memory 打印 jvmdump032i_死锁_13

  • jstack -l ： 加上锁的信息

JVM Direct memory 打印 jvmdump032i_JVM_14

JVM Direct memory 打印 jvmdump032i_死锁_15

对于死锁，jstack只可以检测到由于竞争锁而引起的死锁问题。检测由于循环等待而导致的死锁信息。

也就是说：如果两个线程永久处于blok状态，才会被检测为死锁；而永久处于wait状态是不会被检测到死锁的。

  • jcmd : 可以执行stat的基本所有指令。
  • jmap的替换
  • jinfo的替换
  • jps替换
  • PrintFlagsFinal的替换

JVM Direct memory 打印 jvmdump032i_jvm_16

图形化的界面

2. 性能指标

  • GC的时间
  • 吞吐量
  • 延迟，STW的时间
  • 并发数
  • 内存占比

注意吞吐量和延迟的区别：

  • 对于web应用程序来说，吞吐量越高，延迟越低。 此处的延迟是用户体验到的延迟。
  • 对于GC来说，吞吐量越高，延迟越高。

一些占用时间的过程

  • 垃圾回收
  • 热点代码编译
  • 类加载

3. 性能分析

  • 无监控，不调优；无分析，不调优。
  • 监控和分析的一句
  • 运行日志 ： 异常堆栈的日志，以及垃圾回收日志，还有就是热点代码编译的时间，类加载时间
  • 线程快照：时间上的快照
  • 堆存储快照: 空间上的快照

4. 性能调优

5. 垃圾回收器选择

6. 运行时参数的设定

7. 实战案例

1.单体应用在大内存硬件上部署

  • 通过单独的Java虚拟机实现管理大量的Java堆内存
  • 同时使用若干个JVM，建立逻辑集群来应用硬件资源

2. 集群同步导致内存溢出

3. 堆外内存导致溢出的错误

  • 没有明显的堆存储快照
  • 大量使用NIO
  • 经验总结：管理32应用或者小内存时，应该注意下面的内存
  • 直接内存
  • 线程堆栈
  • Socket缓存区
  • JNI代码
  • 虚拟机和垃圾收集器

4. 外部命令导致系统缓慢

  • 由于进程调用导致的系统缓慢，处理器资源占用率很高。
  • 自己的毕业设计里面 – 加载的照片很慢的原因就是存在系统调用。没法通过Django框架直接进行图片的处理，还需要进程调用。
  • 问题，找不到自己电脑的Pytorch环境和tensorflow环境。
  • 把下载好的tenflow的包和pytorch的包，放在项目的model里面进行引用。
  • 然后调试环境就行了。
  • 问题2：图片的数据库存储，否则的话会查询很慢，因为没法建立索引。应该按照小时建立索引。
  • 增加、删除都没什么问题
  • 查找会很慢，也不支持修改。
  • 问题3：页面的问题很大，一些功能没有实现，加上自己对前端的不熟悉，导致前端很丑，并且修改很困难。

5. 服务器虚拟机进程崩溃

  • 出现了Connect Reset异常。
  • 把异步调用修改成消息队列。
  • 写的发送消息的那个阻塞I/O就是这样的问题。

6. 不恰当的数据结构导致内存占用过大

  • 使用Hahs<Long, Long>封装的对象，使用的存储效率只有18%。
  • 治标，让对象立马进入老年代。
  • 治本，修改代码

7. 由Windows虚拟机导致长时间停顿(存在问题)

  • 情景描述
  • 桌面应用程序，占用内存不大，所以认为不是垃圾回收的原因。最后打印了日志信息-XX+PrintGCDate-Stamps -Xloggc:gclong.log后，发现是由于gc准备收集到真正开始收集的的时间消耗了很长时间。
  • 最小化的时候，资源监视器中内存占用大幅度减小，但是JVM的内存却没有变化。
  • 原因：最小化导致工作内存被自动交换到磁盘内存当中。
  • 解决方案：加入-Dsun.awt.keepWorkingSetOnMinimize=tre，不让它最小化的时候写入内存。

8. 由安全点导致的长时间停顿

  • 现象：
  • 用户线程停顿时间特别长 2.26s,但是垃圾收集时间很短，也只有0.14s
  • 使用-XX:+PrintSafepointStatisticsCount=1看到waited_to_block有两个。也就是等待两个线程，并且spin时间超过了2s。
  • 解决：
  • 找到最这两个线程-XX:safepointTimeoutDelay=2000
  • 使用了int类型的可数循环
  • 改成long类型的循环，这样每次循环就会检查安全点，不用等到跑完才会进行垃圾回收。

实战：Eclipse运行速度调优

0. 使用工具

  • VisualVM
  • Ecplipse
  • jdk5，6，7

1. 初始状态

  • 启动时间15s
  • GC ：4.149s
  • full GC 19次，3s
  • Minor GC , 278次，1s
  • 类加载9115个:4s
  • 及时编译:2s
  • 内存分布：40M新生代，472M老年代

2. 解决方案

  • 升级硬件或者软件
  • 升级到jdk6
  • 永久代溢出，加上-XX:MaxPermSize=256M
  • JDK5中已经默认加上了
  • Eclipse不认识Oracle公司的虚拟机，认识sun公司的虚拟机，所以参数就不能传进去，就需要手动设置。
  • 概述 > JVM参数。
  • 编译时间和类加载时间优化
  • 去掉验证阶段: -Xverify:none
  • 去掉编译时间-Xint
  • 调整内存设置控制垃圾收集频率，主要是Full GC
  • 分析每次回收老年代都会扩容，(日志中括号的内容是老年代的总大小)
  • 直接设定堆的大小为最大值。
  • 调整初始新生代的大小为128m, 初始堆区大小为512m,老年代384m。
  • 禁用System.gc()。-XX:+DisableExplicitGC。
  • 选择收集器降低延迟
  • -XX:+UseConcMarkSweepGC + -XX:+UseParNewGC。第二个可以不加，因为是默认的新生代收集器。使用CMS的时候。

3. 总结

  • -Xverify:none
  • -Xmx512m
  • -Xms512m
  • -Xmn128m
  • -XX:PermSize=256m
  • -XX:MaxPermSize=256m
  • -XX:+DisableExplicitGC"
  • -XX:+UseParNew
  • -XX:+UseConcMarkSweepGC
  • ``-XX:CMSInitialtingOccupanyFrction=85` #VMS的初始并发占内存用率为15%。
  • -Xnoclassgc