本文内容次要介绍，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的值也上来了。达到了预期的一个指标。

总结

其实对于一个性能瓶颈问题的剖析排查定位，犹如医生看病，须要望闻问切，通过表面现象逐层的去排除一种种的可能性，最终找到其根本原因，隔靴搔痒解决问题。本文介绍的也只是性能瓶颈问题中的一个小小的局部，其实在压测过程中还会遇到各种各样的问题，然而咱们把握了方法论，其实都能够依照雷同的思路去排查，最终找到本源。

作者：京东衰弱 牛金亮

起源：京东云开发者社区