JVM的优化

2019独角兽企业重金招聘Python工程师标准>>>

JVM的优化

一、根对象

1.1 详解

• Universe相关对象：Universe模块在JVM中主要负责内存堆的管理，核心是内存堆管理器的初始化工作。
  • 基本类型对应的java.lang.Class对象
  • 基本类型对应的数组类型的描述信息对象
  • Java类型相关的描述信息对象
  • 常用Java方法描述信息对象：法:java.lang.ref.Finalizer.register()/java.lang.ClassLoader.addClass()/java.lang.reflect.Method.invoke()
  • 内存分配相关的异常实例对象
• 本地方法创建的全局对象
• 方法栈中的对象：
  • java方法栈中的对象
  • 本地方法栈中的对象
• 对象同步监视器中的对象
• Java级管理接口(Management)中的对象
• 虚拟机工具接口(JVMTI)中的对象
• 系统字典(SystemDictionary)中的对象象：基础类型

1.2 描述

• JVM内部的全局数据指向java对象的指针：java.lang.Object/java.lang.String/java.lang.Thread/所有包装类型/etc
• 线程的栈上所有指向java对象的指针：参数与局部变量（局部变量区）和临时变量区（操作数栈）
• JNI persistent handle
• 如果是分代GC，当前要做的GC是较年轻的分代，那么需要把较年老的分代指向当前分代的指针也算作根集合的一部分。

二、优化目标 1. 吞吐量、响应时间、内存消耗、启动时间、可用性以及易管理性等等 * 1.1 高可用将系统分割成各个组件。eg:：当系统的某一部分出现错误的时候，不要让整个应用程序崩溃 * 1.2 易管理性：易管理性是衡量系统的运行和监控的成本以及配置应用的成本。eg:由于有限的资源，应用只能部署到尽量少的JVM上面。 * 1.2 吞吐量：在单位时间里面完成的工作(事物)数量,吞吐量需求通常忽略延迟或者响应时间。eg:这个应用需要每秒完成2500个事务 * 延迟和响应时间：延迟或响应时间是衡量应用从接收一个任务到完成这个任务消耗的时间,提升应用的响 应时间需要以更低吞吐量或提高应用的内容消耗。eg:这个应用会在60毫秒内，执行完成交易操作。 * 1.3 内存占用：内存占用是衡量应用消耗的内存，这个内存占用是指应用在运行在某一个吞吐量、延迟以及可用性和易管理性指标下的内存消耗，内存占用是通常描述为应用运行的时候Java堆的大小或者总共需要消耗内存。eg：这个应用会单独运行在一个8G的系统上面或者多出3个应用实例运行在一个24G的应用系统上面。 * 1.4 启动时间：启动时间衡量应用初始化的时间。 2. 吞吐量/低延时：单机：一次处理时间固定，但线程增加，吞吐量上升，延迟时间可能会增加（线程切换、I/O、gc、内存分配、错误页处理、线程开启），要在延迟时间（规定，可接受的范围内）来增加线程数。结论：先规定的延迟时间，增大吞吐量。

---

三、 TOMCAT优化

#I/O协议
protocol="org.apache.coyote.http11.Http11NioProtocol"

#线程数
"maxThreads"="500" :Tomcat 使用线程来处理接收的每个请求，这个值表示 Tomcat 可创建的最大的线程数，默认值是 200

"minSpareThreads"="200"：最小空闲线程数，Tomcat 启动时的初始化的线程数，表示即使没有人使用也开这么多空线程等待，默认值是 10
"maxSpareThreads"="400"：最大空闲线程数，一旦创建的线程超过这个值，Tomcat 就会关闭不再需要的 socket 线程。

#连接数
"acceptCount"：指定当所有可以使用的处理请求的线程数都被使用时，可传入连接请求的最大队列长度，超过这个数的请求将不予处理，默认为100个。
"keepAliveTimeout"：长连接最大保持时间（毫秒），表示在下次请求过来之前，Tomcat 保持该连接多久，默认是使用 "connectionTimeout" 时间，-1 为不限制超时。

