机器及其他状况
1、es集群是六个节点，其中四个数据节点和两个协调节点，六台都是虚机。 2、es原表数据两亿一千万。
产生的问题
1、使用datax把hive的数据打到es中，第一天的速度是qps2600。但是随着导入的时间的增长，qps越来越慢，同时产生的现象是该表的查询延迟也从即时ms到几百ms。 2、随后开始排查datax导入速度变慢的原因。在第二天的导入的过程中，会经常性的出现导入超时(ReadTimeOut)的原因,随机开始查看datax变慢的各种原因，但最终并没有结果。最后怀疑是到达了该表的一个瓶颈，此时该表的总数据量到达两亿五千万。但是与另一个集群中的四亿多的进行对比，四亿的表的使用状态正常。 3、在把数据从hive写到本地，发现速度是很快的。最后datax导入es变慢的原因是es消费变慢。同时我们也创建了一张新的索引表写入数据，发现也可以写入成功。 4、在定位到es出现问题后，查看监控发现es集群有两个节点的资源一直在高位。猜想之所以能写入不进去产生的原因就是磁盘io已经达到了最大值，随即去查看磁盘io，通过iostat发现磁盘的util已经达到了100%。这说明已经这两个节点的所有写入都是慢的。重启其中一个节点之后，过了一会节点的cpu也是升上去。 5、发现问题所在之后，我们开始找谁现在在对这个es集群进行操作。发现并没有新的操作增加进来。由于这张表增加了四千万的数据，然后开始怀疑这个表操作的同事。让同事停下了对表的写入操作之后，一会之后明显发现磁盘的io下降，查询不在慢。最后在知道同事插入es是一条一条的插，并不是批量插的。 6、最终在使用datax导入发现速度都已经上去。
总结：
在这个过程中，排查这个问题进行了三天，浪费了太多了没有道理的排查. 1、排查问题找到根源。 2、机器监控异常排查产生异常的原因。 3、插入慢，其实就是写入磁盘的速度慢，进而推出磁盘io的相关问题。
