背景
生產環境有二台阿里雲伺服器,均為同一時期購買的,cpu、記憶體、硬碟等配置相同。具體配置如下:
由於這二伺服器硬體和軟體配置相同,並且執行相同的程式,所以在nginx輪詢策略均weight=1,即平台的某個流量由這二台機器平分。
有一次對系統進行例行檢查,使用pinpoint檢視下伺服器」heap usage」的使用情況時,發現在有乙個系統full gc非常頻繁,大約五分鐘一次full gc,嚇我一跳。
這麼頻繁的full gc,導致系統暫停處理業務,對系統的實時可用性大打折扣。
我檢查了一下tomcat(tomcat8.5.28)配置,發現在tomcat沒有作任何關於jvm記憶體的設定,全部使用預設模式。
由於這二伺服器硬體和軟體配置相同,並且執行相同的程式,所以在nginx輪詢策略均weight=1,即平台的某個流量由這二台機器平分。
gc資料
在業務峰期間,通過pinpoint觀察的a、b節點的」heap usage」使用情況,分別進行以下幾個時間段資料。
3小時圖:
上圖b系統在三個小時內,一共發生了22次full gc,大約每8分鐘進行一次full gc。
每次full gc的時間大概有150ms左右,即b系統在三個小時內,大約有3300ms暫停系統執行。
從上圖來看,堆的空間最大值在890m左右,但在堆空間的大小大約200m就發生full gc了,從系統資源的利用角度來考慮,這個使用率太低了。
上圖a系統在3個小時內,一共發生了0次full gc,嗯,就是沒有任何停頓。
在這3小時,系統一直在處理業務,沒有停頓。堆的總空間大約1536m,目前堆的空間大於500m。
6小時圖:
上圖b系統在6個小時的資料統計和3個小時很像,6個小時內一共發生了n次full gc,均是堆的空間小於200m就發生full gc了。
上圖a系統在6個小時內,一共發生了0次full gc,表現優秀。
12小時
上圖b系統在12個小時內,一共發生了n次full gc,左邊full gc比較少,是因為我們的業務主要集中白天,雖然晚上屬於非業務高峰期間,還是有full gc。
上圖a系統在12個小時內,一共發生了0次full gc,表現優秀。
gc日誌
看下gc.log檔案,因為我們兩台伺服器都輸出了gc的詳細日誌,先看下b系統的full gc日誌。
上圖全部是」 [full gc (ergonomics)」日誌,是因為已經去掉」 gc (allocation failure」日誌,這樣更方便觀察和分析日誌。
我們選取gc日誌檔案最後一條full gc日誌。
2018-12-24t15:52:11.402+0800: 447817.937: [full gc (ergonomics) [psyounggen: 480k->0k(20992k)] [paroldgen: 89513k->69918k(89600k)] 89993k->69918k(110592k), [metaspace: 50147k->50147k(1095680k)], 0.1519366 secs] [times: user=0.21 sys=0.00, real=0.15 secs]
可以計算得到以下資訊:
分析:這次full gc是因為老年代物件占用的空間的大小已經超過老年代容量 引發的full gc。
[paroldgen: 89513k->69918k(89600k)]
究其原因,是因為分配給老年代的空間太小,遠遠不能滿足系統對業務的需要。
這導致老年代的空間常常被佔滿,老年代的空間滿了,導致full gc。而由於老年代的空間比較小,所以每次full gc的時間也比較短。
a系統日誌,只有2次full gc,這2次gc均發生在系統啟動時:
7.765: [full gc (metadata gc threshold) [psyounggen: 18010k->0k(458752k)] [paroldgen: 15142k->25311k(1048576k)] 33153k->25311k(1507328k), [metaspace: 34084k->34084k(1081344k)], 0.0843090 secs] [times: user=0.14 sys=0.00, real=0.08 secs]
可以得到以下資訊:
分析:a系統只有系統啟動才出現二次full gc現象,而且是」 metadata gc threshold」引起的,而不是堆空間引起的full gc。
雖然經過乙個星期的觀察,a系統沒有full gc,但一旦發生full gc時間則會比較長。
其它系統曾經發現過,1024m的老年代,full gc持續的時間大約是90ms秒。
所以看得出來推也不是越大越好,或者說在useparalleloldgc收集器中,堆的空間不是越大越好。
分析與優化
總體分析:
優化策略:
一次有驚無險的刪庫經歷
來公司三個月了,資料庫每天都在練習,這幾天我的主管回家了,正好趕上這幾天開新伺服器,我作為乙個剛入門的小白,在一台伺服器上跑起了開服指令碼,由於指令碼上已經寫好了開服的全部指令,我也沒仔細想太多,就將資料庫做了個備份,然後跑起了指令碼當然這個指令碼不是我寫的,跑到一半的時候指令碼突然報錯,我去檢視了...
記一次面試經歷
今早七點半的巴士從中山趕到廣州面試php開發助理,以前面的都是十來人 幾十人的小公司,不少還是培訓公司,坑的一逼!這次的公司不錯,比較正規,好歹上百人了,只是筆試題做得一般,題目有的雖有學過,但忘了,好吧!這就是沒準備充分的緣故!下面羅列下我還記得的題目 有些漏了就沒辦法了 之後hr面試聊了下,雖然...
記一次重構經歷
起因 最近因為公司內部對各個業務線的使用者業務進行統一剝離,形成使用者中心,所有使用者相關的業務和資料都落地到使用者中心,各個業務線以rpc的的形式依賴使用者中心的服務。結果 因為我的疏忽,造成了兩個bug沒有被測試出來。總結改進 這兩個bug的產生的原因都是因為我錯誤地估計了回歸測試的範圍,我的想...