记一次JAVA进程导致Kubernetes节点CPU飙高的排查与解决
<h1 id="一发现问题">一、发现问题</h1><p>在一次系统上线后，我们发现某几个节点在长时间运行后会出现CPU持续飙升的问题，导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐（调度）；如果调度到同样问题的节点上，也会出现Pod一直起不来的问题。我们尝试了杀死Pod后手动调度的办法（label），当然也可以排除调度节点。但是在一段时间后还会复现，我们通过监控系统也排查了这段时间的流量情况，但应该和CPU持续占用没有关联，这时我们意识到这可能是程序的问题。</p>
<h1 id="二排查问题">二、排查问题</h1>
<h2 id="定位pod">定位Pod</h2>
<p>这里使用kubectl top pods 命令确定CPU占用最高的pods都是哪些。</p>
<pre><code class="language-bash">kubectl -n app top pods
</code></pre>
<p><img src="https://mnur-prod-public.oss-cn-beijing.aliyuncs.com/0/tech/%7B585C9C6E-E340-4E98-A0D2-5FB209FEE396%7D_20200410132250.jpg" alt="" loading="lazy"></p>
<p>因为问题已解决，以上图片只是举个例子。</p>
<h2 id="排查工具">排查工具</h2>
<h3 id="arthas">Arthas</h3>
<p>我们这边使用了阿里的Arthas ，它是Alibaba开源的Java诊断工具。当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：</p>
<p>这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？</p>
<p>我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？</p>
<p>遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？</p>
<p>线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！</p>
<p>是否有一个全局视角来查看系统的运行状况？</p>
<p>有什么办法可以监控到JVM的实时运行状态？</p>
<p>怎么快速定位应用的热点，生成火焰图？</p>
<h2 id="排查问题">排查问题</h2>
<p>定位到有问题的Pod后,使用kubectl exec进入Pod容器内部：</p>
<pre><code class="language-bash">kubectl -n app exec -it 49a89b2f-73c6-40ac-b6de-c6d0e47ace64-5d489d9c48qwc7t-- /bin/bash
</code></pre>
<p>在容器中下载Arthas</p>
<pre><code class="language-bash">wget https://arthas.gitee.io/arthas-boot.jar
</code></pre>
<p>由于我们打包镜像中只有一个服务，所以一个Pod中也只有一个进程； 这里 1 是指PID。</p>
<pre><code class="language-bash">java -jar arthas-boot.jar 1
</code></pre>
<p><img src="https://mnur-prod-public.oss-cn-beijing.aliyuncs.com/0/tech/%7B57ADB7CD-4302-44DC-8119-1D319FBF8D4B%7D_20200410133527.jpg" alt="" loading="lazy"></p>
<p>执行进程看板 dashboard：</p>
<pre><code class="language-bash">$ dashboard
</code></pre>
<p>这里上半区显示了线程内容，我们可以看到哪个线程ID的对应情况：</p>
<p><img src="https://mnur-prod-public.oss-cn-beijing.aliyuncs.com/0/tech/5645015E-C7C1-42D6-A050-BE8811AD9577.png" alt="" loading="lazy"></p>
<p>比如从上面得到了线程ID，使用如下命令进入线程，如ID 12262：</p>
<pre><code class="language-bash">$ thread -n 12262
</code></pre>
<p>打印出线程日志：</p>
<pre><code>$ thread -n 12262
"com.alibaba.nacos.client.Worker.addr-bj-internal.edas.aliyun.com-7362814c-538b-4c26-aa07-1fd47765a145" Id=20190 cpuUsage=7% TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@d30d0a4e (in native)
at sun.misc.Unsafe.park(Native Method)
-waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@d30d0a4e
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:813)
</code></pre>
<h1 id="三解决问题">三、解决问题</h1>
<p>经过了排查定位到了问题，最后经过社区和阿里云伙伴的协助，发现了这个是Nacos 2.0.0.RELEASE的一个BUG。我们对Nacos客户端版本进行了升级，经过测试后，问题解决了。也加深了对Kubernetes集群调试的能力 [加油]。</p>
<pre><code class="language-xml"><dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>2.0.1.RELEASE</version>
</dependency>
</code></pre>
<h1 id="四最后">四、最后</h1>
<p>通过社区和阿里云的帮助，问题成功解决。在工具方面，阿里提供的Arthas，真的是线上环境调试神器！</p>
</div>
<div id="MySignature" role="contentinfo">
<div class="esa-post-signature">
<p>作者：
YOYOFx
</p>
<p>出处：https://www.cnblogs.com/maxzhang1985/p/12673160.html</p>
<p>版权：本文采用「署名-非商业性使用-相同方式共享 4.0 国际」知识共享许可协议进行许可。</p>
<p></p>
</div>
<b>欢迎大家关注微信号。扫下面的二维码或者收藏下面的二维码关注吧（长按下面的二维码图片、并选择识别图中的二维码）</b>
<img src="https://images.cnblogs.com/cnblogs_com/maxzhang1985/366082/o_200511090003qrcode_for_gh_58872286e96b_860.jpg" alt="微信公众平台" style="max-width:300px;max-height:300px"><br><br>
来源：https://www.cnblogs.com/maxzhang1985/p/12673160.html
頁:
[1]