我们编写了一个应用程序，可以在同一本地卷（RAID1）上同时对多个文件执行小规模（22kB）的写入操作（一个线程代表其他线程对多个位置执行异步排队写入）。99.9
％的写入都是低延迟的，但偶尔（可能每隔一两分钟）我们会得到一两次巨大的延迟写入（我见过10秒及以上），但没有任何真正的解释。
平台：带 NTFS 的 Win2003 Server。
监控：Sysinternals 进程监控器（见下面的链接）和我们自己的应用程序日志记录。
我们尝试了多种方法来解决这个问题，这些方法都是从一些网站上收集到的，例如：
使文件名的第一部分唯一以帮助 8.3 名称生成
将文件写入多个目录
更改英特尔磁盘写入缓存
Windows 文件/打印机共享
尽量减少内存使用
平衡
最大化文件共享的数据吞吐量
最大化网络应用程序的数据吞吐量
系统->高级->性能->高级
NtfsDisableLastAccessUpdate - 使用 fsutil 行为设置 disablelastaccess 1
禁用 8.3 名称生成 - 使用“fsutil behavior set disable8dot3 1”+重新启动
启用大尺寸文件系统缓存
禁用内核代码分页
IO 页面锁定限制
关闭（或打开）索引服务
但似乎没有什么太大的区别。有很多事情我们还没有尝试过，但我们想知道是否有人遇到过同样的问题、原因和解决方案（是否是程序化的）？
我们可以使用 IOMeter 和一个简单的设置来重现这个问题：
启动 IOMeter 并使用断开连接按钮删除‘拓扑’中除第一个工作线程之外的所有线程。
选择工作线程，在“磁盘目标”选项卡中要使用的磁盘旁边的框中打叉，并在“最大磁盘大小”中输入“2000000”（注意：必须至少有 1GB 的可用空间；扇区大小为 512 字节）
接下来创建一个新的访问规范并将其添加到工作线程：
传输请求大小 = 22kB
100% 顺序
访问规范百分比 = 100%
读取/写入百分比 = 100% 写入
将结果显示更新频率更改为 5 秒，测试设置运行时间更改为 20 秒，并将“自动生成的工人数量”设置更改为零。
在拓扑面板中选择工作线程，然后点击“复制工作线程”按钮 59 次，以创建 60 个具有相同设置的线程。
点击“开始”按钮（绿色旗帜）并监视“结果”选项卡。我们的机器上的“最大 I/O 响应时间（毫秒）”始终至少达到 3500。我们的机器并不慢（Xeon 8 核机架服务器，4GB 和板载 RAID）。
我很想知道其他人得到了什么。我们觉得这可能与 NTFS 文件系统有关（我们的文件系统目前有 75% 都是碎片文件），我们将围绕这个原则尝试一些方法。但它也与磁盘性能有关，因为我们在 RAMDisk 上看不到它，而且它在 RAID10 阵列上没有那么严重。
任何帮助都非常感谢。
理查德
右键单击并选择“在新选项卡中打开链接”：
ProcMon 结果
答案1
我现在对这个问题有了更多的了解。
在使用各种硬件的 12 台不同机器上测试了所述 IOMeter 测试后，我将其范围缩小到特定的 RAID 芯片组（使用 RAID1 和 RAID10 的 3 台具有相同芯片组的不同机器表现出这种行为）。所有其他机器的结果至少好一个数量级。
芯片组：英特尔 631xESB/632xESB SATA RAID（又名 ESB2）
请参阅英特尔网站上的这篇文章以了解更多信息，并希望得到英特尔的回复：
Intel 631xESB/632xESB SATA RAID（又名 ESB2）写入速度慢
理查德