我发现了一个 Mumble 服务器的性能问题，我在上一个问题中描述的是由未知来源的 I/O 延迟问题引起的。由于我不知道是什么原因造成的，也不知道如何进一步调试它，所以我想征求您对这个主题的看法。
我正在运行一个Hetzner EX4S 根服务器作为 KVM 管理程序。服务器运行 Debian Wheezy Beta 4，并通过 LibVirt 使用 KVM 虚拟化。
服务器有两个不同的 3TB 硬盘驱动器，因为在报告 SMART 错误后更换了一个硬盘驱动器。第一个硬盘是 Seagate Barracuda XT ST33000651AS（512 字节逻辑，4096 字节物理扇区大小），另一个是 Seagate Barracuda 7200.14 (AF) ST3000DM001-9YN166（512 字节逻辑和物理扇区大小）。有两个 Linux 软件 RAID1 设备。一个用于未加密的启动分区，一个作为加密其余部分的容器，使用两个硬盘驱动器。
在后一个 RAID 设备中有一个 AES 加密的 LUKS 容器。在 LUKS 容器内有一个 LVM 物理卷。hypervisor 的 VFS 在所描述的 LVM 物理卷上分为三个逻辑卷：一个用于 /，一个用于 /home，一个用于 swap。
下面是块设备配置栈的示意图：
sda (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)
sdb (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)
md0 (Boot RAID)
- ext4 (/boot)
md1 (Data RAID)
- LUKS container
- LVM Physical volume
- LVM volume hypervisor-root
- LVM volume hypervisor-home
- LVM volume hypervisor-swap
- … (Virtual machine volumes)
来宾系统（虚拟机）也大多运行 Debian Wheezy Beta 4。我们有一个额外的 Ubuntu Precise 实例。他们也从 LVM 物理卷中获取块设备。这些卷是通过 Virtio 驱动程序以本机写入模式访问的。管理程序和来宾系统上的 IO 调度程序（电梯）都设置为deadline默认值cfs，因为根据我们的 bonnie++ 测试系列，这恰好是性能最高的设置。
I/O 延迟问题不仅会在客户系统内部出现，还会影响在管理程序系统本身上运行的服务。设置看起来很复杂，但我确信不是基本结构导致了延迟问题，因为我以前的服务器运行了四年，基本设置几乎相同，没有任何性能问题。
在旧设置中，以下内容有所不同：
- Debian Lenny 是管理程序和几乎所有来宾的操作系统
- Xen 软件虚拟化（因此也没有 Virtio）
- 没有 LibVirt 管理
- 不同的硬盘驱动器，每个大小为 1.5TB（其中一个是 Seagate Barracuda 7200.11 ST31500341AS，另一个我不能说了）
- 我们没有 IPv6 连接
- 无论是在 hypervisor 还是在 guest 中，我们都没有明显的 I/O 延迟问题
根据数据表，当前硬盘驱动器和旧机器之一的平均延迟为 4.12 毫秒。
7200RPM SATA 驱动器不能执行 4.12ms 延迟，这将使其能够每秒执行 1/4.12ms（大约 240）IO，这是不现实的。
计算单个磁盘 IOPS 的正确公式是 1/(avg_seek_time + avg_rotational_latency) 对于 7200RPM 驱动器大约等于 75 IOPS。如果您有磁盘的规格表，那么您将有两个延迟，因为驱动器可以吸收具有不同延迟的写入和读取，但它们在 +-10% 以内。
当您的队列深度不太高时，您可以预期来自 SATA 磁盘的每个 IO 延迟为 13-15 毫秒。10 到 15 毫秒之间的一切都被认为是正常的；20 毫秒将暗示深度队列（或非常大的 IO 请求大小）引起的延迟问题，而 30 毫秒或更高则表明某些病态。从理论上讲，您的第 95 个百分位数应低于 15 毫秒，系统将“正常”运行。
在运行生产工作负载时，您能否衡量主机和来宾的平均服务时间？您可以通过查看
iostat“await”列中的输出来获取该值。除此之外，我会说您的设置具有最大可能的抽象延迟——因为您将很多东西从虚拟文件系统分层到设备的物理块。
此外，您能否验证您的 HBA 是否具有 BBWC（或启用了磁盘写入缓存）以及虚拟机管理程序和来宾内部的文件系统是否未使用屏障？