本文主要总结Elasticsearch性能优化方面的相关内容
1. 概述
性能优化是个涉及面非常广的问题,不同的环境,不同的业务场景可能会存在不同的优化方案,本文只对一些相关的知识点做简单的总结,具体方案可以根据场景自行尝试。
1.1 性能测试
如果需要做性能调优,性能基准测试的工具必不可少,这里可以选择Rally
1.2 热点线程
当集群缓慢,使用大量的CPU资源时,可以使用热点线程API来查看资源都执行在了哪些地方,并可以查看资源消耗的情况。
可以通过已下方式查看热点线程
1. 全局的分析:/_nodes/hot_threads
2. 某个节点的分析:/_nodes/{nodesIds}/hot_threads
3. 常规配置
3.1 部署方案
- 当单机容纳不下数据时,考虑多分片
- 当查询性能不足时,考虑多副本。
- 对于一些高性能的服务器,可以考虑一台服务器上部署多个实例
- 通过awarenss的相关配置,阻止分片及其副本部署在同一台机器上。
- 尽量平均分配分片和副本。
- 当集群较大时,考虑设计每个节点的角色。例如 节点只作为查询聚合节点,数据节点,或是主/候选主节点
3.2 避免内存交换
内存交换是指把内存页写入磁盘的过程,一般发生在物理内存不够或是某些情况下操作系统认为应该发生的时候发生。如果交换了的内存页再次被需要,操作系统会从交换区加载到内存,该过程相对于内存操作而言是是比较慢的。
为了保证ES的高效,在ES中应该避免内存交换的发生,如果达到此目的,需要进行如下配置:
1. 设置elasticserach.yml文件中的bootstrap.mlockall=true
2. 设置Xms与Xmx的值相同
3. 在/etc/security/limits.conf中添加elasticsearch -memlock unlimited
4. 在/etc/pam.d/common-session中添加session required pam_limits.so
5. 重启es
3.3 采用G1垃圾回收机制代替默认CMS
3.4 索引刷新频率(refresh_interval)
该参数基本遵循如下规律:
1. 刷新越快,数据更新越快,但是查询与索引的效率越低
2. 虽然增加该值,可以一定程度的提升效率,但是超过一定数值后,提升的效果将微乎其微。
3.5 线程池调优
如果你发现ES实例的资源没有100%饱和,但却受到了拒绝执