探索ElasticSearch-無任何索引數據的ElasticSearch狀態（八）

前言

以前作了一些簡單的ElasticSearch的基準測試，可是如今看來仍是有兩個方面的缺點。一個是不夠全面，只是簡單測試了下3種線程場景，另一個是可能機器環境，感受一直沒有壓上去。以後打算從新搞一下基準測試。今天想來看看一個基本上沒有索引數據的ElasticSearch的內存佔用和其餘相關指標(Segment,Lucene...)的狀態。這樣作到在最少的環境下內心有個數，感受仍是很是重要的。不少人都忘記了，其實計算機是一種科學。這種應該是控制變量法吧？

經過本文，可讓你得知如下ElasticSearch的狀態。

• 初始JVM佔用大小和變化幅度
• 初始CPU狀態
• 初始Segment大小
• 改變JVM大小的影響

ElasticSearch

初始環境

目的是想要搭建一個純粹的ElasticSearch的環境。可是，無奈，又想要觀測ElasticSearch的各項指標。又想要一個乾淨的ElasticSearch實在有些強人所難。畢竟在使用Kibana採集ElasticSearch的時候，須要在ElasticSearch上面創建索引。

可是，還好這些索引對ElasticSearch的影響應該是很是小。咱們把他們列在下面。

能夠看到使用Kibana對ElasticSearch進行監控的時候，存在4個索引。每一個索引存在一個主分片，沒有副本。總小大不超過1M。

另外用來監控的索引，也會有少許的查詢。大概Search Total在2-5左右。Index Total在1左右。

把這些都列出來，作到心中有數。

各項指標

JVM佔用和GC

而後，咱們讓ElasticSearch運行一段時間，重點關注初始的JVM的佔用。以下圖所示。

能夠看到在沒有任何索引狀況下，ElasticSearch啓動所須要的內存大小大概在400-500之間。存在100MB左右的浮動。

經過觀察GC Count和GC Duration能夠發現存在100MB左右的波動，看來是存在了Young GC致使的。

咱們能夠經過jstat命令再深刻了解下當前ElasticSearch的JVM狀況。

經過jstat，咱們能夠發現當前Eden區佔用了273MB，每隔1秒鐘會增長10MB多點。因此，咱們能夠估算大概20次左右就會觸發一次Young GC，回收掉Eden區的內存。

可是，觀察下圖，會發如今5分鐘內折線向下的只有大概6次左右。不是說每一個20次左右會發生一次Young GC，折線向下的應該會更加密集纔對啊。其實這裏是由於圖像採集的頻率是不同的。因此，致使這裏的折線和預估的有差距。估計Kibana應該是10s採集一次JVM內存信息。由於我數了一下1min內，存在大概6,7個點。不過，目前來看修改上面的refresh時間好像不能改變Kibana的採集頻率。

因此，咱們要學習估計的能力來整體評估JVM和GC的狀態。

CPU

其實CPU沒啥說的。在沒有寫入和查詢的時候，基本不會消耗CPU資源。以下圖所示。

CPU使用率基本上都在%0-%1。

Segment

Segment Count目前在20左右。考慮到存在用於監控ElasticSearch的4個索引，每一個索引含有的1個分片。因此，總共有4個分片。

咱們知道ElasticSearch的分片其實都是Lucene的索引。而每一個Lucene的索引都由Segment組成。Segment因爲不可改變的特性，致使會在索引新數據時，建立新的Segment。當Segment太多時，多個Segment又會merge成爲一個大的Segment。

因此，我我的以爲在不考慮有索引的狀況下，應該會有4個Segment。可是，這裏是會存在索引監控數據的狀況的。

可是，竟然致使了20左右的Segment仍是我始料未及的。難道，每一個分片都要建立5個左右的Segment？

若是和分片數量有關，那麼能夠在下次增長索引的分片數來看看是不是正相關的。

改變變量-JVM大小

在對照中，咱們才能感覺到在實驗中各個元素的做用。咱們嘗試改變下JVM大小。

打開jvm.options,修改Java的啓動參數爲-Xms2g -Xmx2g,也就是擴大了一倍的內存。以下圖所示。

對於Segment數量，加大JVM內存基本上沒有多大的影響。咱們仍是重點觀察下JVM內存相關的內容。

能夠看到整個內存佔用的線總體向上移動了。其實，熟悉JVM的同窗能夠猜想到這是由於分配給Eden區的大小上升了。臨時對象須要到達一個更高的點纔可以被回收掉。

另外GC Count的值也變小了。畢竟回收後剩餘的空間變大了。對象須要更長的時間纔可以填滿Eden區。

經過jstat查看gc詳細狀況。注意Eden區的大小和後面使用4gJVM時作一個對比。

再次翻倍JVM大小，查看盡可能明顯的信息。當前JVM爲4G大小。

能夠看到當前JVM爲4g和2g時，相差也不是很大。很奇怪的是，爲何JVM的Eden區沒有明顯地增大呢？

經過jstat能夠發現JVM4G時和JVM2G時所分配的Eden區的大小並無發生變化。由於沒有顯式修改JVM的Eden區域的大小。因此，多是JVM的某一個策略把。

好，最後一個問題是不管是JVM2G仍是JVM4G，在Young GC以後，都存在大概350MB左右的內存沒有被回收，這些對象是在哪裏呢？

實際上是存儲在老年代、元數據區裏面的對象。

留下個疑問

最後還給本身留下一個疑問？看下圖。

好像是JVM的內存大小和Doc Values有必定的關係？隨着內存的加大Doc Values好像是趨向去穩定？

關於寫做

之後這裏天天都會寫一篇文章，題材不限，內容不限，字數不限。儘可能把本身天天的思考都放入其中。

若是這篇文章給你帶來了一些幫助，能夠動動手指點個贊，順便關注一波就更好了。

若是上面都沒有，那麼寫下讀完以後最想說的話？有效的反饋和你的鼓勵是對我最大的幫助。

另外打算把博客給從新撿起來了。歡迎你們來訪問吃西瓜。

我是shane。今天是2019年9月9日。百天寫做計劃的第四十六天，47/100。