使用OpenMP读取文件反而更慢的原因是什么？

问题背景 #

我有一个存储了4亿个连续整数的大文件，需要按指定偏移量和大小读取多个数据块。尝试用OpenMP多线程加速读取，却发现速度反而慢了近3倍：OpenMP读取耗时约0.93秒，单线程读取仅约0.37秒。

硬件环境为NVMe SSD、i9-13900KF CPU，系统是Ubuntu 22.04。疑问：为何OpenMP性能差距如此大？是线程切换开销导致的吗？如果文件达到TB级，情况会有不同吗？

演示代码 #

#include <fcntl.h>
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <memory>

const uint32_t N = 400'000'000;

int main() {
    const char *const filename = "big_file.bin";

    int wfd = open(filename, O_WRONLY | O_CREAT, 0644);
    uint32_t *nums = new uint32_t[N];
    for (uint32_t i = 0; i < N; ++i) {
        nums[i] = i;
    }
    write(wfd, nums, sizeof(uint32_t) * N);
    close(wfd);


    int fd = open(filename, O_RDONLY);

    uint32_t n_shards = 16;
    uint32_t *offsets = new uint32_t[n_shards];
    uint32_t *sizes = new uint32_t[n_shards];
    uint32_t chunk_size = N / n_shards;
    for (uint32_t i = 0; i < n_shards; ++i) {
        offsets[i] = i * chunk_size;
        sizes[i] = chunk_size;
    }
    sizes[n_shards - 1] = N - (n_shards - 1) * chunk_size;

    // only to demonstrate the offsets may not be in order
    srand(0);
    for (uint32_t i = 0; i < n_shards; ++i) {
        uint32_t j = rand() % n_shards;
        std::swap(offsets[i], offsets[j]);
        std::swap(sizes[i], sizes[j]);
    }

    uint32_t *nums_omp = new uint32_t[N];
    clock_t start = clock();
    #pragma omp parallel for num_threads(16)
    for (uint32_t i = 0; i < n_shards; ++i) {
        pread(fd, nums_omp + offsets[i], sizes[i] * sizeof(uint32_t),
              offsets[i] * sizeof(uint32_t));
    }
    clock_t end = clock();
    printf("time: %fs\n", (double)(end - start) / CLOCKS_PER_SEC);

    close(fd);
}

核心原因分析 #

• 磁盘带宽物理限制：你的文件大小为1.6GB（4亿×4字节），单线程读取已经接近NVMe SSD的顺序带宽上限（高端型号通常在7GB/s左右）。多线程无法突破硬件的物理带宽瓶颈，反而会引入额外开销。
• 随机IO的额外延迟：代码中打乱了偏移量顺序，多线程执行的是随机读取操作。NVMe的随机IO性能虽优于SATA，但随机寻址延迟远高于顺序IO，多个线程同时发起随机请求会让磁盘控制器频繁切换寻址，大幅增加总延迟。而单线程读取时，Linux的IO调度器（如mq-deadline）会自动重新排序请求，转换成高效的顺序IO。
• 系统调用与同步开销：每个pread都是系统调用，多线程下频繁的系统调用会带来上下文切换开销；同时多个线程竞争文件描述符的内核锁，也会产生同步损耗。
• 计时方式偏差：clock()测量的是CPU总时间（所有线程的CPU时间累加），而非实际墙钟时间。多线程下CPU时间会被放大，导致你看到的耗时差距比实际墙钟时间更大。应改用clock_gettime(CLOCK_MONOTONIC)测量真实耗时。

优化方案 #

1. 优先顺序化读取：如果业务允许，先将偏移量按磁盘地址排序，让读取操作尽可能顺序化——无论是单线程还是多线程，顺序IO的性能都远高于随机IO。
2. 合并IO请求：在多线程处理前，将相邻的偏移量合并成大的读取请求，减少系统调用次数和磁盘寻址次数。
3. 合理控制线程数：磁盘IO密集型任务的最优线程数远小于CPU核心数（通常等于磁盘队列深度，NVMe一般为32-64，但实际测试4-8线程即可），过多线程只会增加不必要的开销。
4. 改用异步IO：使用io_uring或aio等异步IO接口，可更高效地利用磁盘带宽，避免多线程上下文切换的开销。

TB级文件的情况 #

如果文件是TB级且数据分布随机，单线程读取可能无法充分利用磁盘带宽（因为磁盘需要频繁寻址，单线程会持续等待IO完成），此时多线程或异步IO可以通过重叠多个IO请求提升吞吐量，但需满足：

• 使用随机IO性能较强的企业级NVMe SSD
• 合理控制线程数/IO队列深度，避免过度竞争
• 配置合适的IO调度器（比如关闭Linux的IO调度器，让NVMe控制器自行管理队列）

内容的提问来源于stack exchange，提问作者Nicolás Tsu