一次FGC導致CPU飆高的排查過程
今天測試團隊反饋說，服務A的響應很慢，我在想，測試環境也會慢？於是我自己用postman請求了一下接口，真的很慢，竟然要2s左右，正常就50ms左右的。 於是去測試服務器看了一下，發現服務器負載很高，並且該服務A占了很高的cpu。先用top命令，看了load average，發現 ...
原文：TPS低，CPU高--記一次storm壓測問題排查過程
一 業務背景 系統架構 本次場景為kafka storm redis hbase，通過kafka的數據，進入storm的spout組件接收，轉由storm的Bolt節點進行業務邏輯處理，最后再推送進kafka。 表數據相關的邏輯為：查詢Hbase表數據，首次查詢會寫入redis和storm cache，再次查詢，會直接從redis或cache中取值。 storm應用： 二 性能測試場景 .數據： ...
2018-01-24 15:51 0 1857 推薦指數：
相關推薦
記一次慢sql問題排查過程
背景說明 組織架構被拆分為多個微服務 需求： 一個輸入框 查詢 前后模糊查詢 人員信息（工號、姓名），前后模糊查詢 單位名稱。 跨庫平級查詢！！ ...
記一次排查CPU高的問題
背景 將log4j.xml的日志級別從error調整為info后,進行壓測發現CPU占用很高達到了90%多(之前也就是50%,60%的樣子). 問題排查 排查思路: 看進程中的線程到底執行的是什么,導致CPU占用較高. 1. 使用top命令查看到底是哪個應用 ...
記一次OOM問題排查過程
上周運維反饋線上程序出現了OOM，程序日志中的輸出為 看線程名稱應該是tomcat的nio工作線程，線程在處理程序的時候因為無法在堆中分配更多內存出現了OOM，幸好JVM啟動參數配置了-XX:+ ...
記一次線上內存泄漏問題的排查過程
近期需要對公司的接口做線上的巡查監控，需要寫一個腳本放到服務器上，定時運行腳本監測線上接口是否正常。測試的接口不是HTTP協議，而是公司基於TCP協議開發的私有協議，因此不能直接用現成的一些接口測試工 ...
記一次線上崩潰問題的排查過程
大家好，我是雨樂！ 前幾天，突然收到報警，線上服務崩潰，然后自動重啟。 由於正值雙十一期間，業務以穩定為主，線上服務崩潰，這可不是一件小事，趕緊登陸線上服務器，分析原因，迅速解決。 借助這篇文章，記錄下整個崩潰的分析和解決過程。 收到報警 上午上班后，正在划水，突然收到郵件報警 ...
一次死鎖導致CPU異常飄高的整個故障排查過程
目錄 一、問題詳情 top 命令截圖 聯系騰訊雲排查 檢查系統日志發現異常 二、 問題解析 三、問題原因 最終結論 四、擴展 進程的幾種狀態 馬后炮 ...
記一次容器CPU高占用問題排查
起因：發現docker中有兩個容器的CPU持續在百分之95以上運行了一晚上 執行命令：docker stats 發現這個兩個大兄弟一點沒歇滿負荷跑了一晚上，再這么下去怕不是要GG 容器里跑的是JAVA應用，JDK版本1.8 首先進入容器內部：docker exec -it 容器ID /bin ...