部署elasticsearch服務，主要提供記錄使用者登入日誌、訪問日誌，統計，查詢等功能。
遇到的問題為：
cpu使用率激增到60%左右，最高值到達90%，伺服器監控系統開始報警。
elasticsearch是基於j**a開發的，先檢視elasticsearch程序的運**況，然後檢視jvm相關引數。生產環境問題已解決（部分問題暫時無法提供截圖說明）
使用jstat -gcutil pid 1000 命令檢視垃圾**情況
可知每兩秒進行一次minor gc,定位問題為頻繁的minor gc 引起的cpu使用率居高不下。
1.確定垃圾**器的使用
生產環境使用jdk版本為jdk11,jvm.options檔案中相關引數表明
在jdk8-13預設使用的垃圾**演算法為cms,因為cms為老年代垃圾收集器，預設與之配合使用的新生代垃圾**器為parnew。
使用jps命令找到es執行的程序id
使用jinfo命令 檢視jvm的相關引數，確認使用的垃圾**器為parnew+cms。
2.檢視heap大小分配情況
伺服器記憶體為16g,根據官方推薦heap大小配置不宜超過8g
jvm.options配置引數為
-xmx7g
-xms7g
沒有顯示宣告新生代的大小，cms垃圾**器新生代預設大小為：
max_heap/(newratio+1)和scaleforwordsize(young_gen_per_worker * parallel_gc_threads) 中最小的值。
max_heap/(newratio+1) 即最大堆記憶體/(2+1) （未顯式設定引數newratio 則預設為2) 7*1024/3=2389.33m
scaleforwordsize(young_gen_per_worker * parallel_gc_threads) 計算公式為 young_gen_per_worker * parallel_gc_threads * 13/10
young_gen_per_worker 的值x86機器為64m，parallel_gc_threads簡單的理解為cpu核數8 64*8*13/10=665m
即最後的新生代大小為665m
使用jstat -gc 檢視記憶體分配情況 新生代為665m，
預設引數-xx:survivorratio=8 即eden:s0:s1=8:1:1 可知eden記憶體大小為532m
可知新生代記憶體設定太小，eden區滿了之後會進行頻繁的minor gc導致cpu佔用率提高
1.顯式設定引數-xmn 由於老年代占用比例較小，且在minor gc 過程中晉公升到老年代的物件較少，所以可以提高新生代的記憶體佔比設定為-xmn4g
2.改用g1垃圾**器，可在垃圾**過程中根據使用情況動態改變新生代的大小
cms會在垃圾**過程中產生記憶體碎片，不利於程式的長時間執行。
而g1在執行期間不會產生記憶體碎片，有利於程式長時間執行。
綜上所述，從兩個方面來看以及生產環境的試運**況來看，選擇修改垃圾**器為g1的解決方案。
總結，修改垃圾**器為g1後，平穩期cpu使用率穩定在5%以下。
ElasticSearch 引數調優
系統層面的調優主要是記憶體的設定與避免交換記憶體。es 安裝後預設設定的堆記憶體是1gb，這很明顯是不夠的，那麼接下來就會有乙個問題出現 我們要設定多少記憶體給 es 呢？其實這是要看我們集群節點的記憶體大小，還取決於我們是否在伺服器節點上還是否要部署其他服務。那我們在建立索引的時候，應該建立多少個...
ElasticSearch效能調優
介紹 elasticsearch 效能調優的一些常用引數。一塊好的硬碟，會帶來 es 整體效能 10 倍以上提公升，推薦在 datanode 節點上使用 ssd 硬碟，索引的 data 目錄，存放在 ssd 硬碟上。建議記憶體 128g 時，es 使用的 jvm 記憶體為 30g，lucene 會消...
ElasticSearch調優問題
1.近期遇到乙個es記憶體居高不下的問題，查了查，發現es有個fielddata，當你發起乙個查詢，分析字串的聚合將會被載入到 fielddata，如果這些字串之前沒有被載入過。如果結果中 fielddata 大小超過了指定大小，其他的值將會被 從而獲得空間。預設情況下，設定都是 unbounded...