1
z5864703 OP 补充:
1.只要连接数上来就会出现,所以问题和长连接数量相关 2.心跳是 60 秒一次,回应 pong 即可,处理效率不存在瓶颈 |
2
jybox 2019-11-25 17:38:50 +08:00
监控采集的粒度不够?有可能只是极短时间的 CPU 繁忙导致的 load 升高。
|
3
asilin 2019-11-25 17:43:23 +08:00
我猜测是短时间内大量进程 /线程的创建导致的,推荐使用 ganglia 或者 prometheus 监控来看下;
|
4
z5864703 OP @jybox 每秒记录,load 的数值飙升到回落持续时间两分钟,飙升过程 40 秒左右。cpu 没有波动,包括每个核心
|
6
Sasasu 2019-11-25 19:19:16 +08:00
gc 扫描
|
8
dazhangpan 2019-11-25 20:04:23 +08:00
同意#3 楼,不要光看代码,还是得用工具看一下是否有 short-lived 进程,可以参考这篇文章: https://decodezp.github.io/2019/09/19/test20-troubleshoot-short-lived-process/
|
9
z5864703 OP @dazhangpan 看了下,不符合条件。服务器在负载飙升的时候是没有 cpu 占用开销
|
10
capljf 2019-11-26 13:43:07 +08:00
如果确定是业务代码造成的 load 飙升并且是运行 jvm 的话,可以在 load 升起来的时候 dump 一下内存看看
|