jvm监控、优化及问题排查思路

从经验总结来看jvm参数设计原则为

一、内存分配占比

当服务器比较纯粹，只有JAVA服务，没有其它如监控、代理等第三方服务且本服务网络IO不大的时候，可以将jvm内存分配占系统内存2/3左右，但是在互联网公司通常都会做微服务化，为了监控系统状态、日志收集、实时报警等服务会占用系统比较多的内存，此时jvm内存分配占系统存应当在1/2以下。

二、参数配置

jvm的最大内存与最小内存设为一样，避名内存重分配造成的性能损耗

生产环境通常内存分配会比较大，对应用暂时时间有要求可采用G1回收器（G1与CMS回收器 区别）

评估和微调 G1 GC 时，请记住以下建议：

• 年轻代大小：避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。固定年轻代的大小会覆盖暂停时间目标。
• 暂停时间目标：每当对垃圾回收进行评估或调优时，都会涉及到延迟与吞吐量的权衡。G1 GC 是增量垃圾回收器，暂停统一，同时应用程序线程的开销也更多。G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。如果将其与 Java HotSpot VM 的吞吐量回收器相比较，目标则是 99% 的应用程序时间和 1% 的垃圾回收时间。因此，当您评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意承受更多的垃圾回收开销，而这会直接影响到吞吐量。当您评估 G1 GC 的延迟时，请设置所需的（软）实时目标，G1 GC 会尽量满足。副作用是，吞吐量可能会受到影响。
• 掌握混合垃圾回收：当您调优混合垃圾回收时，请尝试以下选项。
   
  • -XX:InitiatingHeapOccupancyPercent
    用于更改标记阈值。
  • -XX:G1MixedGCLiveThresholdPercent 和 -XX:G1HeapWastePercent
    当您想要更改混合垃圾回收决定时。
  • -XX:G1MixedGCCountTarget 和 -XX:G1OldCSetRegionThresholdPercent
    当您想要调整旧区域的 CSet 时。

有关溢出和用尽的日志消息

当您在日志中看到目标空间溢出/用尽的消息时，意味着 G1 GC 没有足够的内存，供存活者和/或晋升对象使用。Java 堆不能扩展，因为已达到最大值。示例消息：

924.897: [GC pause (G1 Evacuation Pause) (mixed) (to-space exhausted), 0.1957310 secs]

或

924.897:[GC pause (G1 Evacuation Pause) (mixed) (to-space overflow), 0.1957310 secs]

要缓解此问题，请尝试以下调整：

增加 -XX:G1ReservePercent 选项的值（并相应增加总的堆大小），为“目标空间”增加预留内存量。

通过减少 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。

您也可以通过增加 -XX:ConcGCThreads 选项的值来增加并行标记线程的数目。

巨型对象和巨型分配

对于 G1 GC，任何超过区域一半大小的对象都被视为“巨型对象”。此类对象直接被分配到老年代中的“巨型区域”。这些巨型区域是一个连续的区域集。StartsHumongous 标记该连续集的开始，ContinuesHumongous 标记它的延续。

在分配任何巨型区域之前，会检查标记阈值，如有必要，还会启动一个并发周期。

在清理阶段或完整的垃圾回收周期内，标记周期结束时会清理死亡的巨型对象。

为了减少复制开销，巨型对象未包括在疏散暂停中。完整的垃圾回收周期会对巨型对象进行压缩。

由于每个 StartsHumongous 和 ContinuesHumongous 区域集只包含一个巨型对象，所以没有使用巨型对象的终点与上个区域的终点之间的空间（即巨型对象所跨的空间）。如果对象只是略大于堆区域大小的倍数，则此类未使用的空间可能会导致堆碎片化。

如果巨型分配导致连续的并发周期，并且此类分配导致老年代碎片化，请增加 -XX:G1HeapRegionSize，这样一来，之前的巨型对象就不再是巨型对象了，而是采用常规的分配路径。

总结

