首先，說明筆者的機器環境（不結合環境談解決方案都是耍流氓）: cpu 32核，記憶體128G，非固態硬碟： RAID0 (4T * 6)，單節點，資料量在700G到1800G，索引15億~21億，敖丙大人，在蘑菇街，可多集群分片，固態硬碟，比不起啊，
轉載請注明出處：https://www.cnblogs.com/NaughtyCat/p/elasticsearch-OOM-optimize-story.html
業務場景:
保存7天索引，每天有400G~500G，發現ES時不時的OOM(out of memory)和重啟，當索引超過500G的時候，ES重啟到加載所有分片，時間約30分鐘到1小時，
題外話，ES OOM 會生成 .hprof 檔案，如下圖（作者【CoderBaby】）：
用jhat來分析OOM堆轉儲檔案，具體命令: jhat -port 7401 -J-Xmx4G java_pid19546.hprof
解決辦法：
- 改檔案存盤型別，減少記憶體占用
設定存盤型別為：“hybridfs” ,即： "index.store.type": "hybridfs" （原來為“mmapfs”，詳見附2；另外，ES 5.6應為“fs”，不支持“hybridfs”，最新的7.4版本支持“hybridfs”），mmapfs — index映射到記憶體，niofs — 并發多執行緒以NIO的方式讀取index檔案， hybridfs—混合 mmafs和niofs ,根據讀取模式選擇最佳的檔案系統
效果：在600G左右的索引，5天索引，確實沒有了OOM，但一旦增大到7個索引，就不行了，用jstat命令，即：stat -gcutil 6811 （ES的PID）查看ES的jvm，如下圖：
O: Old space utilization as a percentage of the space's current capacity (老年代空間占用率），O最高達到79，就往下降，原來為存盤型別為“mmapfs”，O很容易就飆到100.
- 不要自己創建檔案ID
ES默認會自動創建檔案Id"(如：_id": "AW8922mK8RqpiZJD9zb2"），如果自己生成Id,則每次存盤新的檔案的時候，ES都會查看整個分片是否已經存在該Id，如果分片存盤有上千萬的檔案，這是一個比較耗時的操作
- 關閉暫時不用的索引，減少打開索引的數量
關閉索引（檔案仍然存在于磁盤，只是釋放掉記憶體，需要的時候可重新打開），設定打開索引引數： "__es.maxPermanentlyOpenIndices":4 （最大打開索引：7改為4），
- 擴大堆記憶體
設定堆大小，從15G提高到30G，即： -Xms30g -Xmx30g （注意：最大不要超過物理記憶體的 %50）
- 擴大虛擬記憶體空間
命令： sysctl -w vm.max_map_count=2621440（默認值是 “262144”），擴大這個，可以防止這個數量太低而導致的OOM（詳見附6）
- forcemerge
設定merge時最大的執行緒數：index.merge.scheduler.max_thread_count，固態硬碟——默認最大值 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)) ，普通旋轉磁盤——設定為1
筆者機器上，單merge 執行緒，300G的索引耗時：7個小時
優化效果： term 單條件查詢，查詢時間從10秒多提高到3秒多，索引減少約%2.85，減少4000多萬，具體如下表：
| index | total_segments_berfore_merge | total_segments_after_merge | query_IP_after(seconds) | query_IP_after(seconds) | decrease(count/percentage) |
| pcap_flow-2019-12-09 | 1412695374 | 137249867 | 10 | 3.6 | 40196703/ %2.845 |
可通過命令查看各個分片的情況，如下（可查看總的segments數量）：
curl -s "http://localhost:9200/_cat/segments/pcap_flow-2019-12-10?v&h=shard,segment,size,size.memory" | awk '{sum += $NF} END {print sum}'
force merge的restful API:
curl -X POST "localhost:9200/pcap_flow-2019-12-11/_forcemerge?max_num_segments=2"
說明：
1）max_num_segments， 設定最大segement數量，數量越小，查詢速度提高越明顯，但merge耗時越長
2）全部merge，不加索引ID，則如下：
curl -X POST "localhost:9200/_forcemerge"
3）merge程序是串行的，如果同時merge多個，后面的會被阻塞，直到第一個merge完成為止，另外，對于不再有寫入的更新的index，才建議force merge，不然反而會讓搜索的性能更差
4）restful api 查看_segments，如下：
curl -X GET "localhost:9200/_cat/segments?v&pretty"
效果如下圖：
題外話，如果貴司銀子多，可以集群分片，搞SSD，否則只有結構優化，這一招，
附：
1）官網 index force merge說明： https://www.elastic.co/guide/en/elasticsearch/reference/7.4/indices-forcemerge.html
2） ES 存盤型別： https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html
3）merge 執行緒數： https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html
4）磁盤陣列RAID： https://zh.wikipedia.org/wiki/RAID
5）關于索引合并的統計分析： http://openskill.cn/article/375
6）擴大虛擬地址空間： https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.htm
本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
*****************************************************************************************************
精力有限，想法太多，專注做好一件事就行
- 我只是一個程式猿，5年內把代碼寫好，技術博客字字推敲，堅持零拷貝和原創
- 寫博客的意義在于打磨文筆，訓練邏輯條理性，加深對知識的系統性理解；如果恰好又對別人有點幫助，那真是一件令人開心的事
*****************************************************************************************************
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/37815.html
標籤：大數據
上一篇：Hadoop完全分布式集群搭建