aef*_*aef 6 io software-raid luks kvm-virtualization debian-wheezy
我发现了一个 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，一个用于交换。
下面是块设备配置栈的示意图：
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 驱动程序以本机直写模式访问的。根据我们的 bonnie++ 测试系列，管理程序和来宾系统上的 IO 调度程序（电梯）被设置为deadline而不是默认设置，cfs因为这恰好是性能最高的设置。
I/O 延迟问题不仅出现在来宾系统内部，还会影响在管理程序系统本身上运行的服务。设置看起来很复杂，但我确信不是基本结构导致延迟问题，因为我以前的服务器运行了四年，基本设置几乎相同，没有任何性能问题。
在旧设置中，以下内容有所不同：
根据数据表，当前硬盘和旧机之一的平均延迟为4.12ms。
一个 7200RPM SATA 驱动器无法做到 4.12 毫秒的延迟，这将使其能够每秒执行 1/4.12 毫秒（大约 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（或启用了磁盘写入缓存）并且虚拟机管理程序和来宾内部的文件系统没有使用屏障？
| 归档时间： |
|
| 查看次数： |
4288 次 |
| 最近记录： |