前言
经常会有人吐槽，Elasticsearch为什么写着写着突然就慢了？
笔者总结了常见的一些导致写入慢的场景，以供大家排查。
话不多说，进入正题…
Elasticsearch写入慢问题排查思路
Elasticsearch的写入场景相对比较简单，绝大部分场景下我们都是使用bulk API进行写入操作，列举了下面一些场景可能会导致写入慢的问题。
场景1 内存参数配置不合理。
是否给Elasticsearch实例足够的内存，如果内存足够的话，建议配置30GB每个Elasticsearch数据实例节点。
场景2 bulk提交量过大，导致内存被堆满。
一次提交的bulk数量不宜过大，实践证明5-10MB左右大小合适。
场景3 客户端IP，端口配置问题。
因为Elasticsearch的客户端采用的是轮询的方式，所以尽量配置所有节点的IP、端口，或者开启嗅探功能。
场景4 写入时指定DOC ID，导致读IO高。
写入时指定DOC ID，意味着首先需要判断ID是否重复，如果在大数据量的场景下，可能会需要从磁盘进行一次读操作，从而占用大量的磁盘IO，导致写入速度慢。
场景5 bulk队列积压，请求线程被拒绝。
大量的bulk队列被等待或者积压，导致线程被拒绝，这时候需要适当降低业务请求的并发量。
场景6 热分片问题。
单个索引的分片集中分布在某几个机器节点上，导致写入压力无法均匀地分布到各个机器节点上，形成阻塞的问题。
场景7 集群不稳定，大量分片迁移和恢复。
如果你的集群处于不稳定的状态，比如有大量的分片在做均衡迁移或者恢复，都会占用大量的资源，导致写入资源被占用。
场景8 部分实例长时间不断的full gc，导致实例处于假死状态。
部分场景下，数据实例处于长时间不断的full gc，但此时并没有完全脱离集群，写入请求仍然往这个节点发送，此时节点已经无法处理了。快速解决办法：重启问题实例。
场景9 磁盘IO瓶颈。
当磁盘出现IO瓶颈，能怎么办呢，换更好的盘？？，或者扩容吧。
场景10 查询业务占用大量的资源。
高并发的查询或者大数据的查询可能会占用大量的资源，此时需要衡量你的系统侧重点了，实在不行，扩容吧。
场景11 索引段合并占用大量的IO资源。
索引段合并太频繁同样会占用大量的IO资源，如果不是SSD盘，将索引段合并线程设置为1。
场景12 分词器设计不合理。
不同的分词对写入影响很大，分词器设计不合理，可能会存在大量的CPU计算和过度分词等问题。
小结
列举了一些常见的会造成写入慢的场景，更多的写入调优手段在这里，还等什么。
查询慢排查思路在这里，see you。
