1. 前言

  • 本文仅分享本人在工作中遇到的问题时的解决方案和思路，以及排查的过程。重点还是分享排查的思路，知识点其实曾经挺老了。如有疑难或形容不妥，欢送赐教。

2. 问题表象

  • 在工程启动的时候，零碎的申请会有一波超时，从监控来看，JVM 的GC（G1） 稳定较大，CPU稳定较大，各个业务应用的线程池稳定较大，内部IO耗时减少。

3. 先说论断

  • 因为JIT的优化，导致系统启动时触发了热点代码的编译，且为C2编译，引发了CPU占用较高，进而引发一系列问题，最终导致局部申请超时。

4. 排查过程

其实知识点就放在那里，如何将理论遇到的问题和知识点分割到一起并能更粗浅的了解这部分常识，这或者就是排查和剖析的意义，而后积淀为教训，进而成长。

4.1 最后的排查

  • 其实咱们的工程是一个算法排序工程，外面或多或少也加了一些小的模型和大大小小的缓存，而且从监控上来看，JVM 的GC 突刺和 CPU 突刺工夫极为靠近（这也是一个监控平台工夫不够精准的起因）。所以在后期，我消耗了大量精力和工夫去排查JVM，GC 的问题。
  • 首先举荐给大家一个网站：https://gceasy.io/ ，真的剖析GC日志巨好用。配合以下的JVM参数打印GC日志：
-XX:+PrintGC 输入GC日志-XX:+PrintGCDetails 输入GC的具体日志-XX:+PrintGCTimeStamps 输入GC的工夫戳（以基准工夫的模式，你启动的时候相当于12点，跟实在工夫无关）-XX:+PrintGCDateStamps 输入GC的工夫戳（以日期的模式，如 2013-05-04T21:53:59.234+0800）-Xloggc:../logs/gc.log 日志文件的输入门路

  • 因为看到YGC重大，所以先后尝试了如下的办法：

    • 调整JVM 的堆大小。即 -Xms, -Xmx 参数。有效。
    • 调整回收线程数目。即 -XX:ConcGCThreads 参数。有效。
    • 调整冀望单次回收工夫。即 -XX:MaxGCPauseMillis 参数，有效，甚至更惨。
    • 以上调整混合测试，均有效。
    • 鸡贼的办法。在加载模型之后sleep 一段时间，让GC安稳，而后再放申请进来，这样操作之后GC的确有些恶化，然而刚开始的申请依然有超时。（当然了，因为问题基本不在GC上）

4.2 换个思路

  • 依据监控上来看，线程池，内部IO，启动时都有显著的RT回升而后降落，而且趋势十分统一，这种个别都是系统性问题造成的，比方CPU，GC，网卡，云主机超售，机房提早等等。所以GC既然无奈根治，那么就从CPU方面动手看看。
  • 因为系统启动时JVM会产生大量GC，无奈辨别是因为系统启动还没预热好就来了流量还是说无论启动了多久，流量一来就会出问题。而我之前排查GC 的操作，即加sleep工夫，恰好帮我看到了这个问题，因为能显著的看出，GC稳定的工夫，和超时的工夫，工夫点上曾经差了很多了，那就是说，与GC无关，无论GC曾经如许安稳，流量一来，还是要超时。

4.3 剖析利器Arthas

不得不说，Arthas 真的是一个很好用的剖析工具，节俭了很多简单的操作。
  • Arthas 文档： https://arthas.aliyun.com/doc...
  • 其实要剖析的外围还是流量最开始到来的时候，咱们的CPU到底做了什么，于是咱们应用Arthas剖析流量到来时的CPU状况。其实这部分也能够应用top -Hp pid , jstack 等命令配合实现，不开展叙述。
  • CPU状况，仅展现重要局部：

图中能够看出C2 CompilerThread 占据了十分多的CPU资源。

