共计 1737 个字符，预计需要花费 5 分钟才能阅读完成。
本文内容次要介绍，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 的值也上来了。达到了预期的一个指标。
总结
其实对于一个性能瓶颈问题的剖析排查定位，犹如医生看病，须要望闻问切，通过表面现象逐层的去排除一种种的可能性，最终找到其根本原因，隔靴搔痒解决问题。本文介绍的也只是性能瓶颈问题中的一个小小的局部，其实在压测过程中还会遇到各种各样的问题，然而咱们把握了方法论，其实都能够依照雷同的思路去排查，最终找到本源。
作者：京东衰弱 牛金亮
起源：京东云开发者社区
