之前有问过es写过慢的问题，因为有段时间我们KAFKA堆积的比较厉害，在排查为什么写的慢。
之前考虑过，客户端使用异步的接口不等待返回结果直接给客户端，这样消息队列那块堆积的消息能少一点，但是这样的话会有更多的数据在一瞬间发到es集群，我怕本来负载就高的集群一瞬间承受不住。。
集群四个机器 八核16G，SSD，用于线上的日志存储，可以完全放弃读的性能专门针对写优化，日志索引配置基本都按照官网来处理了，但是写的速度依旧很慢，之前发过这个问题，1-10M的数据，速度在800ms到20s不等（负载高的情况下会很慢）。四个机器感觉不是完全负载均衡，有一个机器负载相对低一点，但是四个机器负载都比较高，最低的load 8-10，最高的都快20了。一般来说负载在8以内才算是相对稳定。 iostat看了下iowait站的不多，svctm也很低说明不是磁盘的问题，但是await比较多是不是出现100ms多，感觉是io队列比较满。然后cpu的话 us站的最多（80%以上），idle平均比较低,20%不到。
请问这种情况，应该是机器的CPU到达瓶颈了吧？应该只能通过扩容处理了吧？我实在想不出什么办法了。。。
之前考虑过，客户端使用异步的接口不等待返回结果直接给客户端，这样消息队列那块堆积的消息能少一点，但是这样的话会有更多的数据在一瞬间发到es集群，我怕本来负载就高的集群一瞬间承受不住。。
集群四个机器 八核16G，SSD，用于线上的日志存储，可以完全放弃读的性能专门针对写优化，日志索引配置基本都按照官网来处理了，但是写的速度依旧很慢，之前发过这个问题，1-10M的数据，速度在800ms到20s不等（负载高的情况下会很慢）。四个机器感觉不是完全负载均衡，有一个机器负载相对低一点，但是四个机器负载都比较高，最低的load 8-10，最高的都快20了。一般来说负载在8以内才算是相对稳定。 iostat看了下iowait站的不多，svctm也很低说明不是磁盘的问题，但是await比较多是不是出现100ms多，感觉是io队列比较满。然后cpu的话 us站的最多（80%以上），idle平均比较低,20%不到。
请问这种情况，应该是机器的CPU到达瓶颈了吧？应该只能通过扩容处理了吧？我实在想不出什么办法了。。。
1 个回复
hubble
赞同来自:
另外现在已经做了哪些配置优化？因为主要是写日志，不知道refresh_interval设置是多少？