這段時間開發環境es新接了乙個平台做測試，結果導致頻繁gc，隔三岔五整個服務就會掛掉。
從最新日誌裡可以看到
eden space使用率98%，這就是服務宕機的原因。
先回顧一下eden space是什麼，為什麼eden space使用率98%的情況下from space, to space使用率這麼低。
從上圖可以看到，jvm中記憶體分割槽可以分為heap區和非heap區域。
heap區域包括：
非heap區域包括：
排查gc問題我們需要關注heap區域。
eden, from, to總體又稱為年輕代，而from, to又組成survivor倖存者區。那麼大體來說jvm堆記憶體的區域劃分為：
一般情況下，新建立的物件都會被分配到eden區(一些大物件特殊處理),這些物件經過第一次minor gc後，如果仍然存活，將會被移到survivor區。物件在survivor區中每熬過一次minor gc，年齡就會增加1歲，當它的年齡增加到一定程度時，就會被移動到年老代中。
在gc開始的時候，物件只會存在於eden區和名為「from」的survivor區，survivor區「to」是空的。緊接著進行gc，eden區中所有存活的物件都會被複製到「to」，而在「from」區中，仍存活的物件會根據他們的年齡值來決定去向。年齡達到一定值(年齡閾值，可以通過-xx:maxtenuringthreshold來設定)的物件會被移動到年老代中，沒有達到閾值的物件會被複製到「to」區域。經過這次gc後，eden區和from區已經被清空。這個時候，「from」和「to」會交換他們的角色，也就是新的「to」就是上次gc前的「from」，新的「from」就是上次gc前的「to」。不管怎樣，都會保證名為to的survivor區域是空的。minor gc會一直重複這樣的過程，直到「to」區被填滿，「to」區被填滿之後，會將所有物件移動到年老代中。
那麼再回到我們的問題上。檢視es jvm配置後發現，已經配置了2g的heapsize，那麼是怎麼分配新生代和老年代的heap大小呢？
通過錯誤日誌可以看到，新生代heapsize僅有150mb左右，那麼這裡只要修改newratio配置即可。
回顧一下這段時間
自從小兒子出生以來，每天睡眠不好，加上年底雜事比較多，好久沒有看專業書籍，也沒有寫部落格了。這是病，得改，任何事情都貴在堅持。最近對專案管理和質量管理進行了一些實操性質的研究，實際就是考慮怎麼把規範 標準 體系的要求落實到具體的日常工作中去。下面是一些老生常談 1 流程要梳理清晰。各項工作用的表單，...
getopt 簡單回顧一下
getopt 解析命令的可選項 說明 getopt只是乙個簡單的解析命令可選項的函式，只能進行簡單的格式命令解析，格式如下 1 形如 cmd a b 對短選項的解析 2 形如 cmd a a argument b b argument 對短選項及短選項的引數解析 3 形如 cmd a a argum...
回顧一下 棧和佇列
下面來回顧一下 資料結構中比較常用的兩種型別 棧和佇列 棧 是乙個特殊的線性表，只能在一端操作，即先進後出 棧頂 允許操作的一端 棧底 不允許操作的一端 空棧 不含任何資料元素的棧，top 1，當棧中有乙個元素時，top 0 一 順序儲存 一般採用迴圈佇列 順序儲存中，我們通常用陣列下標表示結點的位...