探索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。