#压缩
"compression"="on"：是否对响应的数据进行 GZIP 压缩，off：表示禁止压缩；on：表示允许压缩（文本将被压缩）、force：表示所有情况下都进行压缩，默认值为off，压缩数据后可以有效的减少页面的大小，一般可以减小1/3左右，节省带宽。
"compressionMinSize"="2048"：表示压缩响应的最小值，只有当响应报文大小大于这个值的时候才会对报文进行压缩，如果开启了压缩功能，默认值就是2048。
"compressableMimeType"="text/html,text/xml,text/javascript,text/css,text/plain"：压缩类型，指定对哪些类型的文件进行数据压缩。

#上传
"disableUploadTimeout"：上传时是否使用超时机制。
"connectionUploadTimeout"：上传超时时间，毕竟文件上传可能需要消耗更多的时间，这个根据你自己的业务需要自己调，以使Servlet有较长的时间来完成它的执行，需要与上一个参数一起配合使用才会生效。



"URIEncoding"：指定 Tomcat 容器的 URL 编码格式，语言编码格式这块倒不如其它 WEB 服务器软件配置方便，需要分别指定。
"connnectionTimeout"： 网络连接超时，单位：毫秒，设置为 0 表示永不超时，这样设置有隐患的。通常可设置为 30000 毫秒，可根据检测实际情况，适当修改。
"enableLookups"： 是否反查域名，以返回远程主机的主机名，取值为：true 或 false，如果设置为false，则直接返回IP地址，为了提高处理能力，应设置为 false。

---

四、 内存优化(主要是堆优化)

4.1 原则： * 1.1 存活数据是指，应用处于稳定运行状态下，在Java堆里面长期存活的对象。换一句话说，就是应用在稳定运行的状态下，多次Full GC之后，Java堆Old区的所占的空间。猜测：这东西应该是常驻内存，应该让它存活在Old区。使用 jmap -histo:live PID 来强制触发Full GC * 1.2 堆大小为:FullGC后old代大小的3、4倍 * 1.3 permanent：为FULLGC后permanet的1.2、1.5倍。 * 1.4 yang区：FullGC后old代大小的1、1.5倍. * 1.5 old区：FullGC后old代大小的2、3倍

4.2. 参数

总堆：
-Xms-->最小堆区。=-Xmx10m
-Xmx-->最大堆区

yang区：
-Xmn --》yang的初始值、最小、最大值。和下面的排斥

-XX:NewSize=10M --> yang区的初始值/最小值。同时需要-XX:MaxNewSize
-XX:MaxNewSize=10m --> yang区的最大值。

Permanent代：
-XX:PermSize=10m -->permanent的初始值、最小值
-XX:MaxPermSize=10m -->permanent的最大值

---

五、 GC相关指标 ：

5.1. 指标： * 1.1 吞吐量：衡量垃圾回收器运行在新能峰值的时候不需要关系垃圾回收器暂停的事件或者需要占用内存的能力。 * 1.2 内存占用：衡量了高效的运行，垃圾回收器需要的内存。 * 1.3 延迟：衡量垃圾回收器最小化甚至消灭垃圾回收器引起的暂停事件和应用都懂的能力。

    * 1.3.1 测量MinorGC的时间：默认GC的回收时间，**时间长，减小yang区；时间短，增大yang区(重要)**
    * 1.3.2 测量MinorGC的频率：默认GC的回收频率，**频率高，增大yang区；频率低，减小yang区**
    * 1.3.3 测量FullGC的时间：默认FullGc的回收时间，**时间长，减小old区；时间短低，增加old区**
    * 1.3.4 测量FullGC的频率：默认FullGc的回收频率，**频率高，增大old区；频率低，减小old区(重要)**
    * tips: 
        * yang/old区独立优化大小。
        * 大小越大，时间越长，频率越低。
    
* 1.4 CMS GC优化:为了减少FullGc频次，需要将短生命周期的数据存放尽量放在yang区(eden和servivor)
    * 1.4.1 **任期阀值**：对象在yang区存活几次gc，然后转移到old区。

5.2. 原则：

