首先，說明筆者的機器環境（不結合環境談解決方案都是耍流氓）: 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年內把代碼寫好，技術博客字字推敲，堅持零拷貝和原創
- 寫博客的意義在於打磨文筆，訓練邏輯條理性，加深對知識的系統性理解；如果恰好又對別人有點幫助，那真是一件令人開心的事
*****************************************************************************************************