4.4 问题的外围

  • 那么这个C2 CompilerThread 到底是什么呢。
  • 《深刻了解JAVA虚拟机》其实有对这部分的叙述，这里我就大白话给大家解释一下。
  • 其实Java在最开始运行的时候，你能够了解为，就是傻乎乎的依照你写的代码执行上来，称之为"解释器"，这样有一个益处，就是很快，Java搞成.class ，很快就能启动，跑起来了，然而问题也很显著啊，就是运行的慢，那么聪慧的JVM开发者们做了一件事件，他们如果发现你有一些代码频繁的执行，那么他们就会在运行期间帮你把这段代码编译成机器码，这样运行就会飞快，这就是即时编译（just-in-time compilation 也就是JIT）。然而这样也有一个问题，就是编译的那段时间，消耗CPU。而C2 CompilerThread，正是JIT中的一层优化（共计五层，C2 是第五层）。所以，罪魁祸首找到了。

5. 尝试解决

  • 解释器和编译器的关系能够如下所示：

  • 就像下面说的，解释器启动快，然而执行慢。而编译器又分为以下五个档次。
第 0 层：程序解释执行，默认开启性能监控性能（Profiling），如果不开启，可触发第二层编译；第 1 层：可称为 C1 编译，将字节码编译为本地代码，进行简略、牢靠的优化，不开启 Profiling；第 2 层：也称为 C1 编译，开启 Profiling，仅执行带办法调用次数和循环回边执行次数 profiling 的 C1 编译；第 3 层：也称为 C1 编译，执行所有带 Profiling 的 C1 编译；第 4 层：可称为 C2 编译，也是将字节码编译为本地代码，然而会启用一些编译耗时较长的优化，甚至会依据性能监控信息进行一些不牢靠的激进优化。
  • 所以咱们能够尝试从C1，C2编译器的角度去解决问题。

5.1 敞开分层编译

减少参数 ： -XX:-TieredCompilation -client （敞开分层编译，开启C1编译）
  • 成果稀烂。
  • CPU使用率继续高水位（相比于调整前）。的确没了C2 thread 的问题，然而猜想因为代码编译的不够C2那么优良，所以代码继续性能低下。
  • CPU截图：

5.2 减少C2 线程数

减少参数 ：-XX:CICompilerCount=8 复原参数：-XX:+TieredCompilation
  • 成果个别，依然有申请超时。然而会少一些。
  • CPU截图：

5.3 推论

  • 其实从下面的剖析能够看出，如果绕不过C2，那么必然会有一些抖动，如果绕过了C2，那么整体性能就会低很多，这是咱们不愿看见的，所以敞开C1，C2，间接以解释器模式运行我并没有尝试。

5.4 最终计划

  • 既然这部分抖动绕不过来，那么咱们能够应用一些mock 流量来接受这部分抖动，也能够称之为预热，在工程启动的时候，应用提前录制好的流量来使零碎热点代码实现即时编译，而后再接管真正的流量，这样就能够做到实在流量不抖动的成果。

后话

  • 本文着重分享解决和剖析的过程，知识点没有重点剖析。更多知识点请看“参考文章”局部。
  • 本文如有问题欢送各位校对。

参考文章

  • 【对于java：-XX：-TieredCompilation到底做什么】https://www.codenong.com/3872...
  • 【如同是下面那篇文章的原版】https://stackoverflow.com/que...
  • 【C2 Compiler Thread】https://blog.csdn.net/chenxiu...
  • 【C2 CompilerThread9 长时间占用CPU解决方案】https://blog.csdn.net/m0_3788...
  • 《深刻了解Java虚拟机第二版》第四局部的“早期(运行期)优化”
  • 【深入分析JVM中线程的创立和运行原理 ｜｜ JIT（future）】https://www.cnblogs.com/silyv...
  • 【HotSpot虚拟机的分层编译（Tiered Compilation）】https://blog.csdn.net/u013490...