自过去几天以来，我在一台虚拟机中发现了奇怪的 I/O 峰值。
其 2.6.32-504.el6.x86_64 #1 SMP 2014 年 9 月 16 日星期二 01:56:35 EDT x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server 版本 6.6（圣地亚哥）
大约有 50G 内存和 24CPU 运行 elasticsearch 数据节点。
我们检测到发往该 elasticsearch 节点的请求超时，在检查虚拟机后，我们目前只发现磁盘 I/O 偶尔会卡住。我在虚拟机中的一个磁盘上使用了 ioping
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=1 时间=3.76 毫秒（预热）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=2 时间=1.17 秒
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=3 时间=131.7 us
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=4 时间=282.8 us
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=5 时间=999.4 毫秒
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=6 时间=632.7 毫秒
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=7 时间=2.15 秒（慢）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=8 时间=400.2 毫秒
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=9 时间=20.0 秒（慢）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=10 时间=1.10 毫秒（快）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=11 时间=1.30 毫秒（快）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=12 时间=2.20 毫秒（快速）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=13 时间=2.61 毫秒（快）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=14 时间=203.6 us（快速）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=15 时间=1.09 毫秒（快）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=16 时间=319.3 us（快速）
4 KiB <<< /dev/sdf1（块设备 100.0 GiB）：请求=17 时间=249.8 us（快速）
如您所见，某一时刻出现了 20 秒的峰值。虚拟机位于 vmware esxi blade 上。数据存储区由另外 3 个虚拟机使用，但这些虚拟机均未显示此类延迟问题。我尝试了 fsck 和 tune2fs，两者都未显示文件系统存在任何问题。
当这种情况开始发生时，虚拟机上没有更新。任何有关如何调试此问题的提示都值得赞赏
编辑：这是 atop -d 信息。似乎 lv 处于 100% 繁忙状态，并且 java（此时 elasticsearch 正在读取）
LVM | vg00-lv_data | 忙 100% | | 读取 8904 | 写入 4 | | KiB/r 11 | KiB/w 4 |
| MBr/s 10.03 | MBw/s 0.00 | | avq 21.41 | avio 1.12 毫秒 |PID TID
RDDSK WRDSK
WCANCL DSK
CMD 1/12629 -
100.3M 12K 0K 100%
Java
答案1
最后，似乎一切都是由 elasticsearch 引起的。我们从集群中排除了该节点，然后又将其添加回来，导致分片从机器重新定位，然后又回到机器。出于某种奇怪的原因，这解决了问题。