起因：發現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為第二步獲取 ...