起因：发现docker中有两个容器的CPU持续在百分之95以上运行了一晚上 执行命令：docker stats 发现这个两个大兄弟一点没歇满负荷跑了一晚上，再这么下去怕不是要GG 容器里跑的是JAVA应用，JDK版本1.8 首先进入容器内部：docker exec -it 容器ID /bin ...

　　前不久公司进行了一次大促，晚上值班。大促是从晚上8点多开始的，一开始流量慢慢的进来，观察了应用的各项指标，一切都是正常的，因为这是双11过后的第一次大促，想着用户的购买欲应该不会太强，所以我们的运维同事9点多就回家了在家里面远程支持，留下交易组和其它后端的技术值班，楼主就是交易组的。谁知10 ...

现象 排查思路 另一台服务器CPU正常，由于消息中心有部分老接口是域名调用的，网关已做负载均衡，并且pinpoint上的两台服务器gc如图，初步猜测是否是负载不均衡导致。 经运维调试nginx权重无效，证明与负载均衡无关。那么先看子线程，这种情况 ...

一、业务背景+系统架构 本次场景为kafka+storm+redis+hbase，通过kafka的数据，进入storm的spout组件接收，转由storm的Bolt节点进行业务逻 ...

一次线上CPU高的问题排查实践 前言 近期某一天上班一开电脑，就收到了运维警报，有两台服务CPU负载很高，同时收到一线同事反馈 系统访问速度非常慢，几乎无响应。 一个美好的早晨，最怕什么就来什么。只好推掉其他会议，专心搞定问题。 排查 登录系统一看，后端的接口访问果然全部超时 ...

一、发现问题 在一次系统上线后，我们发现某几个节点在长时间运行后会出现CPU持续飙升的问题，导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐（调度）；如果调度到同样问题的节点上，也会出现Pod一直起不来的问题。我们尝试了杀死Pod后手动调度的办法（label ...

今天早上，运维同学发现生产某个服务 CPU 持续飙高，于是开始进行排查： 1、首先使用 top 命令，查看 CPU 占用高的进程，得到进程 ID 　　 2、根据上一步找到的进程ID，ps -ef | grep [进程ID] 找到对应程序 　　 3、进入程序对应docker容器 ...

一、java定位进程 在服务器中终端输入命令：top 可以看到进程ID，为5421的cpu这列100多了。 记下这个数字：5421 二、定位问题进程对应的线程 然后在服务器中终端输入命令：top -Hp 5421 作用是查看里程内部线程资源占用情况。5421为第二步获取 ...