* 2.1 在yang区大量对象被回收，尽量不造成Full GC。Full GC暂停时间长，对应用的影响大（抖动）.
* 2.2 更多的内存分配给垃圾回收器，也就是说更大的Java堆空间，垃圾回收器和应用在吞吐量和延迟上会表现得更好，这条原则被称为**GC最大内存原则**。
* 2.3 优化垃圾回收器3个指标的2个,**2/3 GC优化原则**。一般**内存固定，优化延迟（不要造成Full GC），吞吐量(yang GC尽量做完GC，Full GC不做要求)**

**5.3. gc **

GC参数：

-XX:+UseConcMarkSweepGC：old区使用CMS回收器，yang区会开启-XX:+UseParNewGC
-XX:+UseParNewGC：yang区使用并行回收器
-XX:+:ParallelGCThreads：并行回收器的线程数(CPU数目相等)

-XX:SurvivorRatio=6 ：servivor大小。
-XX:MaxTenuringThreshold=3：当时对象的岁数超过<n>的时候，将被放在old区


-XX:+ScavengeBeforeFullGC(默认)：Full GC的时候不做yang GC，直接整个GC。(一般在Full GC之前，都会先来一次yang GC)。
-XX:+CMSInitiatingOccupancyFraction=70 表示年老代内存空间使用到70%时就开始执行CMS收集，以确保年老代有足够的空间接纳来自年轻代的对象，避免Full GC的发生
-XX:+UseCMSInitiatingOccupancyOnly old区总是以上面哪个比例来CMS

-XX:CMSFullGCsBeforeCompaction=0 在CMS gc运行后，直接整理old的内存空间。

GC日志打印：

-XX:+PrintGCTimeStamps ：打印出垃圾回收发生的时间是距离HotSpot  VM启动时间的秒数。

-XX:+PrintGCDateStamps：gc的年月日。
-XX:+PrintGCDetails：提供了垃圾回收特有的统计信息而且具体信息依赖于使用的垃圾回收器类型
-Xloggc:/data/gc/gc.log:垃圾回收器的信息输出文件。

-XX:+PrintTenuringDistribution：输出显示在survivor空间里面有效的对象的岁数情况

5.4 日志

2012-06-21T09:57:10.518-0500: [GC [PSYoungGen: 295648K->32968K(306432K)] 296198K->33518K(1006848K), 0.1083183 secs][Times: user=1.83 sys=0.01, real=0.11 secs]
垃圾回收发生的日期：            [GC [GC类型：yang回收前->yang回收后(yang总内存) 堆回收前->堆回收后(堆总内存),回收时间][CPU时间：用户占用时间，系统占用时间，垃圾回收总时间]

---

** 六、 思路**

**6.1 前提条件 **

• 1. 内存、CPU固定
• 2. 访问可接受延迟固定

6.2 思路

• 参数设定：

1.tomcat 的线程数，连接数，连接时间
2.dubbo线程数

• 加入log日志参数

#加入
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/data/gclog/dluser/gc.log

#运行后，找出：
Full Gc
(多次)"存活数据"(old区)：280m
"permanent"(permanent区):77m
YGC：
(多次)old:1000m
(多次)old_live:280m
(多次)old_free:720m
(多次)transform:10m/次-->2m/s<用来计算old_free_gc的频率>
(多次)yang:频率：30s/次，时间：0.2s/次
计算出：
yang填充：168m/s
old_free_gc:586/10=58.6s

#最后：计算下面的基础参数
-Xmx1600m -Xms1600m -Xmn760m -XX:PermSize=93m -XX:MaxPermSize=93m 

• 根据基础参数，调整new区，整理一下yang gc的频率
• 对比可用内存和可接受延迟，调整线程数，反复设置基本参数（一般成正比，预留空间给servivor）
• 加入下面的参数

#参数：使用old CMS GC,打印servivor的
-XX:+UseConcMarkSweepGC -XX:+PrintTenuringDistribution

#根据日志计算出（存活数）
-XX:SurvivorRatio=n和-XX:MaxTenuringThreshold=n

转载于:https://my.oschina.net/u/2246410/blog/1800642