我发现 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 物理卷。虚拟机管理程序的 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 连接
- 无论是在虚拟机管理程序中还是在客户机中，我们都没有发现明显的 I/O 延迟问题
根据数据表，当前硬盘和旧机器的硬盘平均延迟为 4.12ms。
答案1
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（或者是否启用了磁盘写缓存）以及虚拟机管理程序上和客户机内部的文件系统是否没有使用障碍？