一台连上外网的机器
1.下载对应的 node 安装包

2.下载 Elasticsearch-head 安装包（顺便解压）

3.cmd 输入下面命令安装taobao提供的镜像（原因你懂的）

$ npm install -g cnpm --registry=https://registry.npm.taobao.org

 
4.cmd cd 到你解压的 elasticsearch-head 目录下

$ cnpm install

这时你会发现多了一个 node_modules 目录

5.install 后，head 目录下会自动生成一个 node_modules 目录，里面为相关的依赖

到此，本地的准备工作都已完成。
可以把两个安装包上传到服务器。
建议：elasticsearch-head 重新压缩后上传
 
/etc/profile 添加（改成你的路径）

export NODE_HOME=/usr/local/elastic/node/node-v6.9.2-linux-x64

export PATH=$NODE_HOME/bin:$PATH

记得

$ source /etc/profile

在 elastic/config/elasticsearch.yml 添加（否则完成后网页中会显示未连接）

http.cors.enabled: true

http.cors.allow-origin: "*"

之后（后台启动加 &）

./grunt server 

在网页中输入你的http://localhost:9100

尝鲜

10月26日，Elasticsearch5.0.0 GA终于放出，携程ES Ops团队也在第一时间在DEV和UAT环境分别进行了2.4.0 至5.0.0的升级和测试。升级完成后，除了部分Query不向前兼容（主要是Filtered Query)，需要在应用端做一些修改以外，未发现其他问题。通过监控系统看对比升级前后的主要系统指标，在同等索引量的情况下，CPU使用率有明显下降 ( 30% - 50%左右) ，相信性能方面5.0应该是有较大提升的。 

在测试环境稳定运行了2周以后，我们决定选定一个生产集群进行升级，考验新版本在更为复杂的用户环境下的表现。 出于对业务影响最小化的考虑，用于日志分析的集群被圈定为升级目标。该集群也是携程十几个集群中规模最大的一个，共有120个数据结点运行于70台物理机上，总数据量接近1PB。

升级前需要做一些准备工作，下载官方的Migration Helper插件，检查集群设置和索引的兼容性。对于不兼容的配置项，MH会详尽列出，其中标注为红色部分为为升级前必须修改项。1.x版本创建的索引，是无法直接升级到5的，需要先在2.x集群里做一次reindex 。 MH提供了不兼容索引扫描功能，对于找到的不兼容索引，可以直接在UI上发起reindex操作，等待结束即可。 如果是用于业务搜索集群，数据可能比较重要，建议升级前做一个Snapshot，万一升级过程出现意外，可以回退版本从备份里快速恢复数据。我们的日志集群数据量极大，也没有对数据100%不丢的要求，因此升级前没有做Snapshot。 做完所有的准备工作后，预先通知所有用户集群升级的时间以及可能产生的影响，选定了周五深夜用户低峰期，开始正式升级工作。 

首先通过Ansible将新版本批量部署到所有结点并统一配置，紧接着对原有集群做了Full Stop，校验所有的ES已经停下后，开始Full Start。整个过程比较顺利，所有结点正常启动，数据恢复完成后，集群重新回到正常服务状态。

周末两天运行，未发现有任何的异样，CPU利用率也降了不少，看起来很靠谱……直到周一


踏坑

