elasticsearch-搜索引擎-性能优化（5）

上一篇的优化主要为纯应用层的优化，本篇主要讲基于es参数配置优化及jvm的关系，以es1.2.1及以上版为参考。

（1）分片数的设置。默认为5个。最佳的设置要进行单个分片的索引压力测试，跟机器的配置与所要索引的具体数据记录大小有关，故绝大部分应用均可采用该默认设置。

   其计算公式为， 分片数的个数n=数据总条数/单个分片的索引最大值。

   有人认为分片数越多越好，这种认为是有误的。分片数的多少，直接决定了一次查询所要同时打开的文件流的数量，以及各个分片在查询结果完成后的merge及其它操作，直接影响搜索响应时间。

（2）副本数设置。默认的“index.number_of_replicas”值即为除了原索引数据块之外的要额外复制的索此片数，默认为1。即有两份数据。要把该值的个数是否包括原始数据搞清楚。该值视机器配置有直接关系，一般建议至少应大于等于1，保证在出现索引数损坏、所在机器宕机等情况下，可以正常进行搜索相关操作，保证系统的稳定性。

(3) -Xms,-Xmx设置。前者为最小所占内存数，后者为最大所占内存数，超过该值则为内存溢出。

    由于搜索引擎对资源的要求特殊性，一般要将两值设为相同大小，且偏大为好，能保证较好的搜索体验，默认是xms=256M,xmx=1G,在数据量到达千万级之后，这个设置是没法做任何操作的。一般视机器配置而定，我一般设置为5G。

es对该处做了简单封装为ES_MIN_MEM=Xms,ES_MAX_MEM=Xmx。这样的话在理论是能保证在jvm的gc swapping的时候，不会导致es的内存变小或伸缩略大，导致性能明显下降，这也就是锁住内存的操作。

    但在操作系统中，该锁住内存的操作需要系统支持。首先应设置ES的配置文件中的“bootstrap.mlockall: true”。它能让es有锁住内存的能力。另外需要linux操作系统对进程或线程对内存操作的限制，即执行“ulimit -l unlimited”即可。

（4）自动发现新增或减少节点，也就是所谓的心跳超时操作。该参数在网络环境不稳定时，异常重要。默认为3s,会给机器不少的ping压力。一般会扩大该参数，即可节省内耗资源，又能增加稳定性。建议是扩大1-2倍，设置为6-9即可。

经过前两篇的优化操作，也介于本人的实战操作，在12台节点的服务器，内存为10G，索引量为21亿的索引查询中，均可在ms级内完成，系统的稳定性明显提高。

鉴于时间有限，暂做以上4点说明，欢迎有兴趣和想交流的同学加入网络爬虫、nlp群320349384，交流促进发展，共享成就未来。