我们有一个位于 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 Values（当前已禁用）和 xfs 挂载选项，但目前似乎没有任何成功。
我们在 iotop 中注意到 kdmflush 是导致 iowait 的进程，有什么建议可以改善此设置的性能吗？
答案1
简短的回答是，您的磁盘系统严重不符合您要执行的操作的要求。
1MB/秒是 SATA 磁盘上 RAID1 随机 IO 性能的典型值。例如，请参阅 wmarow 的 iops anr raid 计算器这里。将两个 Barracuda ES.2 SATA 磁盘放入 RAID10（实际上与 RAID1 相同），设置 100% 写入，写入缓存命中率为 0%，预计吞吐量为 0.57MB/秒。实际性能可能有所不同，但不会有太大差异。
将 kdmflush 确定为负责的内核进程这一事实强化了这一点 - 如果您的磁盘系统无法处理负载，则会导致此进程在 iowait 中花费更多时间。kdmflush 是设备映射器刷新进程，它处理由于其他地方的加载而延迟的工作。
有几种方法可以改善这种情况 - 获取更多磁盘，获取更好的磁盘，或在控制器上打开写入缓存。
如果打开写入缓存，您还需要一个 BBU。不过，BBU 可能不是板载 SAS1068E 的选项，因此您可能必须获得一个 PCI-e 控制器。
当我使用的 RAID 控制器（我相信是 3ware 9550）未启用写入缓存时，我发现 DRBD 的性能非常糟糕。您的 DRBD 加载将主要是随机 IO，因此写入缓存将对性能产生重大影响。
SAS1068E 非常低端，也可能是造成问题的原因。如果您有更多磁盘或更好的磁盘，我建议您也购买更好的控制器。
通过谷歌快速搜索可以发现表现同样糟糕使用与您所使用的相同型号的 RAID 控制器。
答案2
1 MB/s 听起来很熟悉。我猜你的问题不是 XFS，而是 DRBD 层。如果 DRBD 上的块复制由于某种原因很慢，那么 kdmflush 导致大量 IOWAIT 是完全合理的。这个速度听起来像是两个 DRBD 主机之间的网络连接协商得不好。
再次猜测，但这个速度听起来很像 TCP 连接，而 TCP Windows 无法正常工作。这在网络跟踪上应该非常明显，因为流量看起来像数据包、确认、数据包、确认、数据包、确认，而不是许多数据包和一个确认。
如果 iotop 在安装 NFS 共享的客户端而不是 NFS 服务器本身上运行，则查看该连接以及 DRBD 连接。
答案3
使用超过 10Mbps 的网络进行 DRBD 复制。DRBD 设备上的磁盘 I/O 受限于网络速度（除非您使用 C 以外的协议，如果您想您的数据会损坏且无法使用）。要测试是否是您的网络导致了问题，请断开主网络与辅助网络的连接，您的 I/O 速率可能会立即上升。