Elasticsearch、Logstash和Kibana配合使用时的调优
2016-07-20 00:00
281 查看
我们在使用Kibana构建了一个20+ visulization的dashboard后,终于出现了性能了,问题可能表现为:
Elasticsearch后台报Java Heap Limit爆了
Elasticsearch后台报out of memory
15分钟时长(每秒1,000条左右)的日志在kibana dashboard要load好几分钟
更多的数据会报shard无法获取
在通读了ElasticSearch官方指南中关于性能和调优的页面以后,用中文总结一下ES开发人员关于调优的基本指引:
曾经有很多人以为调个参数就能让性能快个10倍100倍,他们以为我们傻吗?所有能调的我们都给你们调好,别他妈乱动,我们见过数以百计的项目因为乱动参数被钉在了历史的耻辱柱上!性能不够就加机器!
即使这样,还是有极个别的东西我们可以根据部署和ELK的特点微调一下(因为没钱开那多instance)。
##Heap Memory
不要使用8G内存以下的实例,实在没法用。16G, 32G, 64G都可以。
将Heap设置为内存的一半,剩下的lucene要用的
不要超过32G
##Field data vs docValue
Field data中文名字叫正排索引,也就是以文档为key。原因是主索引不能很好的完成aggregayion和filering这种操作。要注意,fieldData一旦load,会把整个index中的文档都load入Heap,以便于等会要用。
DocValues同样是正排索引,不同的是,DocValues是在索引时构建并存在硬盘的,而不是像field data一样在search时load进内存。可想而知,DocVaule使用性能兑换了对资源的需求。但事实上,根据我找到的一份资料,Docvalue在查询时的性能仅比field data慢20%,而对内存几乎没有需求了。
尽量使用docValues
将logstash升级到2.0以上并重新构建logstash-*的mapping,logstash会自动将所有raw字段设为
##Field data的内存占用
默认条件下,fieldData是不受限的,它虽然放置在内存中,但本质上不是一个transient的缓存,ES也不会丢弃任何内存中的fieldData。在aggregation特别多的时候,这种设定会导致新的fieddata因为内存满了而搜索不到。
有以下几个参数和field data的内存使用有关:
a. indices.breaker.fielddata.limit
fieldData使用保险;默认60%;
b. indices.breaker.request.limit
其他操作(创建buckets什么的)保险;默认40%;
尽量a+b=100%
c. indices.breaker.total.limit
总阀;默认80%,应略低于100%;
d. indices.fielddata.cache.size
内存回收的触发线,应低于a;
使用Elatico的Marvel观测field data在内存中的使用状况,marvel现在是免费的。
##index时的性能
Logstash的elaticsearch插件是有默认的批量flush的,默认应该是每500条日志或每1秒,可以适当调整,但默认设置应该不会给ES太大压力。
如果发现日志不能及时进入ES,更有可能的性能问题出在logstash上。Logstash,尤其当期有grok这样的filter时,是可以非常占CPU的。我们的结果是,1秒1000条日志,1个grokfilter,这样的logstash就基本要占用AWS instance的一个核。
请意识到解析和索引日志是非常占资源的,请分配足够的资源给logstash。
Elasticsearch后台报Java Heap Limit爆了
Elasticsearch后台报out of memory
15分钟时长(每秒1,000条左右)的日志在kibana dashboard要load好几分钟
更多的数据会报shard无法获取
在通读了ElasticSearch官方指南中关于性能和调优的页面以后,用中文总结一下ES开发人员关于调优的基本指引:
曾经有很多人以为调个参数就能让性能快个10倍100倍,他们以为我们傻吗?所有能调的我们都给你们调好,别他妈乱动,我们见过数以百计的项目因为乱动参数被钉在了历史的耻辱柱上!性能不够就加机器!
即使这样,还是有极个别的东西我们可以根据部署和ELK的特点微调一下(因为没钱开那多instance)。
##Heap Memory
不要使用8G内存以下的实例,实在没法用。16G, 32G, 64G都可以。
将Heap设置为内存的一半,剩下的lucene要用的
不要超过32G
##Field data vs docValue
Field data中文名字叫正排索引,也就是以文档为key。原因是主索引不能很好的完成aggregayion和filering这种操作。要注意,fieldData一旦load,会把整个index中的文档都load入Heap,以便于等会要用。
DocValues同样是正排索引,不同的是,DocValues是在索引时构建并存在硬盘的,而不是像field data一样在search时load进内存。可想而知,DocVaule使用性能兑换了对资源的需求。但事实上,根据我找到的一份资料,Docvalue在查询时的性能仅比field data慢20%,而对内存几乎没有需求了。
尽量使用docValues
将logstash升级到2.0以上并重新构建logstash-*的mapping,logstash会自动将所有raw字段设为
docValues = true
##Field data的内存占用
默认条件下,fieldData是不受限的,它虽然放置在内存中,但本质上不是一个transient的缓存,ES也不会丢弃任何内存中的fieldData。在aggregation特别多的时候,这种设定会导致新的fieddata因为内存满了而搜索不到。
有以下几个参数和field data的内存使用有关:
a. indices.breaker.fielddata.limit
fieldData使用保险;默认60%;
b. indices.breaker.request.limit
其他操作(创建buckets什么的)保险;默认40%;
尽量a+b=100%
c. indices.breaker.total.limit
总阀;默认80%,应略低于100%;
d. indices.fielddata.cache.size
内存回收的触发线,应低于a;
使用Elatico的Marvel观测field data在内存中的使用状况,marvel现在是免费的。
##index时的性能
Logstash的elaticsearch插件是有默认的批量flush的,默认应该是每500条日志或每1秒,可以适当调整,但默认设置应该不会给ES太大压力。
如果发现日志不能及时进入ES,更有可能的性能问题出在logstash上。Logstash,尤其当期有grok这样的filter时,是可以非常占CPU的。我们的结果是,1秒1000条日志,1个grokfilter,这样的logstash就基本要占用AWS instance的一个核。
请意识到解析和索引日志是非常占资源的,请分配足够的资源给logstash。
相关文章推荐
- 在Kubernetes上搭建EFK(Fluentd+Elasticsearch+Kibana)
- 巧用mysql提示符prompt清晰管理数据库的方法
- 两大步骤教您开启MySQL 数据库远程登陆帐号的方法
- phpmyadmin 4+ 访问慢的解决方法
- linux系统下实现mysql热备份详细步骤(mysql主从复制)
- CentOS 5.5下安装MySQL 5.5全过程分享
- MySQL复制的概述、安装、故障、技巧、工具(火丁分享)
- MySQL中删除重复数据的简单方法
- MySQL5.5.21安装配置教程(win7)
- 使用ElasticSearch6.0快速实现全文搜索功能的示例代码
- elasticsearch批量数据导入和导出
- 使用ElasticSearch+LogStash+Kibana+Redis搭建日志管理服务
- logstash mysql slow
- ElasticSearch 使用心得
- ES中如何使用逗号来分词
- logback日志交给logstash处理
- ElasticSearch 守护进程 JSW
- 将redis加入到elk日志系统里
- 实战Kibana的日志关键词搜索和日志可视化