摘錄自：http://blog.csdn.net/yangwenbo214/article/details/74000458
內存使用和GC指標
在運行Elasticsearch時，內存是您要密切監控的關鍵資源之一。 Elasticsearch和Lucene以兩種方式利用節點上的所有可用RAM：JVM heap和文件系統緩存。 Elasticsearch運行在Java虛擬機（JVM）中，這意味着JVM垃圾回收的持續時間和頻率將成為其他重要的監控領域。
JVM heap: A Goldilocks tale
Elasticsearch強調了JVM堆大小的重要性，這是“正確的” - 不要將其設置太大或太小，原因如下所述。 一般來說，Elasticsearch的經驗法則是將少於50％的可用RAM分配給JVM堆，而不會超過32 GB。
您分配給Elasticsearch的堆內存越少，Lucene就可以使用更多的RAM，這很大程度上依賴於文件系統緩存來快速提供請求。 但是，您也不想將堆大小設置得太小，因為應用程序面臨來自頻繁GC的不間斷暫停，可能會遇到內存不足錯誤或吞吐量降低的問題
Elasticsearch的默認安裝設置了1 GB的JVM heap大小，對於大多數用例來說，太小了。 您可以將所需的heap大小導出為環境變量並重新啟動Elasticsearch:
export ES_HEAP_SIZE=10g
如上我們設置了es heap大小為10G，通過如下命令進行校驗：
curl -XGET http://:9200/_cat/nodes?h=heap.max
Garbage collection
Elasticsearch依靠垃圾收集過程來釋放heap memory。因為垃圾收集使用資源（為了釋放資源！），您應該注意其頻率和持續時間，以查看是否需要調整heap大小。設置過大的heap會導致GC時間過長，這些長時間的停頓會讓集群錯誤的認為該節點已經脫離。
| Metric description | Name | [Metric type][monitoring-101-blog] |
|---|---|---|
| Total count of young-generation garbage collections | jvm.gc.collectors.young.collection_count(jvm.gc.collectors.ParNew.collection_count prior to vers. 0.90.10) |
Other |
| Total time spent on young-generation garbage collections | jvm.gc.collectors.young.collection_time_in_millis(jvm.gc.collectors.ParNew.collection_time_in_millis prior to vers. 0.90.10) |
Other |
| Total count of old-generation garbage collections | jvm.gc.collectors.old.collection_count(jvm.gc.collectors.ConcurrentMarkSweep.collection_count prior to vers. 0.90.10) |
Other |
| Total time spent on old-generation garbage collections | jvm.gc.collectors.old.collection_time_in_millis(jvm.gc.collectors.ConcurrentMarkSweep.collection_time_in_millis for versions prior to 0.90.10) |
Other |
| Percent of JVM heap currently in use | jvm.mem.heap_used_percent |
Resource: Utilization |
| Amount of JVM heap committed | jvm.mem.heap_committed_in_bytes |
Resource: Utilization |
JVM指標的要點：
-
JVM heap in use: 當JVM heap 使用率達到75％時，es啟動GC。如上圖所示，可以監控node的JVM heap，並且設置一個警報，確認哪個節點是否一直超過%85。如果一直超過，則表明垃圾的收集已經跟不上垃圾的產生。此時可以通過增加heap（需要滿足建議法則不超過32G），或者通過增加節點來擴展集群，分散壓力。
-
JVM heap used vs. JVM heap committed: 與commit的內存（保證可用的數量）相比，了解當前正在使用多少JVM heap的情況可能會有所幫助。heap memory的圖一般是個鋸齒圖，在垃圾收集的時候heap上升，當收集完成后heap下降。如果這個鋸齒圖向上偏移，說明垃圾的收集速度低於rate of object creation，這可能會導致GC時間放緩，最終OutOfMemoryErrors。
-
Garbage collection duration and frequency: Both young- and old-generation garbage collectors undergo “stop the world” phases, as the JVM halts execution of the program to collect dead objects。在此期間節點cannot complete any task。主節點每30秒會去檢查其他節點的狀態，如果任何節點的垃圾回收時間超過30秒，則會導致主節點任務該節點脫離集群。
-
Memory usage: 如上所述，es非常會利用除了分配給JVM heap的任何RAM。像Kafka一樣，es被設計為依賴操作系統的文件系統緩存來快速可靠地提供請求。
許多變量決定了Elasticsearch是否成功讀取文件系統緩存，如果segment file最近由es寫入到磁盤，它已經in the cache。然而如果節點被關閉並重新啟動，首次查詢某個segment的時候，數據很可能是必須從磁盤中讀取，這是確保您的群集保持穩定並且節點不會崩潰的重要原因之一。
總的來說，監控節點上的內存使用情況非常重要，並且盡可能多給es分配RAM，so it can leverage the speed of the file system cache without running out of space。