我发现一个Mumble服务器的性能问题，我在前面的问题中描述是由于来源不明的I / O延迟问题造成的。 因为我不知道是什么原因造成的，以及如何进一步debugging，所以我要求您提供关于这个主题的想法。
我正在运行Hetzner EX4S根服务器作为KVMpipe理程序。 服务器运行Debian Wheezy Beta 4，通过LibVirt使用KVM虚拟化。
服务器有两个不同的3TB硬盘驱动器，因为其中一个硬盘驱动器在SMART错误报告后被replace。 第一块硬盘是希捷Barracuda XT ST33000651AS（逻辑512字节，物理扇区大小4096字节），另一块是希捷Barracuda 7200.14（AF）ST3000DM001-9YN166（512字节的逻辑和物理扇区大小）。 有两个Linux软件RAID1设备。 一个用于未encryption的启动分区，另一个用作encryptionhibernate的容器，同时使用两个硬盘驱动器。
在后面的RAID设备中有一个AESencryption的LUKS容器。 在LUKS容器内部有一个LVM物理卷。 pipe理程序的VFS在所描述的LVM物理卷上分为三个逻辑卷：一个用于/，一个用于/ home，另一个用于交换。
以下是块设备configuration堆栈图：
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驱动程序访问卷。 系统pipe理程序和来宾系统上的IO调度程序（电梯）设置为deadline而不是默认的cfs ，因为根据我们的bonnie ++testing系列，这是最高性能的设置。
I / O延迟问题不仅体现在访客系统内部，还会影响在pipe理程序系统本身上运行的服务。 设置看起来很复杂，但是我确信基本结构不会导致延迟问题，因为我以前的服务器运行了四年，几乎完全相同的基本设置，没有任何性能问题。
在旧的设置下面的事情是不同的：
根据数据表，当前硬盘和旧机器的平均延迟为4.12ms。
一个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到15ms之间的任何情况都可以认为是正常的。 20ms会暗示深度排队（或者非常大的IO请求大小）的延迟问题，而30ms或更高的时间会指向某种病态的问题。 从理论上讲，你的第95个百分点应该低于15ms，系统将performance“正常”。
您是否可以在运行生产工作负载时提供主机和客户平均服务时间的衡量？ 您可以通过在“await”列中查看iostat的输出来获取此值。
除此之外，我会说你的设置具有最大的可能的抽象延迟 – 因为你从虚拟文件系统到设备的物理块分层了很多东西。
另外，您是否可以validation您的HBA是否有BBWC（或者是否启用了磁盘写入caching），并且pipe理程序和客户机中的文件系统没有使用屏障？