前言

之前做了一些簡單的ElasticSearch的基準測試，但是現在看來還是有兩個方面的缺點。一個是不夠全面，只是簡單測試了下3種執行緒場景，另外一個是可能機器環境，感覺一直沒有壓上去。之後打算重新搞一下基準測試。今天想來看看一個基本上沒有索引資料的ElasticSearch的記憶體佔用和其他相關指標(Segment,Lucene...)的狀態。這樣做到在最少的環境下心裡有個數，感覺還是非常重要的。很多人都忘記了，其實計算機是一種科學。這種應該是控制變數法吧？

通過本文，可以讓你得知以下ElasticSearch的狀態。

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

ElasticSearch

初始環境

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

但是，還好這些索引對ElasticSearch的影響應該是非常小。我們把他們列在下面。

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

另外用來監控的索引，也會有少量的查詢。大概Search Total

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

各項指標

JVM佔用和GC

然後，我們讓ElasticSearch執行一段時間，重點關注初始的JVM的佔用。如下圖所示。

可以看到在沒有任何索引情況下，ElasticSearch啟動所需要的記憶體大小大概在400-500之間。存在100MB左右的浮動。

通過觀察GC Count和GC Duration可以發現存在100MB左右的波動，看來是存在了Young GC導致的。

我們可以通過jstat命令再深入瞭解下當前ElasticSearch的JVM情況。

通過jstat，我們可以發現當前Eden區佔用了273MB，每隔1秒鐘會增加10

但是，觀察下圖，會發現在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。