之前介绍了 探索ES-对象和嵌套对象(三) 和 探索ES-嵌套对象和父子对象(四) ,今天想来宏观的把握一下 ElasticSearch
的性能到底是怎么样的?
我们可以使用 基准测试
来对 ElasticSearch
的性能进行测试。
因为暂时没有好的 Linux
服务器,所以只能现在自己的 windows
环境中先测试一把了。
{ "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 } } } } } } } 复制代码
然后,我们启动在机器中的 ElasticSearch
、 Kibana
和 Jmeter
。其中 Kibana
用来对 ElasticSearch
性能做监控, Jmeter
用来发送 Index
请求,不断发送 Http
请求。
创建一个 Http Request
的组件,并配置 ElasticSearch
所需要的 IP
和端口。
注意这个时候,还不能正常发送请求,会提示 text/plain
的 head
不正确。
解决这个问题的方法是在创建一个 HTTP Header Manager
。在 HTTP Header Manager
上面指定 Content-Type
是 application/json
。
虽然在 Kibana
中已经有了对于 ElasticSearch
的监控,但是我们还是可以在 Jmeter
中配置监控 TPS
对应的组件。配置上 Summary Report
和 View 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
提到一个老外的博客中有提到这个问题的解决方案。
Parameters MaxUserPort
这样修改之后,在 Windows
上面就可以暂时进行使用 Jmeter
压测了。
虽然,后来我发现继续加大线程数,还是会时不时出现这个问题。在 StackOverflow
上面也建议到还是希望讲 Jmeter
部署在一台 Linux
的机器上面来对其他应用进行压力测试。
好了,解决了上面这个问题之后,我们开始第一个场景的压力测试。
可以在 Kibana
中的 Index
索引监控模块中看到, Index Rate
大概在300左右。当前有400K的文档数量。总共存放了21.6MB的数量。
观测 ElasticSearch
的节点状态。
发现 CPU
在快速上升。JVM目前来看还是比较平稳的一个状态。
Segment Count
虽然在上下浮动,可以猜测因为数据在不断地进入到 ES
中,不断有新的 Segment
的值被创建,但是 Segment
数量,达到一定的阀值之后, ES
会自动把 Segment
给合并。所以, Segment
的数量会不停地上下浮动。
Latency
总体还是在几毫秒之内返回,说明在这种数量和请求下面, ES
的 Lantency
还是比较平稳的。没有达到 ES
的压力范围内。
因为很明显,上述线程数量还是没有达到当前 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 Total
和 Term
的曲线基本上是保持一致的间距。可以认为是由于 Term
的升高导致的。
在回到 索引
的监控界面。可以看到 Request Rate
从原来的300tps显著上升到600tps。
1000线程下存在两个问题, Jmeter
又开始大量下面这个错误。再次调节注册表字段还是没有效果,估计得将 Jmeter
放置到 Linux
环境中才能彻底解决这个问题了。
java.net.BindException: Address already in use: connect 复制代码
另外一个就是也需要将 Jmeter
对机器CPU的影响降低到一定程度才可以。不然,测试的效果也不一定准确。
不过,目前在上述影响因子没有去掉的情况下,620左右的tps好像已经是极限了。
以后这里每天都会写一篇文章,题材不限,内容不限,字数不限。尽量把自己每天的思考都放入其中。
如果这篇文章给你带来了一些帮助,可以动动手指点个赞,顺便关注一波就更好了。
如果上面都没有,那么写下读完之后最想说的话?有效的反馈和你的鼓励是对我最大的帮助。
另外打算把博客给重新捡起来了。欢迎大家来访问吃西瓜。
我是shane。今天是2019年8月31日。百天写作计划的第三十八天,38/100。
我来评几句
登录后评论已发表评论数()