周一早上，随着用户访问量高峰来临，马上浮现出一个诡异的现象： 索引速率遇到了瓶颈，数据开始在前置的消息队列(Kafka)里堆积。 从监控数据看，尽管所有的数据结点CPU消耗都比上周同期低，磁盘IO也很低，但索引速率却低了很多。反复对比查看升级前后各类监控指标后，终于发现一个可疑点，所有结点的网络流量比升级前高了好几倍！  在集群架构上，我们是单独架设了几台client node做为数据写入和分发的入口，现在这几个node的网络流量已经饱和，成为数据写入的瓶颈。一开始，怀疑是否2.4启用了tcp压缩，而5.0取消了，但翻查官方文档后发现transport.tcp.compress在2.4和5.0里默认都是关闭的！ 这时候只有两个解决办法了，要么启用tcp压缩，要么扩容client node。 先考虑了一下tcp压缩的方案，快速扒了一下ES源码，在transport.TcpTransport这个类里，sendRequest和sendResponse两个方法会根据transport.tcp.compress设置来决定发送的消息是否要经过压缩，而在messageReceived方法则会读取消息头部的状态信息，探测消息是否经过压缩以及压缩的方法，而后决定是否需要解压，以及采用的解压方式。 这样看起来，ES是允许tcp压缩和不压缩的结点之间通讯的，那么只对client node启用压缩应该就可以了。测试环境测试过后，验证了想法的可行性。于是对生产的client node开启tcp压缩，同时在数据发送端(hangout的ES output)也启用tcp压缩，重启client node后入口网络流量降到和之前2.4差不多的程度，问题得到规避。 针对这个问题在Github上提交了issue https://github.com/elastic/ela ... 21612， 但未得到官方合理的解释。

解决好这个问题，另外一个问题来了，很多执行大量历史数据搜索的用户反映出不了结果。 从监控数据看，这类查询的搜索耗时非常久，直到网关300秒超时（查询api前置的nginx代理)。我们之前对集群设置过Global Search timeout为60s，用来保护集群资源过多被超高代价的查询消耗，在2.4版本是有效果的，现在看来不起作用了。手动测试了一下，这个参数果然失效！ 于是向官方报告了第2个问题：https://github.com/elastic/ela ... 21595 。 这个问题很快被官方确认为Bug，修复也很快加入到了5.0.2。 为了规避这个问题，我们只好临时修改了一下Kibana以及第三方API访问要经过的nginx proxy，默认为所有的search request加入一个超时选项。此后，问题有一些缓解，但仍然发现用户查询大范围历史数据时，部分用于存储历史数据的结点响应很慢。

我们的集群是做了冷热分离的结构的，热节点主要承担写入和存放过去24小时数据，冷结点没有写入，查询频率也低，所以为了最大化利用硬件资源，一台物理机上跑了3个实例，这样一台128GB内存的机器可以存放下近30TB的索引。查看冷结点的监控数据，看到用户查询期间磁盘的read IO非常高，直接将磁盘IO Util%撑到100%，并且可持续数小时，同时search thread pool有大量的active thread处于无法完成状态，search queue不断攀升直至饱和、开始reject。 表象上看search thread似乎一直在尝试从磁盘大量读取数据，一次search甚至可以持续几十分钟至一个小时，耗尽了所有的搜索线程，导致拒绝后续的搜索服务。 于是Github上报了第3个issue: https://github.com/elastic/ela ... 21611  这个问题找到解决办法之前，我们只能通过反复重启有问题的冷结点来缓解。 和官方讨论过程中，得知5.0在Lucene文件访问方式上有一个比较大的改动，2.4使用mmapfs读取索引文件的部分，而5.0以后改为用mmapfs读取索引文件的全部。怀疑问题和这个变动有关，尝试将所有索引文件的设置改为NIOFS后，问题迎刃而解。 搜索性能一下回到了2.4时代，再也没出现搜索线程超长时间执行的问题。之后找时间复现了这个问题，并抓取了线程栈，看到长时间执行的搜索线程一直在做Global Ordinal的构造工作。 至于为何会这样，还不清楚。 从官方给出的信息看，底层索引文件的访问模式是没有变化的，仅仅是将文件读取方式全部改成了mmapfs，理论上应该性能更好，但是看起来在我们这种一台机器跑多个ES实例，所有分配的heap为系统缓存3倍的极端用例下，大范围的数据搜索可能造成过高的磁盘读IO，集群性能指数级下降。

