吃西瓜

走过必留下痕迹

目录
探索ElasticSearch-基准测试BenchMark(五)
/  

探索ElasticSearch-基准测试BenchMark(五)

前言

之前介绍了探索ES-对象和嵌套对象(三)探索ES-嵌套对象和父子对象(四),今天想来宏观的把握一下ElasticSearch的性能到底是怎么样的?

我们可以使用基准测试来对ElasticSearch的性能进行测试。

基准测试

环境准备

因为暂时没有好的Linux服务器,所以只能现在自己的windows环境中先测试一把了。

  • 机器:Windows10 6核心 16GB内存
  • ElasticSearch启动参数:JVM 1GB
  • mapping文件:
{
  "mapping": {
    "doc": {
      "properties": {
        "message": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        },
        "postDate": {
          "type": "date"
        },
        "user": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}

然后,我们启动在机器中的ElasticSearchKibanaJmeter。其中Kibana用来对ElasticSearch性能做监控,Jmeter用来发送Index请求,不断发送Http请求。

配置Jmeter

创建一个Http Request的组件,并配置ElasticSearch所需要的IP和端口。

注意这个时候,还不能正常发送请求,会提示text/plainhead不正确。

解决这个问题的方法是在创建一个HTTP Header Manager。在HTTP Header Manager上面指定Content-Typeapplication/json

虽然在Kibana中已经有了对于ElasticSearch的监控,但是我们还是可以在Jmeter中配置监控TPS对应的组件。配置上Summary ReportView Results Tree

启动下Jmeter,发现可以正常发送Index请求,ElasticSearch中也是正常创建了新的文档。

遇到问题

在初步尝试使用100线程数来压测ElasticSearch

发现在Summary Report中提示如下错误信息。

java.net.BindException: Address already in use: connect

大概意思是端口已经被使用了。初步分析是由于是当前系统中所开启的线程数过多,导致端口不够用了吧。但是,需要在哪里修改参数呢?

在业界流传着这么一句话

你现在遇到的问题,早在八百年前就有人遇到了。

所以,我们去Google上面搜索下。发现了
apache-multiple-requests-with-jmeter这么一篇StackOverflow的帖子,这里不得不感叹StackOverflow的强大的知识沉淀能力。

然后stackoverflow提到一个老外的博客中有提到这个问题的解决方案。

  1. 打开注册表
  2. 定位到一个叫做Parameters的key
  3. 修改里面的MaxUserPort的属性值为66534

这样修改之后,在Windows上面就可以暂时进行使用Jmeter压测了。

虽然,后来我发现继续加大线程数,还是会时不时出现这个问题。在StackOverflow上面也建议到还是希望讲Jmeter部署在一台Linux的机器上面来对其他应用进行压力测试。

100线程

好了,解决了上面这个问题之后,我们开始第一个场景的压力测试。

可以在Kibana中的Index索引监控模块中看到,Index Rate大概在300左右。当前有400K的文档数量。总共存放了21.6MB的数量。

观测ElasticSearch的节点状态。

发现CPU在快速上升。JVM目前来看还是比较平稳的一个状态。

Segment Count虽然在上下浮动,可以猜测因为数据在不断地进入到ES中,不断有新的Segment的值被创建,但是Segment数量,达到一定的阀值之后,ES会自动把Segment给合并。所以,Segment的数量会不停地上下浮动。

Latency总体还是在几毫秒之内返回,说明在这种数量和请求下面,ESLantency还是比较平稳的。没有达到ES的压力范围内。

500线程

因为很明显,上述线程数量还是没有达到当前ES所能够承受的极限范围。所以,尝试将线程数量上升为500。

可以看到与原先200线程的时候比较,500线程时,CPU使用率再次上升。不过后面考虑到因为在同一台机器上面启动了Jmeter和ElasticSearch,所以很有可能是Jmeter导致的CPU上升是非常有可能的,下次需要将Jmeter防止到另外一台机器上面来测试下ElasticSearch的性能可能会更加好一点,不过这里测试应该问题也不是很大,毕竟CPU使用率才40%都没有达到,远远没有达到CPU的瓶颈。

可以看到JVM的使用率随着不断Index新的文档,内存在不断地上升。

Index Memory-Lucene的总内存在不断的上升,但是Doc Values基本没有变化,可能是由于

Index Memory-Lucene的提示说明中可以看到Index Memory-Lucene是占据了JVM的一部分内存的。

那么Index Memroy-Lucene的升高是由于什么原因呢?可以在第二张图片中Lucene TotalTerm的曲线基本上是保持一致的间距。可以认为是由于Term的升高导致的。

在回到索引的监控界面。可以看到Request Rate从原来的300tps显著上升到600tps。

1000线程

1000线程下存在两个问题,Jmeter又开始大量下面这个错误。再次调节注册表字段还是没有效果,估计得将Jmeter放置到Linux环境中才能彻底解决这个问题了。

java.net.BindException: Address already in use: connect

另外一个就是也需要将Jmeter对机器CPU的影响降低到一定程度才可以。不然,测试的效果也不一定准确。

不过,目前在上述影响因子没有去掉的情况下,620左右的tps好像已经是极限了。

关于写作

以后这里每天都会写一篇文章,题材不限,内容不限,字数不限。尽量把自己每天的思考都放入其中。

如果这篇文章给你带来了一些帮助,可以动动手指点个赞,顺便关注一波就更好了。

如果上面都没有,那么写下读完之后最想说的话?有效的反馈和你的鼓励是对我最大的帮助。

另外打算把博客给重新捡起来了。欢迎大家来访问吃西瓜

我是shane。今天是2019年8月31日。百天写作计划的第三十八天,38/100。


标题:探索ElasticSearch-基准测试BenchMark(五)
作者:yang2yang
地址:http://blog.chixigua.xyz/articles/2019/08/31/1567262928117.html

评论