转载

探索ElasticSearch-无任何索引数据的ElasticSearch状态（八）

之前做了一些简单的 ElasticSearch 的基准测试，但是现在看来还是有两个方面的缺点。一个是不够全面，只是简单测试了下3种线程场景，另外一个是可能机器环境，感觉一直没有压上去。之后打算重新搞一下基准测试。今天想来看看一个基本上没有索引数据的 ElasticSearch 的内存占用和其他相关指标(Segment,Lucene...)的状态。这样做到在最少的环境下心里有个数，感觉还是非常重要的。很多人都忘记了， 其实计算机是一种科学 。这种应该是控制变量法吧？

通过本文，可以让你得到以下 ElasticSearch 的状态。

初始JVM占用大小和变化幅度

ElasticSearch

初始环境

目的是想要搭建一个纯粹的 ElasticSearch 的环境。但是，无奈，又想要观测 ElasticSearch 的各项指标。又想要一个干净的 ElasticSearch 实在有些强人所难。毕竟在使用 Kibana 采集 ElasticSearch 的时候，需要在 ElasticSearch 上面建立索引。

但是，还好这些索引对 ElasticSearch 的影响应该是非常小。我们把他们列在下面。

探索ElasticSearch-无任何索引数据的ElasticSearch状态（八）

可以看到使用 Kibana 对 ElasticSearch 进行监控的时候，存在4个索引。每个索引存在一个主分片，没有副本。总小大不超过1M。

把这些都列出来，做到心中有数。

各项指标

然后，我们让 ElasticSearch 运行一段时间，重点关注初始的 JVM 的占用。

JVM占用和GC

先来看看 JVM 占用。如下图所示。

可以看到在没有任何索引情况下， ElasticSearch 启动所需要的内存大小大概在 400-500 之间。存在100MB左右的浮动。

通过观察 GC Count 和 GC Duration 可以发现存在 100MB 左右的波动，看来是存在了 Young GC 导致的。

我们可以通过 jstat 命令再深入了解下当前 ElasticSearch 的 JVM 情况。

通过 jstat ，我们可以发现当前 Eden 区占用了 273 MB，每隔1秒钟会增加 10 MB多点。所以，我们可以估算大概20次左右就会触发一次 Young GC ，回收掉 Eden 区的内存。

但是，观察下图，会发现在5分钟内折线向下的只有大概6次左右。不是说每个20次左右会发生一次 Young GC ，折线向下的应该会更加密集才对啊。其实这里是因为图像采集的频率是不一样的。所以，导致这里的折线和预估的有差距。估计 Kibana 应该是 10s 采集一次 JVM 内存信息。因为我数了一下 1min 内，存在大概6,7个点。不过，目前来看修改上面的 refresh 时间好像不能改变 Kibana 的采集频率。