likes
comments
collection

一次应用多次fgc原因的排查及解决

作者站长头像
站长
· 阅读数 13

应用多次fgc性能排查(一次抢购引起的性能问题)

大家好我是魔性的茶叶,今天分享一个项目jvm多次fgc的整个排查流程

上班后不久运维突然通知我们组,有一个应用在短时间内多次fgc,即将处于挂掉的状态。

首先我登录skywalking,观察应用整体状况

首先先交代下背景,该项目属于一个整合消息的项目,可以称之为消息中心,负责我们应用中的所有的推送,短信及公众号推送,消息都是通过业务方面投递到kakfa消费的方式,所以feign或者http调用的外部调用几乎没有

首先通过cpm(call per minute/每分钟服务被调用数)观察服务整体情况

一次应用多次fgc原因的排查及解决

我们可以看到在8.到8.07分这段时间有一个波峰,询问产品得知是有医院开启了抢购药品的业务(某些专科医院比如说皮肤病医院,会在一些特定时段,每天开启限制数量的药品抢购,这个抢购属于比较火爆的业务),所以这个流量峰值是正常的。流量一大,消息队列中的消息数量立刻就上来了:

一次应用多次fgc原因的排查及解决

那么我第一个想法,有没有可能是kafka消息堆积呢?应用的处理能力跟不上,导致消息大量堆积,带着这个问题,我去看一下skywalking监控的消费速度,打开Endpoint监控,观察slow endpoints:

一次应用多次fgc原因的排查及解决

可以看到最慢的kafka消费速率在234ms,对于一个需要调用第三方外部接口完成业务的消费来说,这个速度不可以说慢,甚至还可以说有点小快。没关系,只要是性能问题,那么总是有迹可循。我点开最高负载的服务实例查看gc次数:

一次应用多次fgc原因的排查及解决

可以看到在8.6分流量最高的这段时间fgc的次数达到了70次,这确实离谱,按照我的经验一个健康的应用甚至不应该一天fgc超过10次,这一分钟超过70次居然还没当场挂掉,简直可以称之为坚挺。我们再看看jvm线程数量:

一次应用多次fgc原因的排查及解决

waiting的线程在流量冲入后大量增加,几乎导致了oom,在流量波峰过去后线程数量又慢慢归于平稳

所以观察结论是大量被创建的线程导致的内存飙高,接下来就是需要观察线程快照找出罪魁祸首了

将线程堆栈导入fastthread.io/分析堆栈,我们查看线程数最多的相同线程组

一次应用多次fgc原因的排查及解决

这个明显是OkHttp使用不当导致的OkHttp链接池的异常增多,我第一个反应是联想到我们的fegin调用,feign底层可能使用了OkHttp导致OKHttp链接池创建异常。下一秒就把自己的推测推翻了,因为首先feign不可能有这么明显的问题,第二是上图中的“OkHttp api.tpns.tencent.com”我们并不是通过feign调用,而是直接通过sdk调用的(这个是tpns,腾讯的app推送)

那么,有没有可能是sdk的问题呢?

我们是这么调用腾讯的推送的:

//每次推送都会调用这段代码 
XingeApp xingeApp = new XingeApp.Builder()
                .appId(androidAppId)
                .secretKey(androidSecret)
                .domainUrl(PREFIXURL)
                .build();
 return xingeApp.pushApp(pushAppRequest);

点开build方法发现是这样的

 public XingeApp build() {
            if (appId == null || secretKey == null) {
                throw new IllegalArgumentException("Please set appId and secret key.");
            }
​
            return new XingeApp(this);
        }
​
​
private XingeApp(Builder builder){
        if(builder.domainUrl != null){
            restapiV3.setDomainUrl(builder.domainUrl);
        }
​
        this.accessId = builder.appId;
        this.secretKey = builder.secretKey;
        this.isSignAuth = builder.useSignAuth;
​
        client = new OkHttpClient.Builder()
                .proxy(builder.proxy)
                .connectTimeout(builder.connectTimeOut, TimeUnit.SECONDS)//设置连接超时时间
                .readTimeout(builder.readTimeOut, TimeUnit.SECONDS)//设置读取超时时间
                .build();
 }
​
​

可以看到这个new XingeApp(this)到后面是初始化了一个OkHttpClient的客户端,点进OkHttpClient的Builder方法是这样的:

public Builder() {
      dispatcher = new Dispatcher();
      protocols = DEFAULT_PROTOCOLS;
      connectionSpecs = DEFAULT_CONNECTION_SPECS;
      eventListenerFactory = EventListener.factory(EventListener.NONE);
      proxySelector = ProxySelector.getDefault();
      cookieJar = CookieJar.NO_COOKIES;
      socketFactory = SocketFactory.getDefault();
      hostnameVerifier = OkHostnameVerifier.INSTANCE;
      certificatePinner = CertificatePinner.DEFAULT;
      proxyAuthenticator = Authenticator.NONE;
      authenticator = Authenticator.NONE;
    //可以看到罪魁祸首就在这里
      connectionPool = new ConnectionPool();
      dns = Dns.SYSTEM;
      followSslRedirects = true;
      followRedirects = true;
      retryOnConnectionFailure = true;
      connectTimeout = 10_000;
      readTimeout = 10_000;
      writeTimeout = 10_000;
      pingInterval = 0;
    }

于是真相大白,原来ConnectionPool对象是在这里new出来的

可以看到,每次new一个XingeApp就会new一个OkHttpClient,顺便new一个ConnectionPool。而每次推送的都会new一个XingeApp导致内存中有大量的ConnectionPool对象存在,直到堆满了进行一次fgc,又能回收掉很大部分的内存,因为大部分ConnectionPool在推送完成后以后都是没用的垃圾内存,推送又是海量的,所以导致内存一直满一直fgc但是又能一直抗住(因为每次fgc可以gc掉大部分内存)

那么怎么解决呢?

最简单的解决方式就是减少XingeApp实例的对象,因为没必要每次推送都去new一个对象出来,按理说只需要一个实例就够了,OkHttpConnectionPool也只需要一个,链接的复用和摧毁完全交给OkHttp就行。所以修改如下:

//伪代码 双重校验锁
public static XingeApp getAndroidXingeAppInstance(){
        if (androidXingeAppInstance !=null){
            return androidXingeAppInstance;
        }
        synchronized (TpnsPushLogicImpl.class) {
            if (androidXingeAppInstance !=null) {
                return androidXingeAppInstance;
            }
            androidXingeAppInstance = new XingeApp.Builder()
                    .appId(staticAndroidAppId)
                    .secretKey(staticAndroidSecret)
                    .domainUrl(PREFIXURL)
                    .build();
            return androidXingeAppInstance;
        }
}
​
public void pushMessage(){
     XingeApp xingeApp = getAndroidXingeAppInstance();
    xingeApp.pushMessage;
}
​

升级后在推送高峰期重新查看skywalking仪表板:

一次应用多次fgc原因的排查及解决

一次应用多次fgc原因的排查及解决

可以明显看到线程数量降下来了,gc也只有ygc,说明很健康

重新打出该应用的线程快照,导入线程快照分析工具查看okHttpConnectionPool线程

一次应用多次fgc原因的排查及解决

可以看到现在应用内只有一条OkHttpConnection的线程,改造成功