以上问题前后耗了4天才完全规避掉，支持团队连续熬夜后集群总算回复到平稳状态。然而好景不长，运行一段时间以后，数据结点出现疑似内存泄漏现象。结点总数据没怎么增加、甚至还有减少的情况下，heap使用率一只呈攀升趋势，Old GC无法回收内存。这个问题对用户影响较小，通过监控我们可以及时发现内存即将用尽的结点，做一次重启很快就恢复了。 为排查根源，我们对一个有问题的结点做了dump，通过MAT工具分析，看到meta data相关的一个alias对象被实例化了有6600万次之多！ 在Github上提交了第四个issue: https://github.com/elastic/ela ... 22013，不多久被确认为已知问题https://github.com/elastic/ela ... 21284 ,在5.0.1已经修复。

最后还存在一个master node内存泄漏的问题，这个问题在2.4.0时代就存在了，升级到5.0.0以后依然没有修复。由于我们的master node和data node是分离的，所以这个问题比较容易通过监控发现，解决方式也很简单和迅速，重启master node即可，对用户完全无影响。之后不久，5.0.2版本正式发布，release notes里提到了对这个问题的修复 https://github.com/elastic/ela ... 21578 。

上周周末我们将集群rolling upgrade到了5.0.2，global search timeout失效和两个内存泄漏的问题从根源上解决掉了。 网络流量增大的问题依然存在，仍然需要通过启用client结点的transport.tcp.compress规避。 冷结点搜索性能的问题没看到有提及，估计没解决，安全起见，还是保持索引的文件系统为NIOFS。升级完成运行一段时间后，可以肯定，5.0.2已经比较稳定。


心得

升到5.0.2后，对于其中一组数据结点这两天特意加了点索引负载，通过监控数据将v5.0.2与2.4.0做实际运行环境的索引吞吐量对比。




 
在近似的CPU使用率和load情况下，5.0.2能够支撑更大的吞吐量。另外5.0带来的Instant aggregation功能，对于跨多个索引的时序类型数据的聚合也可以有效Cache了，在使用Kibana的时候提速感觉非常明显。

升级过程虽然遇到很多波折，但由于集群架构上做了角色分离(client,master,data)和冷热分离，因而Bug引起的故障比较容易被限定在一个较小的范围而不至于影响所有的功能和所有的用户。 故障点定位更加容易，规避措施也更容易实施。 部分规避措施实施过程中甚至对用户是完全无影响的，比如: 重启内存泄漏的master node)。详尽的监控为问题的发现和诊断提供了有力的支持。

Elasticsearch是非常复杂的系统，官方的测试无法覆盖所有的用例场景和数据规模，一些极端的应用场景可能触发某个深藏的Bug或者缺陷而陷入困境。 因此对于稳定性要求极高的应用，最好还是采用经过长时间考验的版本，比如v2.4.2。

A customizable importer from mysql to elasticsearch.
可定制的 elasticsearch 数据导入工具 ——基于 elasticsearch 的 JS API
 
 
【github 项目地址】
https://github.com/parksben/mysql_2_elasticsearch 


【主要功能】
1. 完全使用 JS 实现数据从 MySQL 到 elasticsearch 的迁移；
2. 可批量导入多张 MySQL 表；
3. 可自定义的数据迁移规则（数据表/字段关系、字段过滤、使用正则进行数据处理）；
4. 可自定义的异步分片导入方式，数据导入效率更高。


【一键安装】

npm install mysql_2_elasticsearch

【快速开始（简单用例）】

var esMysqlRiver = require('mysql_2_elasticsearch');



var river_config = {

  mysql: {

    host: '127.0.0.1',

    user: 'root',

    password: 'root',

    database: 'users',

    port: 3306

  },

  elasticsearch: {

    host_config: {               // es客户端的配置参数

      host: 'localhost:9200',

      // log: 'trace'

    },

    index: 'myIndex'

  },

  riverMap: {

    'users => users': {}         // 将数据表 users 导入到 es 类型: /myIndex/users

  }

};





