Windows IOCP+FILE_FLAG_NO_BUFFERING下4K随机IO性能暴跌问题排查

问题背景 #

我正在开发Windows平台LLM推理异步IO框架，配置8个计算线程，核心流程如下：

• 计算任务发现下一阶段所需神经元不在内存池时，将任务闭包放入IO队列；
• IO线程取出闭包后，通过无锁LRU从内存池分配缓冲区，生成数百个含缓冲区、大小、偏移的IO闭包并放入IO执行队列；
• IO线程从执行队列取任务完成IO、修改原子变量，待所有IO完成后将任务放回计算队列继续执行。

微基准测试中，该框架在SSD上可达2.6GB/s吞吐量，与磁盘实际性能匹配；但移植到LLM推理流水线场景后，性能仅为50MB/s，两者目标文件、线程数、队列深度及代码完全一致。

已完成排查 #

• 将IO线程数减至1，性能仍为50MB/s，排除IO线程与计算线程冲突问题；
• 队列实现采用锁和条件变量，微基准与实际场景代码一致；
• 移除FILE_FLAG_NO_BUFFERING后性能达1100MB/s，排除IO闭包队列瓶颈。

优化建议 #

1. 严格满足FILE_FLAG_NO_BUFFERING的对齐要求 #

Windows下FILE_FLAG_NO_BUFFERING有强制对齐规则，若未满足会触发系统内部额外拷贝或重试，直接拉低性能：

• 用GetDiskFreeSpace获取目标磁盘的扇区大小，确保IO请求的偏移量、长度均为扇区大小的整数倍；
• 内存池分配缓冲区时，使用VirtualAlloc（而非malloc/new），指定对齐参数为扇区大小，保证缓冲区地址对齐。

2. 合并分散小IO请求 #

LLM场景中神经元IO请求多为小粒度分散请求，而微基准测试可能是连续大IO。FILE_FLAG_NO_BUFFERING下系统缓存无法合并请求，需手动处理：

• 对同一文件的相邻偏移请求进行合并，生成大尺寸IO请求；
• 按文件偏移对IO闭包排序，减少磁盘寻道开销。

3. 优化原子变量的竞争开销 #

每个计算任务对应数百个IO闭包，单个IO完成即修改全局原子变量会引发频繁缓存一致性竞争：

• 改用本地计数器+批量更新：每个IO线程维护本地计数，累计到阈值后再更新全局原子变量；
• 替换为轻量原子操作：使用InterlockedIncrement等Windows原生原子函数，或std::atomic_flag，减少不必要的内存屏障。

4. 提升内存池的缓存局部性 #

无锁LRU的缓冲区分配可能破坏CPU缓存局部性，导致缓存命中率下降：

• 调整LRU策略，优先复用最近访问的缓冲区，减少缓存失效；
• 按LLM的神经元分组（如层、注意力头）划分内存池分区，让同一组的IO请求复用同一分区的缓冲区。

5. 切换至IOCP模型处理异步IO #

若当前使用普通重叠IO+线程池，大量小IO场景下上下文切换开销极高：

• 改用IO完成端口（IOCP），将所有IO请求投递到IOCP，由系统调度线程处理完成通知；
• 确保CreateFile时同时指定FILE_FLAG_OVERLAPPED和FILE_FLAG_NO_BUFFERING，正确初始化OVERLAPPED结构。

6. 验证实际IO队列深度 #

虽配置队列深度一致，但LLM场景的请求分布可能导致有效队列深度不足：

• 用Windows性能监视器（PerfMon）查看PhysicalDisk指标：Current Disk Queue Length（当前队列长度）、Avg. Disk sec/Read（平均读取延迟），确认磁盘是否处于饱和状态；
• 调整IO执行队列深度，保证磁盘控制器持续忙碌，避免空闲。

内容的提问来源于stack exchange，提问作者Yy Lee