微服务性能调优03

近期遇到一些技术问题,记录如下:

1、NAS引起的惨案一
上次说到,大家都在降本,于是我们做了一系列调整工作。但降本总有一个永恒不变的主题:降配。
于是我们和集团的科技,同时开始了惨无人道的降配工作。
在一顿神奇操作后,系统终于区域稳定,好景不长,突然间又出问题了。

表现:
系统部分服务的部分节点,在服务高峰期之后,总是会出现时不时的系统卡顿。
关键这个卡顿很有规律,总是上午10点,下午4点出现,完美错过我们的上下午业务高峰。
原因:
经过技术委员会小伙伴通力排查,大家最终定位到是应用日志写入到归档NAS时,NAS性能十分不稳定,IO时间有时会高达几秒。
一旦遇到NAS卡顿,会阻塞日志,进而阻塞服务。
而且,当前NAS是和兄弟公司公用的,NAS卡顿时,正值他们的业务高峰期。
解决:
应用日志不再输出到NAS,而是输出到日志云。

2、NAS引起的惨案二
平稳度过了几天,周五,问题又来了。
表现:
系统时不时卡顿,没有任何规律,和业务高峰没有任何关系,一切监控都正常。
原因:
经过N个小时排查,我们的小伙伴,终于发现问题还是出现在日志上,只不过这一次,是GC日志。
GC日志同样是在归档NAS上,此时归档NAS更加不稳定,minor gc日志写入,偶尔会遇到NAS IO延时,引起系统卡顿。
解决:
应用日志不再输出到归档NAS,而是输出到中端闪存NAS,花钱买平安。
进一步:
针对当前遇到的情况,重新制定日志规范,尽快推广落地。

3、一次RefreshScope引发的惨案
表现:
使用nacos动态刷新了一个配置,但相关服务突然越来越慢,并有大量的锁等待:sun.misc.Unsafe.park

原因:
初步分析,nacos更新配置后,对应RefreshScope的类需要重新加载配置,从而调用了GenericScope类的destroy方法,在该方法中加了writelock
同时,业务代码在处理请求的时候,同样的用到了GenericScope::LockedScopedProxyFactoryBean的invoke方法,在该方法中加了readlock
先是读锁(多个),再写锁(一个),再读锁(多个),最后死锁了,都无法获取锁,服务就卡住了。问题是,一开始的锁为何不释放呢?

进一步分析,发现是在服务业务代码中,用到了HttpClient的org.apache.http.impl.io.SessionInputBufferImpl.streamRead方法
该方法调用了java.net.SocketInputStream.socketRead,该方法触发了jdk8的一个bug,该native方法无法返回

解决:
升级JDK版本,同时代码改造缩小RefreshScope的范围

4、一次redis引发的惨案
表现:
几分钟内redis内存飙高,直接爆掉。
查看了业务系统日志,没有出现业务激增的情况。
查看redis日志,发现AOF日志不断增大,重写的时候缓存爆掉,导致主备切换。
监控日志反馈存在大量setex操作。

原因:
reids集群出现大量setex操作,导致AOF日志激增,日志重写时落盘速度缓慢(出现了short write),结果AOF日志缓存爆掉,主从切换

解决:
临时升级了内存,后续将日志盘从NAS改为SSD,并好服务的redis主从切换配置
但setex激增的原因暂时还没有查到,补充了一些防御性代码

5、一次jdk引发的惨案
表现:
一个生成表单PDF的微服务会产生大量的临时文件,而且不会自行清理。

原因:
在用到的一个第三方Jar包中,用到了java.awt.Font类,该类用到了createFont方法

//不会产生大量临时文件
static Font createFont(int fontFormat, File fontFile)
//会产生大量临时文件,初步判断是JDK的问题
static Font createFont(int fontFormat, InputStream fontStream)

解决:
重写了改Jar包的类,从InputStream切换到了File

6、一次防火墙引发的惨案
表现:
部分用户反馈,无法正常加载微信小程序,需要点击右上角进行刷新才行

原因:
从腾讯后台可以看到,有大约18%的请求会超过60S,其余正常
然后到微服务层,发现有一些请求,在返回数据包的时候,会收到“连结已断开”的反馈,与腾讯后台表现较为一致
然后向前一点儿一点儿的捋,最后发现,需要访问的腾讯IP有5个,之前开墙只开了4个,第5个IP数据返回时就被防火墙直接拦截了。

解决:
提单,开墙,解决问题