轉自：https://segmentfault.com/a/1190000018558875?utm_source=sf-similar-article
Elasticsearch 和 Lucene 對內存使用情況：
Elasticsearch 限制的內存大小是 JAVA 堆空間的大小，不包括Lucene 緩存倒排索引數據空間。
- Lucene 中的 倒排索引 segments 存儲在文件中，為提高訪問速度，都會把它加載到內存中，從而提高 Lucene 性能。所以建議至少留系統一半內存給Lucene。
- Node Query Cache (負責緩存f ilter 查詢結果)，每個節點有一個，被所有 shard 共享，filter query查詢結果要么是 yes 要么是no，不涉及 scores 的計算。
集群中每個節點都要配置，默認為：indices.queries.cache.size:10% - Indexing Buffer 索引緩沖區，用於存儲新索引的文檔，當其被填滿時，緩沖區中的文檔被寫入磁盤中的 segments 中。節點上所有 shard 共享。
緩沖區默認大小：indices.memory.index_buffer_size: 10%
如果緩沖區大小設置了百分百則indices.memory.min_index_buffer_size用於這是最小值，默認為 48mb。indices.memory.max_index_buffer_size用於最大大小，無默認值。 - Shard Request Cache 用於緩存請求結果，但之緩存request size為0的。比如說 hits.total, aggregations 和 suggestions.
默認最大為indices.requests.cache.size:1% - Field Data Cache 字段緩存重要用於對字段進行排序、聚合是使用。因為構建字段數據緩存代價昂貴，所以建議有足夠的內訓來存儲。
Fielddata 是 延遲 加載。如果你從來沒有聚合一個分析字符串，就不會加載 fielddata 到內存中，也就不會使用大量的內存，所以可以考慮分配較小的heap給Elasticsearch。因為heap越小意味着Elasticsearch的GC會比較快，並且預留給Lucene的內存也會比較大。。
如果沒有足夠的內存保存fielddata時，Elastisearch會不斷地從磁盤加載數據到內存，並剔除掉舊的內存數據。剔除操作會造成嚴重的磁盤I/O，並且引發大量的GC，會嚴重影響Elastisearch的性能。
Elasticsearch默認安裝后設置的內存是1GB，這是遠遠不夠用於生產環境的。
有兩種方式修改Elasticsearch的堆內存：
- 設置環境變量：
export ES_HEAP_SIZE=10g在es啟動時會讀取該變量； - 啟動時作為參數傳遞給es：
./bin/elasticsearch -Xmx10g -Xms10g
給es分配內存時要注意，至少要分配一半兒內存留給 Lucene。
分配給 es 的內存最好不要超過 32G ，因為如果堆大小小於 32 GB，JVM 可以利用指針壓縮，這可以大大降低內存的使用：每個指針 4 字節而不是 8 字節。如果大於32G 每個指針占用 8字節，並且會占用更多的內存帶寬，降低了cpu性能。
還有一點， 要關閉 swap 內存交換空間，禁用swapping。頻繁的swapping 對服務器來說是致命的。
總結：給es JVM棧的內存最好不要超過32G，留給Lucene的內存越大越好，Lucene把所有的segment都緩存起來，會加快全文檢索。
參考文檔：
https://nereuschen.github.io/...
https://www.elastic.co/guide/...