故障重现(内存篇2)，JAVA内存不足致使频繁回收和swap引发的性能问题

背景原由：

记起之前的另外一次也是关于内存的调优分享下

有个系统平时运行很是稳定运行（没经历过大并发考验），然而在一次活动后，人数并发一上来后，系统开始卡。

我按经验开始调优，在每一个关键步骤的加入以下代码耗时统计进行压测：

long startTime = System.currentTimeMillis();
callRpc();   //这里好比调用RPC伪代码，固然还在插入数据库，中间件地方都加入统计
long costTime = (System.currentTimeMillis() - startTime); 
//统计600毫秒以上耗时
if (costTime > 600) { 
logger.warning("callRpc cost time:" + costTime); 
}

而后去grep日志， 最后神奇的发现各个地方都有超过600毫秒的地方...

而后各类定位的误导...

固然最终是解决了，缘由是因为程序里使用了大对象致使

细分析，即便这种状况深研究也是分不少状况的

 

问题重现：

缘由分析：

因为系统中使用了大对象，当并发来临，内存讲被吃紧，将有可能引发以下三种状况

第一种状况， 系统内存够用(JVM内存未使用到SWAP内存)，但JVM内存不够，最终致使JVM的频繁垃圾回收（FGC），严重影响性能 (stop the word)

第二种状况，系统内存不够，把JVM堆部分用到了SWAP，那么此时的垃圾回收须要把SWAP的内存换回到系统物理内存再进行JVM的垃圾回收。最大影响，致使每次GC的时间变得好久

第三种状况,  物理内存不够用， 大量JVM的堆内存被交换到SWAP后，垃圾回收时，把SWAP内存换回物理内存，但SWAP的内存又不会当即回， 此时能够观察到垃圾回收同时swap使用的内存会变大(其它部份内存要交换到SWAP里)

 

准备：

ubuntu 1G  4核

先关闭SWAP虚拟空间 sudo swapoff -a

java version "1.7.0_101"

apache-tomcat-8.5.9

设置好Tomcat的JVM内存：

JAVA_OPTS="-Xmx500m -Xms500m -Xmn200m -Xss228k -XX:+UseConcMarkSweepGC -XX:+UseParNewGC"

apache-jmeter-2.13 用于模拟HTTP请求压测，都是100条线程并发进行压测

 

模拟代码以下

/**
 * 模拟当系统中使用大对象时,对JVM形成的影响
 * 
 * @author 包子(何锦彬). 2017.01.07
 * @QQ 277803242
 */
@WebServlet("/Test")
public class Test extends HttpServlet {
    private static final long serialVersionUID = 1L;
    private Logger logger = Logger.getLogger(Test.class.getName());

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        // use java heap 10m
        byte[] bts = new byte[1024 * 1024 * 10];// 代码段1
        long startTime = System.currentTimeMillis();
        // deal
        try {
            // 模拟业务花费时间
            Thread.sleep(500);
        } catch (InterruptedException e) {
        }

        // 理论上这里输出500附近
        long costTime = (System.currentTimeMillis() - startTime);
        if (costTime > 600) {
            logger.warning("cost time:" + costTime);
        }

        Writer out = response.getWriter();
        out.append("ok");
    }

 

 

先模拟正常的状况:

先注释掉"代码段1", 1W个请求下来，基本耗时都在500，一切正常，返回都是在500毫秒附近

垃圾回收状况，只发生了1次YGC，因此系统正常稳定...

 

模拟第一种状况:

放开“代码段1”，让每次请求都去堆内存申请10m的堆空间，一样是1W个请求，返回的平均值已经接近了2S

垃圾回收状况来看， 已经发生了1966次的FGC了， 在上面耗时158秒

 

模拟第二种状况:

把系统的SWAP打开,打开2G的SWAP，swapon -a

调大JVM参数，到1G，让JVM用到部分SWAP的空间

此时再让每次请求都去堆内存申请10m的堆空间，一样是1W个请求，性能已经低于第二种状况

垃圾回收来看，回收次数是1766次，比第二种状况发生的次数还要少,但FGC耗费的时间已是212秒，

（虽然多了200m内存也没差距这么大，更精确看年轻代同样的内存，耗时也远超过）远超过第二种状况了

此时垃圾回收详情：

模拟第三种状况:

这种状况和我上一篇提到的相似,若是系统内存不够用时，系统将KIIL掉内存

 

总结：

频繁垃圾回收（FGC），会严重影响性能。若是此时用耗时统计去寻找瓶颈，会出现失误；

 

如JVM堆用到了SWAP分区，当发生GC:

1，会致使大量SWAP被使用，2，致使每次GC的时间变得好久；

 

SWAP分区开启能够有效防止进程由于内存问题而被系统杀掉；

 

 

持续更新留言问题，解答疑问

欢迎关注个人公众号，专一重现各类线上的BUG

 或搜 “包子的实验室”