一次由磁盘IO问题导致elasticsearch查询慢的排查

最近项目上线了一个elasticsearch相关的功能，过了不久发现接口的延迟很高，通过skywalking发现耗时集中在了查询ES上，

然后将查询对应的DSL语句放到kibana上进行profile排查发现两台节点上的分片查询延迟很高

然后又尝试了几个查询慢的DSL发现都是这两个节点查询比较慢，因此猜测两台机器的节点有问题

然后从kibana监控中发现两台机器的节点的load都很高，我们是16核的机器，但是load值都彪到了近40

然后排查了该机器的cpu发现机器的CPU并不是很高，因此怀疑改机器的IO存在问题，使用top命令发现wa确实很高，由于当时负载40的时候没有截图，因此这是后续稍微降下来的一个截图但是也很高

wa的解释为:：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request. 因此只要IO时间段内有CPU空闲，那这段CPU空闲的锅就会由IO来背。wa就是用来提示io可能阻塞了系统性能。 实际wa本来也就是一段CPU空闲时间

确定了时I/O确实有问题后，使用了iostat -d -k 1命令查看各个磁盘的I/O情况

发现vdb（我们存放ES数据的盘）磁盘高负载的情况下需要每秒需要读取150M，写近20M的数据，await的值也达到了几十，%util都已经达到100%，明显存在性能问题

await解释：

每一个I/O请求的的平均处理时间（单位ms），这里可以理解为I/O的响应时间，一般的系统I/O的响应时间应该低于5ms，如果大于10ms就比较大了

svctm解释：

表示平均每次设备I/0操作的服务时间（单位ms）。如果svctm的值玉await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远远高于svctm的值，则表示I/O队列等待时间很长，系统上运行的程序很慢。

%util解释：

在统计时间内所有处理I/O时间除以总共统计时间，所以才参数暗示了设备的繁忙程度，一般地，如果该参数是100%表示设备已经接近满负荷运行了（如果是多次盘，及时%util是100%，因此磁盘的并发能力，磁盘使用也未必达到瓶颈）

图中我们机器的%util为100%，因为有多个磁盘因此机器整体的I/O不会出问题，但是针对ES所在的磁盘而言，已经严重超载

然后通过cat /sys/block/vdb/queue/rotational命令，返回值为1表示为机械硬盘，0表示SSD

，然后上网查了一下机械硬盘的读取速度大概在60M~80M之间，对于150M/s的I/O明显满足不了

最终结论：

ES所在磁盘的问题

解决方案：

更换ES所在的磁盘为SSD