这是一个创建于 1876 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在做服务拆分，把 A 服务中某部分的逻辑抽取到 B 服务，服务间调用采用 http 接口。然后 A 服务出现了 cpu100%的情况。
发现 A 服务消耗 cpu 最高的有 8 个线程，然后用线程 id 从 jstack 导出的 stack 日志中发现全都是 8 个 GC 的线程，且都是 runable 状态，应该不是 GC 出现的问题。
继续在 stack 日志中发现了大量线程处于 BLOCKED，且阻塞的部分都是一些类库的部分，比较的杂乱，暂未找到规律。把抽取之前的代码放到同样的环境，没有发现这个问题。有经验的老哥给我一点思路。下面是 stack 日志的一些截图：
 |
1
90xchun 2019-11-08 14:09:59 +08:00 via iPhone
你还得用下 pidstat 这个能直接找到那个线程占用的 cpu 资源高，猜是徒劳的
|
 |
2
loongwang 2019-11-08 14:14:54 +08:00
发现 A 服务消耗 cpu 最高的有 8 个线程，然后用线程 id 从 jstack 导出的 stack 日志中发现全都是 8 个 GC 的线程，且都是 runable 状态，应该不是 GC 出现的问题。
STW 的时候会 block 所有用户线程. 看起来很有可能是 GC 的问题 |
 |
3
pank OP @loongwang ,但是在抽服务之前没有经过 http 接口调用的时候从来没有发生过这种情况，会不会跟服务间调用的时候频繁的序列化，反序列化对象有关呢
|
|
4
pank OP @90xchun，我用 top -p pid -H 已经找到了消耗 cpu 最高的线程，共有 8 个都是 gc 的线程,业务的线程几乎没有怎么消耗 cpu。这个想不明白。
|
 |
5
0NF09LJPS51k57uH 2019-11-08 14:31:47 +08:00
看起来像死锁了
|
 |
7
sagaxu 2019-11-08 14:34:20 +08:00 via Android
把 gc 日志打出来看看
|
 |
8
kirin 2019-11-08 15:28:53 +08:00
https://www.jianshu.com/u/1e1cd4da105c
可以参考这个排查过程, 看看对你有没有帮助. |
 |
9
choiwanxy 2019-11-08 16:31:44 +08:00
为什么 GC 一直跑呢，要不 dump 一下，看是不是 OOM,看下是不是直动态生成类，加载类导致元空间满了，也会造成 fullGC
|
|
10
choiwanxy 2019-11-08 16:38:52 +08:00
也可以先简单看下堆大小，是不是一直是到了临界值。是的话，当然会一直 GC
|
 |
11
Raymon111111 2019-11-08 16:38:56 +08:00
看一下 gc 相关的指标
|
 |
14
wh520 2019-11-08 17:24:25 +08:00
可以看看是不是 http 调用超时，线程数飙升导致的。
|
|
15
wh520 2019-11-08 17:27:32 +08:00
仔细看了下，不是 GC 的问题，毕竟不是 Full GC,应该是 HTTP 连接的问题，可以仔细看看远程调用策略是否有问题。
|
 |
16
Jrue0011 2019-11-08 17:38:03 +08:00
用 jmap 看看？
|
|
17
pank OP @Jrue0011 ,jmap 导出的 heap 文件有 3.3G ，用 MAT 倒是打开了，一脸懵逼，不会用这东西定位啊😥
|
 |
18
realpg 2019-11-08 18:03:34 +08:00
JAVA 啊 一般我都是淘个 2500 元的 24 线程 96G 内存的物理机跑
|
 |
19
wwwzhujibcom 2019-11-08 18:05:40 +08:00
被 CC 了吗
|
 |
20
snappyone 2019-11-08 19:46:20 +08:00
jstat -gcutil pid 500 10 看下
|
 |
21
dorothyREN 2019-11-08 22:56:25 +08:00
@realpg #18 话说老哥现在还有靠谱点的二手服务器渠道吗
|
|
22
realpg 2019-11-08 23:55:49 +08:00
@dorothyREN #21 万能的淘宝 都是走量的 没有啥不靠谱的
|
 |
23
msg7086 2019-11-09 01:21:11 +08:00
难道是内存吃完了？
|
Select Language