G1 GC 是区域化、并行-并发、增量式垃圾回收器，相比其他 HotSpot 垃圾回收器，可提供更多可预测的暂停。增量的特性使 G1 GC 适用于更大的堆，在最坏的情况下仍能提供不错的响应。G1 GC 的自适应特性使 JVM 命令行只需要软实时暂停时间目标的最大值以及 Java 堆大小的最大值和最小值，即可开始工作。

 -Xmx4096m //最大内存分配
 -Xms4096m //最小内存分配
 -Xss256k //每个线程的堆栈大小
 //-XX:NewRatio=2 年轻代和老年代大小的比例，默认是2 G1垃圾回收最好不要设置采用下面的配置
 -XX:G1NewSizePercent=30 //新生代最小值，默认值5%
 -XX:G1MaxNewSizePercent=45 //新生代最大值，默认值60%
 -XX:MetaspaceSize=256m //jdk8 元空间大小（相当于以前的perm）
 -XX:MaxMetaspaceSize=512m //jdk8最大元空间大小
 -XX:+UseG1GC //指定G1垃圾收集器
 -XX:G1HeapRegionSize=16m //G1垃圾收集器分区大小
 -XX:G1ReservePercent=25 //预留多少内存，防止晋升失败的情况，默认值是10
 -XX:MaxTenuringThreshold=15 //晋升的阈值，默认是15（一个存活对象经历多少次GC周期之后晋升到老年代)
 -XX:SurvivorRatio=8 //	eden和survivor区域空间大小的比例，默认是8
 -XX:+ParallelRefProcEnabled //采用多线程的方式发现需要处理的finalize方法的对象，非多线程执行对象的finalize方法
 -XX:-OmitStackTraceInFastThrow //一些频繁抛出的异常，JVM为了性能优化而抛出没有堆栈的异常，默认开启，
 -XX:+AlwaysPreTouch //jvm预先访问所有分配给它的内存,让操作系统把内存真正的分配给JVM
 -XX:+PrintTenuringDistribution //显示出survivor区间有效对象的年龄(经历过几次新生代回收)分布情况，可以通过该参数的输出确定出survivor大小以及 MaxTenuringThreshold 的值
 -XX:+PrintGCApplicationStoppedTime //打印垃圾收集期间应用被暂停的时间
 -XX:+UnlockExperimentalVMOptions //打印出实验性的参数
 -XX:InitiatingHeapOccupancyPercent=40 //内存占用达到整个堆百分之多少的时候开启一个GC周期，G1 GC会根据整个堆的占用，而不是某个代的占用情况去触发一个并发GC周期，0表示一直在GC，默认值是45
 -XX:MaxGCPauseMillis=20 //G1收集器GC最大停顿时间ms
 -XX:ParallelGCThreads=4 //GC在并行处理阶段启动多少个线程，默认值和平台有关。一般不设采用默认配置
 -XX:ConcGCThreads=n //并发收集的时候使用多少个线程，默认值和平台有关。一般不设采用默认配置
 -verbose:gc // 表示输出虚拟机中GC的详细情况
 -XX:+PrintGCDetails //打印gc日志，打印的出日志包含日志收集原因，各区域变化情况，以及用时
 -XX:+PrintHeapAtGC //打印gc前后堆详细信息，不管是minor gc还是full gc都会打印
 -XX:+PrintGCDateStamps //日志中输出时间戳
 -XX:+PrintPromotionFailure //是多大的新生代对象晋升到老生代失败从而引发Full GC
 -XX:+HeapDumpOnOutOfMemoryError //在Out Of Memory，JVM快死掉的时候，输出Heap Dump到指定文件。不然开发很多时候还真不知道怎么重现错误
 -XX:+PrintAdaptiveSizePolicy //可以打印出survivor的一些详细信息，关于survivor区间是否溢出，是否有对象转移到老年代
 -XX:+UseGCLogFileRotation //
 -XX:NumberOfGCLogFiles=5 //
 -XX:GCLogFileSize=30M //这三个参数用于设置gc文件滚动和设置滚动日志文件的个数，为了防止单个gc日志文件太大，生产上建议加上这两个参数；
 -Xloggc:/opt/logs/jetty/gc_%p.log //gc log输出地址
 -XX:HeapDumpPath=/opt/logs/jetty/java.hprof //heap dump日志地址
 -XX:ErrorFile=/opt/logs/jetty/hs_err_pid%p.log //JVM crash时生成crash文件的路径

 

转载于:https://my.oschina.net/laigous/blog/3080613