本文内容主要介绍，618医药供应链质量组一次军演压测发现的问题及排查优化进程。旨在给大家借鉴参考。
布景
本次军演压测布景是，2B事务线及多个事务侧共同和B中台联合军演。
现象
当压测产品卡片接口的时分，cpu到达10%，TPS只要240不满足预期目标，可是TP99现已到达了1422ms。
排查
关于这种TPS不满足预期目标，可是TP99又超高，其实它的原因有许多中或许，经过之前写过的文章对功能瓶颈的一个剖析方法《功能测试监控目标及剖析调优》，咱们能够采用自下而上的策略去进行排查：
首要是操作体系层面的CPU、内存、网络带宽等，关于集团内部的压测，机器的装备、网络带宽，这些要素运维人员现已装备到最优的程度了，无需咱们再关怀是否是因为硬件资源体系层面导致的要素。
接下来从代码层面和JVM层面进行排查，或许是项目代码中出现了线程堵塞，导致线程出现等待，呼应时刻变长，请求不能及时打到被测服务器上。关于这种猜想，咱们能够在压测进程中打线程dump文件，从dump文件中找到哪个线程一致处于等待状况，从而找到对应的代码，检查是否能够进行优化。这块同开发一同剖析整个接口的调用链路，产品卡片接口调用运营端的优惠券的可领可用接口，经过检查此接口的ump监控那个，发现调用量其实并不高。接下来经过检查运营端机器的日志发现，调用可领可用优惠券接口现已超时了，而且机器CPU现已偏高，使用率平均在80%以上。是什么原因导致调用可领可用接口很多超时，成为了问题的关键点。
首要咱们代码层面剖析，这个可领可用优惠券接口还会调用一个过滤器进行过滤，所以猜想是不是这个过滤器接口把CPU打满了，可是经过监控过滤器接口的ump中能够看到它的TP99并不是很高，阐明它的调用量没有上去，这种猜想或许不成立。还好其时代码这设置了一个开关是否使用过滤器，咱们把过滤器的开关封闭后。再次进行压测产品卡片接口，发现仍是没有解决问题，TPS仍然不高，而且TP99仍是很高。阐明这个猜想真是不成立的。
接下来咱们转换思路，检查JVM日志，是否从中寻找到一些蛛丝马迹，公然从JVM的GC日志中可看到Ygc和Fgc的时刻占用比较长，其间Fullgc的时刻占用时刻到达了7165ms，而且从中能够检查jvm的参数装备，发现Xms 和Xmx装备的值都是1024，只要1个G。问题的原因找到了，这台被压测的机器JVM参数装备的Xms 和Xmx值太小了，假如-Xmx指定偏小，使用或许会导致java.lang.OutOfMemory过错
关于JVM的介绍这部分比较巨大涉及到类加载方法、JVM内存模型、废物回收算法、废物收集器类型、GC日志，在这就不做具体阐明晰，想要了解具体内容能够看看《深化了解 JAVA 虚拟机》这本书。
此处简单阐明下什么是Ygc和Fgc，以及Xms、Xmx的意义。
JVM内存模型中，分为新生代、老时代和元空间，新生代又分为eden区、Survivor0、Survivor1区。目标优先在Eden区分配，当Eden区没有足够空间时会进行一次Minor GC，履行完第一次MGC之后，存活的目标会被移动到Survivor（from）分区，当Survivor区存储满了之后会进行一次Ygc，可是Ygc一般不会影呼使用。当老时代内存不足的时分，会进行一次Full GC，也便是Stop the world，体系将停止运转，清理整个内存堆（包括新生代和老时代） ，FullGC频率过大和时刻过长，会严重影响体系的运转。
Xms，JVM初始分配的堆内存
Xmx，JVM最大分配的堆内存
一般情况这两个参数装备的值是相等的，以避免在每次GC 后堆内存重新进行分配。
优化
终究修改机器的JVM数装备
检查JVM装备参数
重启后再次进行压测，咱们的TPS目标上来了，而且TP99的值也下去了。到达了预期的一个目标。
总结
其实关于一个功能瓶颈问题的剖析排查定位，犹如医生治病，需求望闻问切，经过表面现象逐层的去扫除一种种的或许性，终究找到其根本原因，对症下药解决问题。本文介绍的也只是功能瓶颈问题中的一个小小的部分，其实在压测进程中还会遇到各式各样的问题，可是咱们把握了方法论，其实都能够按照相同的思路去排查，终究找到根源。
作者：京东健康 牛金亮
来历：京东云开发者社区
