1. 程式人生 > >記一次問題排查的過程-伺服器記憶體問題

記一次問題排查的過程-伺服器記憶體問題

記一次問題排查伺服器記憶體問題

背景

工作中突然發現伺服器的記憶體使用率特別高,這是不正常的,帶著疑問,想一探究竟,下面是排查的過程。

第一步

首先使用top命令,free -h命令檢視記憶體使用情況和cpu使用的情況,發現有個應用記憶體使用率異常的高,如下圖,根據記憶體佔比,找到對應行的pid,使用下面的命令根據pid找到自己的應用

ps-ef|grep #pid#

這裡寫圖片描述

第二步

既然已經拿到了我們可以dump堆的檔案出來進行分析了,這個命令執行,JVM會將整個heap的資訊dump寫入到一個檔案,heap如果比較大的話,就會導致這個過程比較耗時,並且執行的過程中為了保證dump的資訊是可靠的,所以會暫停應用,謹慎使用


命令如下:

jmap -dump:format=b,file="/opt/snapshot/"$PID".hprof" $PID  

第三步

使用java的記憶體分析工具memory analyzer(下載地址:https://www.eclipse.org/mat/)開始分析dump的檔案,下圖便是分析工具出的報告,通過報告可以看出,Google的快取貌似有些問題,該物件記憶體已經佔用了505M了,佔虛擬機器heap總量的76.88%,帶著這些現象我們進行下一步
這裡寫圖片描述

第四步

既然已經看到了具體的類有問題,那麼下面開始定位程式碼。通過分析類中使用快取的地方,發現快取設定的時間過長,並且存的物件很大,長時間不回收,造成伺服器記憶體壓力很大,通過改變快取策略(減少快取時間,減少存入的物件數量,設定上限),問題便迎刃而解。

總結

伺服器線上應用難免會出現各種問題,只要細心排查,耐心找原因,一步一步總會把問題的根源揪出來,通過這次的排查,發現快取的使用方式不合適,這對自己以後正確合理使用快取敲響警鐘,能用分散式快取就儘量不要採用類似guava,map這種本地快取,當然真的有場景特別需要本地快取,只要能忍受得了記憶體的消耗也可以。對於引數比較少且變化很少的介面建議使用cdn快取,能夠得到提高服務的響應速度。

相關推薦

排查線上程式記憶體的忽高忽低,又是大集合惹禍了

## 一:背景 ### 1. 講故事 昨天繼續還技術債,優化一輪後的程式拉到線上後記憶體繼續忽高忽低,低的時候20G,高的時候30G,過了一會又下降了幾個G,毫無疑問,程式中有什麼集合或者什麼操作佔用了大量記憶體,所以準備在28,29G的時候抓dump分析分析。 ## 二:解決思路 從快照中找

Dubbo導致的記憶體洩漏過程分析及解決

       近日測試團隊反饋版本機測試環境請求經常卡頓,十分緩慢,甚至有超時的情況,但是請求返回、業務邏輯均是正常的,因此進行了一番排查。         首先檢視應用日誌,及控制檯監控,應用均表現無異常,由於版本

排查線上full gc過程

序最近頻繁收到線上報警,就看看到底啥原因二 匯出dump檔案2.1 查詢報警對應的程序ps -ef|grep XX是23898,看一下gc情況:這才不到半小時,fgc就增加了好幾次。jmap匯出dump。jmap -dump:format=b,file=salary1 238

排查Java專案記憶體洩漏的過程

發現問題 公司自己維護的服務三四個,有的服務還分多個節點,自己也有幾個私人伺服器,所以為了能實時知道各個伺服器的情況,就使用ServerStatus做了個雲探針,功能很簡單,能實時的監控每個伺服器的記憶體、cpu、硬碟、流量的使用情況,如下 雖然只有幾個

處理linux伺服器cpu跑滿的問題

記一次處理linux伺服器cpu跑滿的問題 公司伺服器,突然掛掉了,登入阿里雲後臺才發現,是阿里雲把我們的伺服器給關停了,提示有對外攻擊,使用top命令檢視後發現Cpu(s) us顯示98%多,但是看程序發現,並沒有佔用很多加起來也不過就10%左右。然後就給阿里雲發工單尋求幫助,因為我壓根就

Minecraft遊戲伺服器搭建實踐經歷

Minecraft簡介 Minecraft是一款沙盒遊戲,整個遊戲沒有劇情,玩家在遊戲中自由建設和破壞,透過像積木一樣來對元素進行組合與拼湊,輕而易舉的就能製作出小木屋、城堡甚至城市,玩家可以通過自己創造的作品來體驗上帝一般的感覺。在這款遊戲裡,不僅可以單人娛樂,還可以多人聯機,玩家也可以安裝一些模組來增加

在公司伺服器上安裝fastdfs的歷程

1.確保已安裝了gcc,unzip(基本工具) 2.安裝libfastcommon-master 步驟: unzip libfastcommon-master.zip cd libfastcommon-master ./make.sh ./make.sh install

阿里雲伺服器執行慢排除

公司測試環境用的阿里雲伺服器+docker部署的,一共跑了14個專案。之前幾個月一直OK,最近幾天突然很卡很慢。剛開始以為是專案問題,又是擴大記憶體,又是清減外掛,甚至停了一半專案。結果CPU是下來了,但是構建、啟動、訪問還是很慢,各種百度、google、群裡問都沒能找到原因,最後提了個工單說明情況。 回覆說

學習hadoop遇到的問題(阿里雲伺服器被惡意掛木馬,CPU100%)

在我剛開始學習時,把防火牆,安全組都開放了,過了一段時間被掛上了木馬。並且殺死程序一會還啟動 解決辦法 1通過命令netstat -antlp|grep 9002檢視埠檔案地址,刪除可以檔案(java資料夾) 2.還得在安全組中關閉hadoop一些對外開放的web頁面(可以改變埠號)

解Bug之路——JVM堆外記憶體洩露Bug的查詢

前言JVM的堆外記憶體洩露的定位一直是個比較棘手的問題。此次的Bug查詢從堆內記憶體的洩露反推出堆外記憶體,同時對實體記憶體的使用做了定量的分析,從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成部落格,以饗讀者。由於實體記憶體定量分析部分用到了linux kernel虛擬

搭建ftp伺服器

今天早上剛到公司,老大給了個任務,需要在阿里雲上搭建一臺Ftp伺服器。接到任務的時候,心裡想著,一臺ftp伺服器而已,上學期間就有搭過了~ so easy ~。But … 因為搭建的環境不一樣,還是遇到了一些坑,最後還是順利解決了。下面整理一下思路~ 環境介紹: 作業系統: Linux

阿里雲伺服器遷移

今天凌晨兩點 伺服器定時遷移了遷移之前 先把開機自啟動修改了一下 發現memcached沒有開機自啟動新增方式vim /etc/rc.d/rc.local增加一行/data/website/xunsearch/bin/xs-ctl.sh restart /usr/local/

排查mbstowcs誤用引發的bug

問題程式碼如下: #define MAX_LINE_LEN (10240*2) char tieziLine[MAX_LINE_LEN]; wchar_t oneTieziLine_wchar[MAX_LINE_LEN];

解Bug之路-JVM堆外記憶體洩露Bug的查詢

# 解Bug之路-記一次JVM堆外記憶體洩露Bug的查詢 ## 前言 JVM的堆外記憶體洩露的定位一直是個比較棘手的問題。此次的Bug查詢從堆內記憶體的洩露反推出堆外記憶體,同時對實體記憶體的使用做了定量的分析,從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成部落格,以饗讀者。 由於實體記憶體定量分

問題排查過程-伺服器記憶體問題

記一次問題排查伺服器記憶體問題 背景 工作中突然發現伺服器的記憶體使用率特別高,這是不正常的,帶著疑問,想一探究竟,下面是排查的過程。 第一步 首先使用top命令,free -h命令檢視記憶體使用情況和cpu使用的情況,發現有個應用記憶體使用

Spring Websocket後臺伺服器CPU佔用率過高的問題排查過程

背景 最近在做Spring Websocket後臺程式的壓力測試,但是當併發數目在10個左右時,伺服器的CPU使用率一直在160%+,出現這個問題後,一開始很納悶,雖然伺服器配置很低,但也不至於只有10個併發吧。。伺服器的主要配置如下: CPU:2核 In

使用windbg排查記憶體洩漏的過程

一、背景   近期有一個專案在運行當中出現一些問題,程式順利啟動,但是觀察一陣子後發現記憶體使用總量在很緩慢地升高, 雖然偶爾還會往下降一些,但是總體還是不斷上升;記憶體執行6個小時候從33M上升到80M;   程式存在記憶體洩漏是確定無疑的了,大概出問題的方向也知道,就是程式新加入一個採集協議(BACnet

記憶體溢位問題的排查、分析過程及解決思路

謹以此文獻給自學路上的兄弟 起因 這個測試工具的開發已有一段時間了,由於資料量過大,寫入資料較慢,導致工具執行耗時較長,所以再次優化了實現方案,進行二階段的程式開發。 經優化後,2000 條資料寫入,耗時4秒,個人感覺,快了很多了。 於是,想批量執行下,看下耗時多長。 結果10分鐘、20分鐘、1 個小時過

TPS低,CPU高--storm壓測問題排查過程

進入 狀態 其他 value 由於 均衡 線程狀態 左右 grep 命令 一、業務背景+系統架構 本次場景為kafka+storm+redis+hbase,通過kafka的數據,進入storm的spout組件接收,轉由storm的Bolt節點進行業務邏輯處

Xmrig挖礦木馬排查過程

linux 系統 異常 定位 計劃任務 root systemctl ica 文件名 發現 問題現象 Linux 服務器收到報警信息,主機 CPU 跑滿。 自動創建運行 Docker 容器 xmrig, 導致其他運行中容器被迫停止。 問題原因 通過 to