背景：在数据和服务都准备完成的情况下，打开页面，发现请求需要要几秒才返回；

思路：1.查看搜索接口请求本身耗时情况，排除网络抖动因素，发现搜索接口请求到ES返回结果本身耗时较高；

2.检查每次请求到ES的入参，并在原有参数中加入"profile": true，查看ES处理搜索请求的耗时分布情况；
入参：

返回：

发现只是一个简单的termQuery耗时818ms，然后查看是否ES集群负载情况；
3.初步定位：ES集群的cpu和内存消耗较大，磁盘io写入较高，认为是数据同步服务不断的在提交索引建立请求导致ES集群负载较高，影响了查询性能；

4.初步解决：停掉数据同步服务，使ES集群负载降下来，再做查询，发现搜索响应时间没有任何变化，继而再次监控ES机器磁盘IO；
5.再次定位：发现每次搜索请求时，磁盘需要读40M+的数据，然而一次请求的数据不过10+k，考虑到搜索的索引文件是由多个segment组成，这里是读取多个segment到内存进行查询匹配，打开segment分布情况发现一个索引节点有多个小的segment，判断是由于打开多个文件随机读写提升了读取索引数据耗时；
iostat

curl 'http://xxxx:9200/_cat/segments/m_pd_cu_id_wifi_2es_inc_hi_out?v&h=shard,segment,size,size.memory'

6.再次解决：手动合并segment，几分钟后合并完成，并进行搜索，性能显著提升，问题解决；
curl -XPOST 'http://xxxx:9200/_forcemerge?max_num_segments=1'

7.永久解决：加配置项index.merge.policy.floor_segment=设置每个segment最小值，index.merge.scheduler.max_thread_count=ES集群负载较低时，后台合并segment线程数，一般=核数/2；
curl -XPUT http://xxxx:9200/m_pd_cu_id_ip_2es_inc_hi_out/_settings -d '{"index.merge.policy.floor_segment":"100mb"}'
curl -XPUT http://xx:9200/m_pd_cu_id_rela_address_2es_dt_out/_settings -d '{"index.merge.scheduler.max_thread_count":"2"}'
原因分析：数据同步服务不断的在提交索引构建，ES集群接收到构建请求数据后会缓冲到内存，达到一定量后生成segment，每个segment是一个包含正排（空间占比90~95%）+倒排（空间占比5~10%）的完整索引文件，每次搜索请求会将所有segment中的倒排索引部分加载到内存，进行查询和打分，然后将命中的文档号拿到正排中召回完整数据记录；如果不对segment做配置，提交又特别频繁的话，就会导致查询性能下降，另外将这里的普通硬盘换成SSD，预计搜索性能还会提升3~5倍；

【总结】
搜索性能优化建议：
1.segment合并；索引节点粒度配置index.merge.policy.floor_segment=xx mb；segment默认最小值2M
2.索引时不需要做打分的字段，关闭norms选项，减少倒排索引内存占用量；字段粒度配置omit_norms=true；
3.BoolQuery 优于 TermQuery；目前需求场景全部不需要用到分词，所以尽可能用BoolQuery；
4.避免使用对象嵌套结构组建document，建议优化为一个扁平化结构，查询多个扁平化结构在内存做聚合关联；
5.设定字符串类型为不分词，可以用于字符串排序，但是比起数字排序会消耗cpu，搜索效率更低，慎用；
6.cache设置，就目前数据业务类型，保持默认配置即可，设值fielddata.cache之类的缓存命中率低，反而吃掉了ES集群的一部分内存；

索引性能优化建议：
1.调小索引副本数；针对索引节点粒度：curl -XPUT http://xxxx:9200/m_pd_cu_id_gps_2es_inc_hi_out/_settings -d '{"number_of_replicas":1}'
2.设置延迟提交，延迟提交意味着数据提交到搜索可见，有延迟，需要结合业务配置；针对索引节点粒度：curl -XPUT http://xxxx:9200/m_pd_cu_id_gps_2es_inc_hi_out/_settings -d '{"index.refresh_interval":"10s"}'；默认值1s；
3.设置索引缓冲buffer，最大512m，默认值是jvm的10%；ES集群粒度config/elasticsearch.yml ：indices.memory.index_buffer_size = 10%

