docker 运行中的容器CPU 莫名其妙使用率升高过百,解决 :Unable to open socket file:

服务器CPU莫名其妙升高。。。

通过监控工具查看。CPU达到 733%。。。。

 

于是,查找众多资料,发现。

步骤都差不多。。

1、进入容器,查看 进程号

top

结果如下:看到排第一的进程,拿到pid

复制代码
Tasks: 151 total,   1 running, 150 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.5 us,  1.6 sy,  0.0 ni, 80.2 id,  0.0 wa,  0.0 hi,  0.8 si,  0.0 st
KiB Mem : 16265568 total,   182552 free, 12032964 used,  4050052 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3893084 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                                                 
25970 root      20   0 8803864   3.1g  13892 S 120.0 19.7  60:57.15 java                                                                                                                                                                    
15188 root      20   0 4630448   3.1g   9204 S  40.0 19.8 671:05.97 java                                                                                                                                                                    
 1082 root      20   0 1385500  79148   8740 S   6.7  0.5  61:47.84 dockerd                                                                                                                                                                 
    1 root      20   0   43600   3728   2388 S   0.0  0.0   0:03.42 systemd                                                                                                                                                                 
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd 
复制代码

 

 

2、使用top -H -p 进程号查看异常线程、查看线程

top -H -p 25970

得到如下结果:

复制代码
top - 13:07:01 up 2 days, 19:38,  6 users,  load average: 1.87, 1.67, 1.60
Threads: 252 total,   1 running, 251 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.8 us,  1.3 sy,  0.0 ni, 79.2 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
KiB Mem : 16265568 total,   168684 free, 12043804 used,  4053080 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3882576 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                                                                  
26246 root      20   0 8821340   3.1g  13892 R 99.9 19.7  48:16.31 java                                                                                                                                                                     
26105 root      20   0 8821340   3.1g  13892 S  0.7 19.7   0:10.20 java                                                                                                                                                                     
26243 root      20   0 8821340   3.1g  13892 S  0.7 19.7   0:07.85 java                                                                                                                                                                     
26252 root      20   0 8821340   3.1g  13892 S  0.7 19.7   0:07.80 java   
复制代码

 

 

3、使用printf "%x\n" 线程号将异常线程号转化为16进制

printf "%x\n" 26246

得到如下结果

[root@iZwz97bb75hzl6vsvx8xb9Z ~]# printf "%x\n" 26246
6686

 

 

4、使用jstack 进程号|grep 16进制异常线程号 -A90来定位异常代码的位置(最后的-A90是日志行数,也可以输出为文本文件或使用其他数字)。可以看到异常代码的位置。

jstack 25970|grep 6686 -A90

得到如下结果:提示:说明本机查看docker容器的线程失败。

[root@iZwz97bb75hzl6vsvx8xb9Z ~]# jstack 25970|grep 6686 -A90
25970: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

 

总结:不行呀。因为这是docker的容器,在外部无法接入。而在容器内无法处理。因为依赖基础镜像的阉割精简版。

所以修改依赖基础镜像为完整版。

#FROM openjdk:8-jre-alpine
FROM java:8
.......

 

而且需要进入到容器内,才可以操作。于是打包,发布,重复以上步骤。。

解决:

docker exec -it my-server bash

重复以上的各步骤

然后。

printf "%x\n" 136
88
jstack 8|grep 88 -A90 >/home/soft/881.log
等待15s
jstack 8|grep 88 -A90 >/home/soft/882.log 
等待15s
jstack
8|grep 88 -A90 >/home/soft/883.log

 

将结果导出到宿主机

退出容器,

exit

docker cp my-server:/tmp/soft .

 

最终通过查看快照881,882,883

查找内容中的 自己的程序代码,并且在状态为RUNNABLE中的记录。最终。找到死循环程序

 java.lang.Thread.State: RUNNABLE

 

修复问题,重新发布,问题解决。

 

posted on   陈惟鲜的博客  阅读(4308)  评论(0编辑  收藏  举报

编辑推荐:
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器
历史上的今天:
2014-10-17 js替换文本内容。实例

导航

< 2025年2月 >
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 1
2 3 4 5 6 7 8
点击右上角即可分享
微信分享提示