1. 程式人生 > >一次cgi服務卡死的問題排查記錄

一次cgi服務卡死的問題排查記錄

問題現象

cgi服務無法處理請求,cpu偶爾飆高。

問題排查記錄

檢視呼叫棧

首先jstack 檢視程序的當前呼叫棧,發現很多執行緒處於Blocked狀態。

jstack pid > stack.txt

檢視gc情況

cpu偶爾飆升,懷疑是gc導致 stop the world,使用jstat查詢gc的頻率

jstat -gcutil pid 1000 100

這裡寫圖片描述

可以發現,系統確實在頻繁發生full gc
各列資料含義:

S0C、S1C、S0U、S1U:Survivor 0/1區容量(Capacity)和使用量(Used)
EC、EU:Eden區容量和使用量
OC、OU:年老代容量和使用量
PC、PU:永久代容量和使用量
YGC、YGT:年輕代GC次數和GC耗時
FGC、FGCT:Full
GC次數和Full GC耗時 GCT:GC總耗時

檢視jvm記憶體佔用情況

那麼來看看為什麼會頻繁發生full gc呢,看看jvm的堆記憶體佔用情況

jmap -heap pid

這裡寫圖片描述

可以看到老年代已經被佔滿。

檢視哪些大物件佔用老年代

jmap -histo:live pid > mem.txt
 num     #instances         #bytes  class name
