优化背景：
基于 elasticsearch-5.6.0
机器配置：3 个阿里云 ecs 节点，16G，4 核，机械硬盘
优化前，写入速度平均 3000 条/s，一遇到压测，写入速度骤降，甚至 ES 直接频率 GC、OOM 等；优化后，写入速度平均 8000 条/s，遇到压测，能在压测结束后 30 分钟内消化完数据，各项指标回归正常。
生产配置：
这里我先把自己优化的结果贴出来，后面有参数的详解：
elasticsearch.yml 中增加如下设置：
索引优化配置：
优化参数详解
①精细设置全文域：string 类型字段默认会分词，不仅会额外占用资源，而且会影响创建索引的速度。所以，把不需要分词的字段设置为 not_analyzed。
②禁用 _all 字段：对于日志和 apm 数据，目前没有场景会使用到。
③副本数量设置为 0：因为我们目前日志数据和 apm 数据在 es 只保留最近 7 天的量，全量日志保存在 hadoop，可以根据需要通过 spark 读回到 es，况且副本数量是可以随时修改的，区别分片数量。
④使用 es 自动生成 id：es 对于自动生成的 id 有优化，避免了版本查找。因为其生成的 id 是唯一的。
⑤设置 index.refresh_interval：索引刷新间隔，默认为 1s。因为不需要如此高的实时性，我们修改为 30s。扩展学习：刷新索引到底要做什么事情？
⑥设置段合并的线程数量
如下：
段合并的计算量庞大，而且还要吃掉大量磁盘 I/O。合并在后台定期操作，因为他们可能要很长时间才能完成，尤其是比较大的段。
机械磁盘在并发 I/O 支持方面比较差，所以我们需要降低每个索引并发访问磁盘的线程数。
这个设置允许 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许三个线程。
①设置异步刷盘事务日志文件：
对于日志场景，能够接受部分数据丢失。同时有全量可靠日志存储在 hadoop，丢失了也可以从 hadoop 恢复回来。
②elasticsearch.yml 中增加如下设置：
已经索引好的文档会先存放在内存缓存中，等待被写到到段（segment）中。缓存满的时候会触发段刷盘（吃 I/O 和 CPU 的操作）。默认最小缓存大小为 48m，不太够，最大为堆内存的 10%。对于大量写入的场景也显得有点小。
①设置 index、merge、bulk、search 的线程数和队列数
例如以下 elasticsearch.yml 设置：
②设置 filedata cache 大小
例如以下 elasticsearch.yml 配置：
filedata cache 的使用场景是一些聚合操作（包括排序），构建 filedata cache 是个相对昂贵的操作。所以尽量能让他保留在内存中。
然后日志场景聚合操作比较少，绝大多数也集中在半夜，所以限制了这个值的大小，默认是不受限制的，很可能占用过多的堆内存。
①设置节点之间的故障检测配置
例如以下 elasticsearch.yml 配置：
大数量写入的场景，会占用大量的网络带宽，很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁（1s 检测一次）。此项配置将大大缓解节点间的超时问题。
转载作品，原作者：小程序建站，文章来源：https://www.toutiao.com/article/7084257110112125443/
微信扫一扫 
支付宝扫一扫 