没办法了,被连续问到这个问题,必须讲一下了
java程序写得不好,要么cpu高,要么内存高,内存可以不断扩大,我们的某个pod,已经扩到8G了,node总共才16G,无语啊。
那究竟用啥玩意来排查呢?
那必须推荐async-profiler了
使用也很简单,运行排查即可
1mkdir -p /opt/app/profiler
2
3wget https://github.com/async-profiler/async-profiler/releases/download/v4.2/async-profiler-4.2-linux-x64.tar.gz
4
5tar zxvf async-profiler-4.2-linux-x64.tar.gz -C /opt/app/profiler --strip-components=1
命令很简单,关键是参数-e的选择:
- 高 CPU 占用 (CPU-Bound)?缺省参数
- 首选:
-e cpu或-e cycles - 目标: 查看火焰图顶端最宽的方法,即消耗 CPU 最多的计算代码。
- 首选:
- I/O 阻塞、锁等待或应用假死 (Latency/Blocking-Bound)?
- 首选:
-e wall - 目标: 查找火焰图顶端长时间处于
BLOCKED或 I/O 相关的代码块,找出阻塞的根源。
- 首选:
- 频繁 GC 或内存消耗过快?
- 首选:
-e alloc - 目标: 找出哪些方法在短时间内创建了大量对象,导致年轻代 GC 频繁。
- 首选:
- 明确怀疑锁竞争?
- 首选:
-e lock - 目标: 准确找出哪个锁是主要的竞争点。
- 首选:
那确定目标,cpu是缺省参数,所以可以直接运行
1./asprof -d 30 -f 1.html 1
解释,-d 分析实践30秒,-f输出的文件,最后的1是java的进程号,这样就生成了一个1.html的文件
打开看看:
看看底下那部分,kafka相关,点开动辄是63%之流的,说明都干这事了,去kafka里查询耗费了大量的cpu时间。
然后再看看内存,再收集一波:
1./asprof -d 30 -e alloc -f 2.html 1
同样是kafka部分,又耗内存又耗CPU。唉,优化吧。