----------------------------------------------
   1:         62287      235160976  [B
   2
: 801838 190622336 [C 3: 709992 57319760 [Ljava.util.HashMap$Entry; 4: 1411289 33870936 java.util.HashMap$Entry 5: 701725 28069000 java.util.HashMap 6: 820113 19682712 java.lang.String 7: 671624 16118976 java.util.concurrent
.ConcurrentHashMap$HashEntry 8: 839857 13437712 java.lang.Long 9: 131073 12582968 [Lkilim.State; 10: 499133 11979192 com.tencent.jungle.now.service.LogicService$LiveCodeInfo 11: 151632 9508968 [Ljava.lang.Object; 12: 74775 9299256 <constMethodKlass>

可以大概看到這些物件的大小,可以看到位元組陣列是230M,字元陣列是190M,HashMap型別物件是57M。
我們可以注意到一個LogicService 和業務物件相關,可以進一步猜測了。

dump記憶體

jmap -dump:live,format=b,file=dump.hprof pid

可能掛載不上程序,使用root許可權即可。

jprofile分析記憶體

使用jprofile載入上面dump下來的記憶體檔案,可以清晰的看到下面的資料:
可以很明顯的看到LogicService裡面有一個LRU的cache以及DataService下面有一個快取,佔用了較大的記憶體空間,長期佔有不釋放,就會導致記憶體不夠用,從而頻繁gc了。
這裡寫圖片描述

所以這裡有兩種解決方案:
* 程式碼裡限制快取的大小,比如快取的個數或者過期時間等;
* 調整java程序啟動的堆記憶體大小。

tomcat調整引數

在setenv.sh中新增引數即可。這裡設定Xmx為4096.
在測試環境中設定ok,但是到現網啟動會報錯:

java.net.connectexception connection refused 

調整大小為3072就ok。 猜測現網伺服器上的java版本是32位的,允許的最大堆大小應該是小於4G的。
檢視java的版本資訊 && file java檢視java的位數資訊:

[root@Tencent-SNG /data/home/ewanzhao]# java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)

可以使用命令檢視java允許設定的最大堆的大小:

[[email protected] /data/home/ewanzhao]# java -Xmx3687M -version 
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

參考文章

相關推薦

cgi服務卡的問題排查記錄

問題現象 cgi服務無法處理請求,cpu偶爾飆高。 問題排查記錄 檢視呼叫棧 首先jstack 檢視程序的當前呼叫棧,發現很多執行緒處於Blocked狀態。 jstack pid > stack.txt 檢視gc情況 cpu偶

核心 crash 的排查記錄

# 一次核心 crash 的排查記錄 使用的發行版本是 CentOS,核心版本是 `3.10.0`,在正常執行的情況下核心發生了崩潰,還好有 vmcore 生成。 ## 準備排查環境 1. crash 2. 核心除錯資訊rpm,下載的兩個 rpm 版本必須和核心版本一致 - kernel-deb

記錄抽獎超發排查問題過程

緩存控制 緩存 騰訊雲 領導 通過 redis 不知道 服務 更新 接到運營方提出的bug,說是移動端優惠券超發,通過拉取線上數據,確實存在超發現象,而且恰好是設定的兩倍。 通過在測試和仿真環境新建一個活動頁面添加優惠券進行測試,又不會出現超發現象,想到

網站性能排查實錄

linux性能調整 排查 接到一個求助電話,說是有個阿裏雲上的服務器,有性能瓶頸,但又沒有什麽具體的數據,只是說偶爾客戶端有少數連接不上,或者連接會突然中斷。我的天,最怕這種狀況了,還得自己去找問題表現是什麽,再去找什麽原因所致。----懶人可直接點此處,不必辛苦看文字因為是線上的環境,得分兩步進行。

Tomcat運行失敗記錄

路徑 AR ever logs server _for inf 配置文件 本地 記一次Tomcat運行失敗記錄 如圖tomcat運行之後會出現這樣的情況,在網上百度之後大部分都說的是web.xml或者其他配置文件的問題,但是根據網上修改了之後卻還是老樣子。 這裏有比

重裝CM的坑爹記錄

nbsp manifest 每次 創建 信息 nts 多余 end ood 今天同事要對測試環境進行降級(測試高於生產所以要求降級),自己不經常搞運維,但是無奈測試環境沒運維管理只能自己上了。 流程和遇到問題按數字表示。 1.重裝CM(clouder manager)這個過

多資料來源 配置問題記錄

  現在的專案是個多資料來源的配置,前兩天 做專案遷移,要把另一個專案遷移到api的專案裡面。於是 貼上複製後,發現不能執行。。。 最後發現是多資料來源配置出了問題。      <?xml version="1.0" encoding="UTF-8"?

快取效能問題排查

概述 以下分享的都跳過了很多坑,包括redis、tomcat環境配置、機器硬體配置等等問題(與線上保持一致,或者硬體效能減配係數,例如線上:8C16G,壓測:4C8G,係數簡單相差2倍),直接把挖掘瓶頸的主要思路搬出檯面。 壓測資料分析 全域性圖預覽    

對Soul 安卓App的 api請求 抓取記錄

之前註冊玩過一段時間的社交app--soul,發現其沒有網頁版也沒有桌面版,app裡也沒有相關的資料匯出功能,作為一個老使用者,很多日常釋出的瞬間很想匯出來,作為紀念,所以就想看看能不能指令碼抓取我的資料,才有了下面的記錄: 一.對soul抓包 分析Soul App

MySQL-記備份失敗的排查過程

          山竹來臨,窩在家裡整理個人文件。        本篇文章主要講解排查問題的思路,涉及linux 刪除檔案的原理、例項誤刪資料恢復、MySQL例項初始化引數優先級別等,雖然涉及知識點比較淺,但是個人覺得挺有意思的,所以翻出筆記釋出出來。  1 備份出錯咯

線上mysql鎖分析

一、現象 發運車次呼叫發車介面時發生異常,後臺丟擲資料庫死鎖日誌。   二、原因分析   通過日誌可以看出事務T1等待 heap no 8的行鎖 (X locks 排他鎖)                 事務T2持有heap no 8的行鎖,等待heap no 7的行鎖 兩個更新運

無線網路故障排查

使用者發來郵件說XX樓4樓無線斷網,使用者能連上無線,可是不能上網,部分使用者能上網不過也不太穩定。由於休假,不能出現場,只能遠端連上去看看到底發生了什麼。以下是故障排除過程,僅供參考:1、telnet到AP連線的交換機上,通過show logg檢視系統日誌,發現有5個連線AP的接口出現up、down的現象,

Java 記憶體洩漏排查過程,漲姿勢

人人都會犯錯,但一些錯誤是如此的荒謬,我想不通怎麼會有人犯這種錯誤。更沒想到的是,這種事竟發生在了我們身上。當然,這種東西只有事後才能發現真相。接下來,我將講述一系列最近在我們一個應用上犯過的這種錯誤。最有意思的是,一開始的跡象揭示的問題,與實際發生的問題完全不同。 在一個淒涼的午夜 午夜剛過,我就被一條

oracle sql插入多條記錄

假如我有一個學生資訊表,建立的表結構如下: create table student( id int primary key not null, name varchar(10) not null) 熟悉MySQL資料庫的可能知道,如果你想要批量插入一些資料,一條INSER

線上問題的排查過程

問題描述 前不久運維在例行釋出線上CS系統的時候,發現在服務啟動的過程中,後臺一直在報如下錯誤,同時導致使用者頁面訪問異常 2017-10-10 18:28:51,077 [ERROR] org.springframework.amqp.rabbit.l

CMS GC問題排查過程(理解原理+讀懂GC日誌)

這個是之前處理過的一個線上問題,處理過程斷斷續續,經歷了兩週多的時間,中間各種嘗試,總結如下。這篇文章分三部分: 1、問題的場景和處理過程;2、GC的一些理論東西;3、看懂GC的日誌 先說一下問題吧 問題場景:線上機器在半夜會推送一個700M左右的資料,這個時候有個資料置換

jVM效能調優記錄

前言 填別人留下來的坑其實挺無奈的,會被搞的特別煩,特別是我這種要填三四個人留下來的坑的時候,滿滿的都是無奈。 幸好的是填坑也可以選擇一種更能提升自己的方式來填。 這次遇到的一個程式,是一個從kafka消費並且插入mysql的程式,該程式歷經三人之手,頻頻

從Kafka的broker假介紹Kafka架構和DefaultPartitioner

最近公司的kafka叢集出現了節點已經失效但是節點程序和埠都還在的情況,目前我們的系統監控只是做到了程序監控,即為整個叢集的每臺機群建立程序快照,如果程序(如NameNode、kakfa broker)丟失,則報警並立刻自動重啟程序。但是這次的kafka事故程序

【原】【BG】-虛擬化環境實踐簡要記錄

部分涉及到Linux、Nginx、tomcat、MySQL等的點滴操作記錄,時間長了,就忘掉了,偶爾整理一下操作的history,就此簡要備份一下: SQL相關: 前幾天,搞了一臺PowerEdge R720機架伺服器,在上面搭建了一套虛擬化環境,將一臺

查詢sqlserver鎖的經歷

查詢bug是程式設計師的家常便飯,我身邊的人喜歡讓使用者來重現問題。當然他們也會從正式伺服器上下載錯誤log,然後嘗試分析log,不過當錯誤不是那種不經思考就可識別的情況,他們就會將問題推向使用者,甚至怪罪程式依賴的平臺。他們常用的藉口就是“這個問題很難重現,需要持續監控