4.适当减少备份数，必要字段只需要提供搜索，不需要返回则将stored设为false；

如果ES提交索引请求达到瓶颈，一般任务队列task-queue为50，可以设置task-queue队列，提升搜索集群索引能力；

 

补充：

在一年多以前，我写过Elasticsearch 5 入坑指南一文，其中提到将生产的某个ES集群从2.4升级到5.0以后， 冷数据结点搜索性能变差，对大索引进行搜索的时候，io read会长时间飙高，导致系统load很重，甚至到无法响应的程度。
 
通过进一步分析，用Linux下的Sar -B命令，可以看到有大量的数据被pagein到内存。 虽然通过“试”的方法，定位到这个问题和5.0开始使用的mmap fs有关联，并且通过更改为nio fs以后得到解决，但问题的底层根源一直没找到。 
 
近期有空重新去看了一下这个问题， 在Github上发现一个对os底层更熟悉的人提交并分析了类似的问题 Avoid file cache trashing on Linux with mmapfs by using madvise 。  总结:

  1. mmap fs对比nio fs，省去了磁盘io上的系统调用，并且不需要在jvm内部做io缓存，也减轻了GC压力。 所以通常来说，mmapfs的性能应该更高。 这也是为什么lucene推荐使用mmap fs，并且ES从5.0开始做为默认的store配置的原因。
  2. 然而，mmap系统调用，在内核层面默认会有一个2MB的预读大小设置，也就是说，当映射了一个大文件以后，即使读取其中1k个字节，mmap也会预读取2MB的数据到缓存。 这种策略是基于文件的访问大多数是顺序的假设。
  3. 在ES这个特定的应用场景，如果某数据结点上索引不是很大，系统剩余缓存也足够，一般不会有问题。但是如果是大数据应用场景，典型的如海量的日志ELK应用，则可能对大索引的搜索聚合，产生较多的随机磁盘访问。 从而mmap的预读策略，可能会导致大量的无用数据从磁盘读取到系统缓存。 在系统可用的缓存不是非常宽裕的情况下，某些极端场景下，会导致热数据被过于频繁的踢出内存，再反复读入，让磁盘IO不堪重负。
  4. Lucene有一个NativePosixUtil.madvise(buffer,NativePosixUtil.RANDOM)的native调用，可以用于指导内核对mmap过的文件做读取的时候，禁用预读。 上文作者将该调用hack进lucene代码，做搜索对比测试。 结论是对于磁盘io和cache的消耗，niofs都要好于mmapfs，而patch过的mmapfs则比niofs更好。
  5. 作者的测试仅限于搜索，对于其他类型的io操作，如写入，merge没有做过详尽测试，因此不清楚利弊。
  6. ES官方开发人员认为这是一个有趣的发现，值得深入去探究。对于用户报告的mmap fs性能比nio fs更差的问题，猜测可能是在大索引读取的场景下，预读带来的额外开销，抵消了相对niofs节省的系统调用等开销。 
  7. ES官方提到Lucene已经有一种类似功能的store，叫做NativeUnixDirectory（显然ES目前还没有对这种store的支持)，用户动手能力强的话，应该可以利用这个store自己写一个ES plugin。 另外提到JAVA 10提供了O_DIRECT to streams / channels ，似乎官方打算等这个出来以后再看怎么处理这个问题。
  8. 要注意，这个预读是mmap层面的，和块设备的预读是两回事。 我们曾经尝试过使用 blockdev --setra 这个linux命令取消块设备预读，证实无法解决这个问题。

 
结论: 如果ES结点上会存放海量的索引数据，经常会有大索引（如1TB+)的搜索聚合操作，使用NIOFS会更安全，可以避免很多怪异的性能问题。