/*

** 以下代码内容：

** 通过 esMysqlRiver 方法进行数据传输，方法的回调参数(一个JSON对象) obj 包含此次数据传输的结果

** 其中：

** 1. obj.total    => 需要传输的数据表数量

** 2. obj.success  => 传输成功的数据表数量

** 3. obj.failed   => 传输失败的数据表数量

** 4. obj.result   => 本次数据传输的结论

*/



esMysqlRiver(river_config, function(obj) {

  /* 将传输结果打印到终端 */

  console.log('\n---------------------------------');

  console.log('总传送：' + obj.total + '项');

  console.log('成功：' + obj.success + '项');

  console.log('失败：' + obj.failed + '项');

  if (obj.result == 'success') {

    console.log('\n结论：全部数据传送完成！');

  } else {

    console.log('\n结论：传送未成功...');

  }

  console.log('---------------------------------');

  console.log('\n(使用 Ctrl + C 退出进程)');

  /* 将传输结果打印到终端 */

});

【最佳实现（完整用例）】

var esMysqlRiver = require('mysql_2_elasticsearch');



/*

** mysql_2_elasticsearch 的相关参数配置(详情见注释)

*/



var river_config = {



  /* [必需] MySQL数据库的相关参数(根据实际情况进行修改) */

  mysql: {

    host: '127.0.0.1',

    user: 'root',

    password: 'root',

    database: 'users',

    port: 3306

  },



  /* [必需] es 相关参数(根据实际情况进行修改) */

  elasticsearch: {

    host_config: {               // [必需] host_config 即 es客户端的配置参数，详细配置参考 es官方文档

      host: 'localhost:9200',

      log: 'trace',

      // Other options...

    },

    index: 'myIndex',            // [必需] es 索引名

    chunkSize: 8000,             // [非必需] 单分片最大数据量，默认为 5000 (条数据)

    timeout: '2m'                // [非必需] 单次分片请求的超时时间，默认为 1m

    //(注意：此 timeout 并非es客户端请求的timeout，后者请在 host_config 中设置)

  },



  /* [必需] 数据传送的规则 */

  riverMap: {

    'users => users': {            // [必需] 'a => b' 表示将 mysql数据库中名为 'a' 的 table 的所有数据 输送到 es中名为 'b' 的 type 中去

      filter_out: [                // [非必需] 需要过滤的字段名，即 filter_out 中的设置的所有字段将不会被导入 elasticsearch 的数据中

        'password',

        'age'

      ],

      exception_handler: {           // [非必需] 异常处理器，使用JS正则表达式处理异常数据，避免 es 入库时由于类型不合法造成数据缺失

        'birthday': [                // [示例] 对 users 表的 birthday 字段的异常数据进行处理

          {

            match: /NaN/gi,          // [示例] 正则条件(此例匹配字段值为 "NaN" 的情况)

            writeAs: null            // [示例] 将 "NaN" 重写为 null

          },

          {

            match: /(\d{4})年/gi,    // [示例] 正则表达式(此例匹配字段值为形如 "2016年" 的情况)

            writeAs: '$1.1'          // [示例] 将 "2015年" 样式的数据重写为 "2016.1" 样式的数据

          }

        ]

      }

    },

    // Other fields' options...

  }



};





/*

** 将传输结果打印到终端

*/



esMysqlRiver(river_config, function(obj) {

  console.log('\n---------------------------------');

  console.log('总传送：' + obj.total + '项');

  console.log('成功：' + obj.success + '项');

  console.log('失败：' + obj.failed + '项');

  if (obj.result == 'success') {

    console.log('\n结论：全部数据传送完成！');

  } else {

    console.log('\n结论：传送未成功...');

  }

  console.log('---------------------------------');

  console.log('\n(使用 Ctrl + C 退出进程)');

});

