我们有一个坐在XFS和drbd之上的NFS，它给我们带来了一个糟糕的性能（如iostat / iotop所示，大约1MB / s的读/写）xfs卷的属性是：
meta-data=/dev/drbd0 isize=256 agcount=4, agsize=52427198 blks = sectsz=512 attr=2 data = bsize=4096 blocks=209708791, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 我们有一个带有SAS1068E控制器和2个WD 1TB磁盘的戴尔盒（Dell Box）。该卷当前安装的属性为：
rw,noatime,nodiratime,attr2,nobarrier,logbufs=8,noquota
文件系统包含大量小文件，大小约为50-100k，分布在目录树中。
我们尝试使用ReadAhead值（当前禁用）和xfs挂载选项，但目前为止没有任何成功。
我们在iotop中注意到kdmflush是导致iowait的任何build议来提高此安装程序的性能？
简单的答案是，你的磁盘系统是可悲的低于你想要做的事情。
1MB /秒是SATA磁盘上RAID1随机IO性能的典型代表。 EG，看这里的wmarow的iops和raid计算器。 将两个Barracuda ES.2 SATA磁盘放在一个RAID10中（与RAID1实际上相同），设置100％写入时写入caching命中率为0％，估计吞吐量为0.57MB /秒。 真实世界的performance可能会有所不同，但不会有太大的不同。
您将kdmflush识别为负责任的内核进程的事实加强了这一点 – 如果您的磁盘系统无法处理负载，则会在此过程中花费更多时间在iowait上。 kdmflush是设备映射程序刷新过程，由于在别处加载而处理延迟工作。
有几种改进方法 – 获得更多的磁盘，获得更好的磁盘或打开控制器上的写入caching。
如果你打开写caching，你也会想要一个BBU。 虽然BBU可能不是板载SAS1068E的选项，但您可能需要安装PCI-e控制器。
当我使用的RAID控制器（我相信3ware 9550）没有启用写入caching时，我看到DRBD的糟糕performance。 您的DRBD加载将主要是随机IO，因此写入caching将对性能产生显着影响。
SAS1068E是非常低端的，也可能是造成这个问题的原因。 如果你获得更多的磁盘或更好的磁盘，我build议你也可以获得更好的控制器。
快速谷歌search显示与您正在使用相同型号的RAID控制器类似的性能差 。
1 MB / s听起来很熟悉。 猜测，你的问题是DRBD层的XFS和更多。 如果由于某种原因DRBD上的块复制缓慢，kdmflush导致大量IOWAIT是完全合理的。 这个速度听起来像两个DRBD主机之间的networking连接没有正确协商。
再一次猜测，但是这个速度听起来很像TCP连接，没有TCP Windows正常工作。 networking跟踪应该是非常明显的，因为stream量看起来就像是数据包，数据包，数据包，数据包，数据包，而不是许多数据包和一个数据包。
如果在安装NFS共享的客户端上运行iotop，而不是在NFS服务器本身上运行，则可以查看该连接以及DRBD连接。
为您的DRBD复制使用多于10Mbps的networking。 DRBD设备上的磁盘I / O限于networking速度（除非您使用C以外的协议，如果您希望数据损坏且无用，则执行此操作）。 要testing这是您的networking导致的问题，断开主要从辅助和您的I / O率可能会发射boost。