K8S下应用异常卡顿问题的分析与学习

背景

周二自己在处理申威服务器的问题时, 被同事拉进一个群聊.
告知客户现场有一个特殊情况: 
服务晚上重启,  上午速度还可以, 但是到了下午就开始变的非常卡顿.

因为当时正在车上也看不到具体信息. 
晚上九点上会进行了一次简单查看.

发现GC非常平稳, 容器内的CPU和内存都和很正常
部署模式是 华为鲲鹏服务器上面的 华为云 K8S集群
容器部署.

第一次问题分析

第一天没有上手操作(这是一个败笔)
根据现场同事的说明进行了简单的判断. 

启动参数问题不大, 资源没问题 , GC没问题
同事一开始怀疑是 虚拟化挤压导致的性能下降
我通过gclog发现GC时间变化不大, 排除了这一个可能. 

但是怀疑自己分析错了 top -Hp的文件,导致出现误判
怀疑的方向到了 东方通中间件. 以为是中间件的问题. 

第二次问题分析

周三下午问题依旧. 
不过也排除了东方通的问题, 不算是没收获.
没办法紧急联系了华为云的运维人员
进行了一些简单的沟通
发现大家都一样, 认为自己没问题. 
都是别人的问题. 
云平台说别人没问题, 就你们有问题
我们说大项目都没问题,就这个项目有问题.
没办法继续折腾 

周三其实没有特别大的发现, 想着继续看看

第三次问题分析

周四下午问题继续 !-_-!
正好下午有时间可以远程, 趁着六点客户使用低谷期进行了验证
周三其实还是有一个收获的, 看到华为云有一个jvm的监控
周四自己能操作, 多看了会儿, 发现 codecache 是一个深坑, 只有 48MB
然后继续上手操作: 
其实方法还是一样的. 
第一步 docker exec -it $containerid bash 进入容器
第二步 top -Hp 16 然后输入大写的 T  查看 现成CPU使用时间
这里存在一个坑爹的问题, 容器内不显示具体线程信息, 只显示java
第三步 jstack -l 16 > 1.txt 然后 cat 1.txt |grep C2 
查看C2 编译进程的 进程号 发现是 nid=0x32 和 nid=0x33
查看第一步里面的 50号和51号线程, 发下CPU使用率已经超过了80分钟. 
注意这里需要进行 16进制和10进制的转换. 

基本确认 产品应该是 codecache 太小导致的问题. 

问题解决

增加启动脚本: 
-XX:InitialCodeCacheSize=1G  -XX:ReservedCodeCacheSize=1G  

第二天进行查看. 
发现 时间基本可控了. 

问题原因确定

拿现场的JDK 到公司内部进行验证
替换自己的aarch64的 jdk 进行处理
文件名为:
jdk-8u221-linux-arm64-vfp-hflt.tar.gz
替换之后进行启动. 发现
 cat jdk1.8.221.txt |grep C2
"C2 CompilerThread1" #6 daemon prio=9 
"C2 CompilerThread0" #5 daemon prio=9 
只有C2没有C1
[root@NFSV3 ~]# cat jdk1.8.221.txt |grep C1

之前的jdk的情况是: 
[root@NFSV3 ~]# cat jdk18222.txt |grep C1
"C1 CompilerThread20" #25 daemon prio=9 
"C1 CompilerThread19" #24 daemon prio=9 
"C1 CompilerThread18" #23 daemon prio=9 
"C1 CompilerThread17" #22 daemon prio=9 
"C1 CompilerThread16" #21 daemon prio=9 
"C1 CompilerThread15" #20 daemon prio=9 
"C1 CompilerThread14" #19 daemon prio=9 

现场的JDK版本存在问题.  一方面太久, 并且是一个prerelease的.

问题进一步的思考

这个简单的问题浪费了两天的时间
(主要是有其他事情在, 自己没直接上手.)

但是不想浪费时间就这么白白浪费了
趁着帮人解决问题, 想多进行一下思考和数据获取

第一个: 为什么我这边正常情况下 服务器返回而也有 300ms.
不应该这么多的, 公司内x86的机器才  20ms左右
自己想到了网络延迟, 然后ping了下,发现延迟在 40ms. 
自己与项目所在地的距离应该是
好几千公里.  所以理论上在局域网应该会少40ms
然后让交付进行了验证, 的确现场大概是 250ms 左右

第二个: 想到了是容器化部署的情况
我让交付同事直接使用node:port的方式进行查看时延的情况
发现延迟也差不多 250ms
所以怀疑 K8S的出口有一个较大行的网络设备影响了网络延迟. 
公司内最快15ms.明显网络设备产生了 240ms的延迟. 

问题进一步思考之二

为啥方法区默认是48MB
现场同事很细心, 立马发现 分层编译时默认值是 240MB
不启用分层编译是  48MB
但是我们没有明确在指定不使用分层编译
所以这是一个什么鬼? 

又花费了了一段时间进行排查, 暂未发现
感觉可以问问呢 华为云或者是 jdk的版本? 

问题的进一步思考之三

其实如果有perf 或者是 epbf 
或者是使用arthas 或者是 async profiler
可以通过查看火焰图里面大的平台
如果升级jdk 可以使用jfr 然后同构jmc进行分析

估计也可以看到是 complie 相关
也可以确定这个问题原因
但是现场没有部署这一些工具, 部署工具有担心影响性能. 

所以很多问题是需要循序渐进的. 
提高自己的武器库才重要
不能盲猜不能盲信. 

问题的进一步思考之四

需要统一交付物
这几天帮助同事进行处理. 
他找了一圈都没找到openjdk的下载点
自己下载的这个jdk有bug 
也不能怪这位同事.

还是需要有一个统一的知识库和可以获取下载的点的.