【注意事项及参考】
1. elasticsearch数据导入前请先配置好数据的 mapping；
2. "host_config" 更多参数设置详见 [es官方API文档] https://www.elastic.co/guide/e ... .html
3. mysql 表的自增 id 将自动替换为 "表名+_id" 的格式，如："users_id"；
4. 如出现数据缺失情况，请注意查看 elasticsearch 终端进程或日志，找出未成功导入的数据，通过设置 exception_handler 参数处理它。

一.前言
应medcl写es文章的时候，其实这段时间es研究的不多，感觉没什么新东西可写。
考虑只有这次调优心得可与大家分享，文笔有限，见谅！
二.背景
先交代一下背景，调优的项目是某电商类搜索项目，流量来自于前端的app和h5。
搜索主要是根据用户的地理位置和关键字等条件搜索附近的商家和商品。
商品数据大概在5000w左右，商品更新很频繁，更新量大概是每天2000w条左右，（因商家经常会促销、或者调上下架状态、改价格等）查询也相当频繁。
集群有2个集群，一个主一个备，用于有问题的时候随时切换。主集群有8个节点，配置是32核，
32g内存的docker的机器。给es jvm分配20g内存，jdk 版本是1.7，gc 是使用parnew/cms gc。
这个项目我是后期加入的，来的时候项目已上线。由于参与进来的时候es跑的也还是比较稳定，所以也一直
没调过es的参数。程序，参数基本上也就保持上线的时候那个样子。
es上线的时候是用的1.5版本，后期没升过级。
三.问题
项目大概跑了一年多，时间来到大概16年的9月份。搜索请求响应时间开始出现几秒才完成的情况，
我就被拉过来调优了。通过我们自己内部的调用方法监控，tp99和avg这些值还好，维持在200ms以下。max 最大有5,6s的情况，而且次数有点多。
这里没怎么折腾，很快定位就是es gc导致的。翻了一下es gc日志，就是cms remark这个阶段时间特别长，
而且 这个阶段是stop the world的。
四.解决
为什么remark阶段这么长时间？ 直接上结论，就是一次cms 周期内，并发标记后到remark这个期间jvm 堆内存对象
变化很大。说白了对应我们的场景就是一大波 es bulk操作。对应Bigdesk观察，几秒的卡顿基本都出现在一大波 es bulk操作之后。
这里解释一下，引用网上文章的说法：
remark如果耗时较长，通常原因是在cms gc已经结束了concurrent-mark步骤后，旧生代的引用关系仍然发生了很多的变化，旧生代的引用关系发生变化的原因主要是：
* 在这个间隔时间段内，新生代晋升到旧生代的对象比较多；
* 在这个间隔时间段内，新生代没怎么发生ygc，但创建出来的对象又比较多，这种通常就只能是新生代比较大的原因；
原文地址：
http://hellojava.info/?tag=cms-gc-remark

调整一：
加cms gc 的 线程
直接从根源入手，你remark 慢，我就让你跑快点。
因为我们是32 核的cpu ，cpu 利用率用bigdesk观察还是很低的，5%左右。这么低，那就加点线程呗。
-XX:ParallelGCThreads= N
-XX:ParallelCMSThreads= M
调整这2个参数都可以，它们的关系：ParallelCMSThreads = (ParallelGCThreads + 3)/4)
调整后情况缓解了一些，remark还是有3,4秒的情况。
调整二：
关于这点是我们自己的问题。一次bulk 操作就写1条数据。
是的，你没有看错，我们这边的工程师就是这么干的。
一年以前提过这里最好是能合并写，但现在还是这个样子。
这里有一些业务上的原因，合并写会导致一些字段值不准确。
合并写暂时没办法，只能调整es 了。(这里说明一下，其实合并写应该是本次优化比较有效果的办法，可惜这招不让我用。)
通过bigdesk观察，bulk线程池有reject的情况。
但就增加bulk线程池的消费线程，加快数据的消费速度，减少对象驻留在jvm 的时间。
调整后情况没有明显的好转，
但肯定有用，能优化一点是一点嘛。

