我有一台运行 VMware ESX 的戴尔服务器，配备 12TB 本地 SSD 驱动器、1TB 内存、Xeon Gold 处理器和一个 Debian VM。
在该虚拟机上，当我同时在磁盘上执行写入操作时，甚至只是执行以下命令：
dd if=/dev/urandom of=/local/ssd/drive/path/largefile bs=1M count=1024
我在 VSphere 上针对该虚拟机发出了严重的磁盘延迟警报。
dd 命令在 10 分钟后成功完成。
为什么 vSphere 会触发并不严重的严重警报？
如何仅用一个 dd 命令就能压垮高端 SSD 驱动器？
编辑：
如果延迟在五分钟内超过 75 毫秒，则会触发严重警报。
实际上，该虚拟机的磁盘延迟似乎约为 200-250 毫秒：
编辑2：
- 配置：厚延迟置零（不幸的是，没有紧急置零）
编辑3：
我尝试在 VM 级别定义该磁盘的 IOPS 限制（如下图所示）。
我尝试过，1000 IOPS，然后是 800、600、400、200、100。即使只有 100 IOPS，也会触发严重磁盘延迟警报。
奇怪的是（如您在图表中看到的），降低限制（从 1000 IOPS 到 100 IOPS）往往会增加 vSphere 报告的磁盘延迟。在 100 IOPS 限制下，延迟为 16,000 毫秒。
编辑4：
在软件方面，我尝试将最大同时文件写入数量从 24 个减少到 4 个。延迟从 200 毫秒变为 100 毫秒，但写入带宽从 100MB/秒变为 50MB/秒。
编辑5：
从厚惰性零配置切换到厚急切零配置，延迟没有任何变化，始终为 200 毫秒
注意是延迟警报。这意味着系统发出了大量 I/O 命令，这些命令被排队。
延迟会增加，因为如果发出新命令，它会被附加到队列的末尾，需要等待轮到它执行，而这只有在执行完所有之前的命令后才会发生——因此这个新命令需要等待比平时更长的时间。这个等待时间称为系统延迟。想象一下一家大型商店或超市，顾客在结账时排队；当顾客很多时，所有收银员都会很忙，因此延迟（任何顾客在队列中花费的时间）就会增加。
这可能很重要，也可能不重要。这取决于这个系统的作用。对于实时处理高负载的在线 RDBMS 来说，这是不可接受的，因为所有处理都会大大减慢，从而降低数据库的性能。数据库对存储延迟非常敏感。对于交互式系统（如桌面），这不太重要；启动新程序或加载新文档的时间会明显变长，但其他负载模式通常不会受到影响。对于文件服务器来说，这是可以安全容忍的，因为网络和其他协议延迟会更长，因此存储过载导致的额外延迟不会那么明显。
VMWare 不知道它运行的是哪种工作负载。因此，它会保持安全，提醒您存储已超载。是否采取行动由您决定。它还允许您对 VM 实例设置资源限制，以使其无法过载太多。