Elasticsearch 和 Lucene 對內存使用狀況：html
Elasticsearch 限制的內存大小是 JAVA 堆空間的大小，不包括Lucene 緩存倒排索引數據空間。
git
- 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的堆內存：
github
- 設置環境變量：
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/2015/09/16/ElasticSearch內存使用分析/
https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
服務器