再一次生產 CPU 高負載排查實踐
前言 前幾日早上打開郵箱收到一封監控報警郵件：某某 ip 服務器 CPU 負載較高，請研發盡快排查解決，發送時間正好是凌晨。 其實早在去年我也處理過類似的問題，並記錄下來：《一次生產 CPU 100% 排查優化實踐》 不過本次問題產生的原因卻和上次不太一樣，大家可以接着往下看。 問題 ...
原文：記一次生產環境docker服務CPU飆高排查
今天早上，運維同學發現生產某個服務 CPU 持續飆高，於是開始進行排查： 首先使用 top 命令，查看 CPU 占用高的進程，得到進程 ID 根據上一步找到的進程ID，ps ef grep 進程ID 找到對應程序 進入程序對應docker容器 docker exec iter 容器ID bin bash 容器內部使用 top 命令，查看CPU占用高的進程，得到進程 ID 根據上一步找到的進程ID， ...
2021-12-24 17:25 0 1148 推薦指數：
相關推薦
一次生產 CPU 100% 排查優化實踐
前言 到了年底果然都不太平，最近又收到了運維報警：表示有些服務器負載非常高，讓我們定位問題。 還真是想什么來什么，前些天還故意把某些服務器的負載提高（沒錯，老板讓我寫個 BUG！），不過還好是不同的環境互相沒有影響。 定位問題 拿到問題后首先去服務器上看了看，發現運行 ...
記一次JAVA進程導致Kubernetes節點CPU飆高的排查與解決
一、發現問題 在一次系統上線后，我們發現某幾個節點在長時間運行后會出現CPU持續飆升的問題，導致的結果就是Kubernetes集群的這個節點會把所在的Pod進行驅逐（調度）；如果調度到同樣問題的節點上，也會出現Pod一直起不來的問題。我們嘗試了殺死Pod后手動調度的辦法（label ...
生產環境碰到系統CPU飆高和頻繁GC，你要怎么排查？
處理過線上問題的同學基本上都會遇到系統突然運行緩慢，CPU 100%，以及Full GC次數過多的問題。當然，這些問題的最終導致的直觀現象就是系統運行緩慢，並且有大量的報警。本文主要針對系統運行緩慢這一問題，提供該問題的排查思路，從而定位出問題的代碼點，進而提供解決該問題的思路。對於線上系統突然 ...
一次FGC導致CPU飆高的排查過程
今天測試團隊反饋說，服務A的響應很慢，我在想，測試環境也會慢？於是我自己用postman請求了一下接口，真的很慢，竟然要2s左右，正常就50ms左右的。 於是去測試服務器看了一下，發現服務器負載很高，並且該服務A占了很高的cpu。先用top命令，看了load average，發現 ...
記一次服務器高CPU的排查思路
現象 排查思路 另一台服務器CPU正常，由於消息中心有部分老接口是域名調用的，網關已做負載均衡，並且pinpoint上的兩台服務器gc如圖，初步猜測是否是負載不均衡導致。 經運維調試nginx權重無效，證明與負載均衡無關。那么先看子線程，這種情況 ...
記一次排查CPU高的問題
背景 將log4j.xml的日志級別從error調整為info后,進行壓測發現CPU占用很高達到了90%多(之前也就是50%,60%的樣子). 問題排查 排查思路: 看進程中的線程到底執行的是什么,導致CPU占用較高. 1. 使用top命令查看到底是哪個應用 ...