今天寫了一段垃圾代碼,然后上服務器上運行,cpu瞬間飆到了100%,現記錄一下問題排除過程~ 1. 問題代碼 2. top 3. 查找問題 3.1 top -Hp 18571, 找出最耗cpu的線程,結果發現18584是就耗了99.9 ...
發現應用記錄日志內,出現網絡訪問延遲較大的情況。 此類問題較為常見,特別是之前參與輔助一個朋友項目運維的過程中,經常因為網絡訪問延遲較大,朋友認為是遭到了ddos攻擊或者是cc攻擊。網絡訪問延遲較大常常會給頂層業務帶來損失,甚至嚴重影響用戶體驗。 遇到這類問題,首先根據OSI七層模型,從上到下,盡可能脫離更加高層的協議帶來的影響。一般說來,稍微有經驗的人都會采用ping的方式,通過探尋icmp是否 ...
2019-06-28 22:24 0 505 推薦指數:
今天寫了一段垃圾代碼,然后上服務器上運行,cpu瞬間飆到了100%,現記錄一下問題排除過程~ 1. 問題代碼 2. top 3. 查找問題 3.1 top -Hp 18571, 找出最耗cpu的線程,結果發現18584是就耗了99.9 ...
服務器突然宕機,領導找了服務器供應商,然后供應商發來一張馬賽克畫質的圖片。說是我們做了什么操作,透過馬賽克,隱約能看到一些 以及一些,供應商說是因為升級操作導致的,但是上面分明是22號升級的,23號宕的機。 全圖(眼差點瞎了) 查看系統日志 所有日志目錄 查看 ...
現象 排查思路 另一台服務器CPU正常,由於消息中心有部分老接口是域名調用的,網關已做負載均衡,並且pinpoint上的兩台服務器gc如圖,初步猜測是否是負載不均衡導致。 經運維調試nginx權重無效,證明與負載均衡無關。那么先看子線程,這種情況 ...
nethogs tcpdump 最近在維護公司線上的服務器,排查了一些問 ...
最近接連聽說一台線上服務器總是不響應客戶端請求。 登錄服務器后查詢iis狀態,發現應用程序池狀態變為已停止。 按經驗想,重啟后應該就ok,第一次遇到也確實起了作用,當時完全沒在意,以為是其他人無意把服務關閉了而已。 但是之后幾天幾乎每天都出現問題,應用程序池再次成為 已停止 狀態。這個情況 ...
基本情況 系統: ubuntu16.04 症狀: who命令可以用,w命令用不了 sudo iotop命令會卡住,黑屏 nvidia-smi命令和nvl命令都用不了,卡住 排查步驟 可以看到,是編號為42943的進程出問題了,卡在I/O上了。 第一想法嘗試kill它,發現 ...
公司報表分析系統已經運行了一年多,最近收到服務器內存警告信息內存耗盡,第一時間着手排查問題,記錄下排查內存耗盡問題整個過程使用到的命令。 第一步查看內存使用情況: free -m 命令:已M單位顯示服務器實際內存使用情況,如圖: 第1行mem數據:total內存總數 ...
不知道為什么,窗外出現了烏雲,又不知道為什么,煩人的蟬鳴突然變得無聲了,大腦中的嘈雜瞬間歸位了寧靜,草他么,我的測試服務器又特么無緣無故的崩了。 作為菜鳥為了排查故障,最先想到的就是找日志,先后分析了項目啟動日志,resin啟動日志,jvm日志完全看不出來結果。 1.jvm日志 ...