调整三：
再次从gc入手， -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark
这个是网上找的办法：
为了减少第二次暂停的时间，开启并行remark: -XX:+CMSParallelRemarkEnabled。 如果remark还是过长的话，可以开启-XX:+CMSScavengeBeforeRemark选项，强制 remark之前开始一次minor gc，减少remark的暂停时间，但是在remark之后也将立即开始又一次minor gc。调整后情况也没有特别的好转。
以上都是从减小单次cms gc的开销的方向去解决问题，然后我就换了个方向，降低cms gc发生的次数，让它少发生或者不发生。
调整四:
这里调整了一共5个参数，
Xmn10g ==> 8g
CMSInitiatingOccupancyFraction=70 ==>80

index.cache.filter.max_size 2g==>1g
index.cache.filter.expire 2m==>40s
index.refresh_interval 20s==>30s

前2个参数没什么好说的，提高cms gc 被触发的条件，降低cms gc 触发几率。
后3个参数是本文的重点，这里大概讲下es 对于filter cache的管理。
这部分是通过阅读源码分析出来的，涉及代码还挺多，有点复杂，还有很大一部分还是lucene的代码。
这里就不贴大段代码了。
es 对于 filter cache管理是内部维护了一个map的结构（实际是利用com.google.common.cache实现的），关键是这个map 的key 是个它自己定义的类
叫 FilterCacheKey，它override了equals方法
public FilterCacheKey(Object readerKey, Object filterKey) {
    this.readerKey = readerKey;
    this.filterKey = filterKey;
}
...
@Override
public boolean equals(Object o) {
    if (this == o) return true;
//            if (o == null || getClass() != o.getClass()) return false;
    FilterCacheKey that = (FilterCacheKey) o;
    return (readerKey().equals(that.readerKey()) && filterKey.equals(that.filterKey));
}
从这里可以看出，filter cache 能否被再次利用到就跟readerKey和filterKey 有关。
filterkey如果你build 查询语句的时候什么都没设置的话，就是filter对象本身。
举个例子，TermFilter，如果term一样，那前后2次查询filterKey是一致的。
关键是这个readerKey是否一致呢？这个readerKey其实就是lucene 的 indexReader，如果前后2次查询有数据更新并且
index.refresh_interval 这个参数设置的比较小，es 会去刷新indexReader，那么很有可能readerKey不一致。
对应我们的场景，数据更新频繁，而且index.refresh_interval 比较小，那么缓存利用率就不太高。
后一次查询的filter cache 会重新put 到上面提到的map里，然后这个index.cache.filter.max_size 2g 
就迅速占满（我们程序代码里很多地方使用到了filter），配多大都有可能占满。那这个filter cache什么时候被移除呢,index.cache.filter.expire 2m管移除这个事，当然应该还有size满了移除的策略。
这就造成了缓存没什么用，还占这么大地方，还占那么久。
然后这个filter cache就很可能跑到 old gen去了。
那么就让它占少点，不干活就快点走：
index.cache.filter.max_size 2g==>1g
index.cache.filter.expire 2m==>40s
index.refresh_interval 20s==>30s
这些调整完毕，重启es ，通过bigdesk ,gc a线图好看多了，cms gc 基本没了，monitor gc 也顺畅多了。
五.总结和备注
总结：
1.优化这个事，我认为是业务上的优化要比技术上优化有效的多
2.日志和监控是你最好的朋友，仔细的看，你总会看出什么
3.es 缓存要利用好，还是需要好好去设计，回头考虑单独写一篇。
备注：
因为这次优化后，我就离开了原来的公司，没有了原来的环境。所以本文
部分参数和数字可能不准确，我仅凭记忆完成。