解决 I/O 绑定问题的最佳方法？答案

【问题标题】：Best Approach for I/O Bound Problems?解决 I/O 绑定问题的最佳方法？
【发布时间】：2018-09-28 01:55:31
【问题描述】：

我目前正在一个 HPC 集群上运行一个代码，该代码在磁盘（同一目录）上短时间写入几个 16 MB 的文件，然后将其删除。它们被写入磁盘，然后按顺序删除。但是，I/O 操作的总数超过了 20,000 * 12,000 次。

我正在使用 python2.7 中的 joblib 模块来利用在多个内核上运行我的代码。它基本上是一个嵌套循环问题，外循环由 joblib 并行化，而内循环在函数中按顺序运行。总共是一个 (20,000 * 12,000 循环。)

我的代码的基本框架如下。

from joblib import Parallel, delayed
import subprocess

def f(a,b,c,d):
    cmds = 'path/to/a/bash_script_on_disk with arguments from a,b > \
    save_file_to_disk'
    subprocess.check_output(cmds,shell=True)

    cmds1 = 'path/to/a/second_bash_script_on_disk  > \
    save_file_to_disk'
    subprocess.check_output(cmds1,shell=True)

    #The structure above is repeated several times. 
    #However I do delete the files as soon as I can using:

    cmds2 = 'rm -rf files'
    subprocess.check_output(cmds2,shell=True)

    #This is followed by the second/inner loop.

    for i in range(12000):
        #Do some computation, create and delete files in each 
        #iteration.

if __name__ == '__main__':
    num_cores = 48
    Parallel(n_jobs=num_cores)(delayed(f)(a,b,c,d) for i in range(20,000)) 

    #range(20,000) is batched by a wrapper script that sends no more \
    #than 48 jobs per node.(Max.cores available)

这段代码非常慢，瓶颈是 I/O 时间。这是将文件临时写入 /dev/shm/ 的好用例吗？我在 /dev/shm/ 上有 34GB 的可用空间作为 tmpfs。

我已经测试过的东西：

我尝试在具有 8 个内核的笔记本电脑上以较小的规模设置相同的代码。但是，写入 /dev/shm/ 比写入磁盘慢。

旁注：（内部循环也可以并行化，但是，我可用的核心数量远少于 20,000，这就是我坚持这种配置的原因。如果有更好的方法，请告诉我这个。）

【问题讨论】：

多核不应改进 I/O 绑定任务，您可能希望（高度依赖于您的工作负载）在 I/O 之前使用写入磁盘之前的快速压缩算法，如 C-blosc。但是，对它进行基准测试，它很可能不适用于您的用例。
另一个技巧可能是为文件预分配存储空间并确保它使用顺序文件存储，但这可能只对某些 POSIX 操作系统有帮助，对 Windows 和某些 POSIX 操作系统没有帮助（posix_fallocate 是允许写入 0 以保证存储，这在某些情况下可以有效地使写入文件所需的时间增加一倍）。
您能否扩展文件周围的数据流？例如，有什么读取它们吗？

标签： python linux python-2.7 subprocess joblib

【解决方案1】：

首先，不要谈论总I/O操作，那是没有意义的。相反，请谈论 IOPS 和自始至终。

其次，写入 /dev/shm/ 几乎不可能比写入磁盘慢。请提供更多信息。可以使用fio测试写性能，示例命令：sudo fio --name fio_test_file --rw=read --direct=1 --bs=4k --size=50M --numjobs=16 --group_reporting，我的测试结果是：bw=428901KB/s, iops=107225。

第三，你真的写了太多文件，你应该考虑一下你的结构。

【讨论】：

请注意，此答案中给出的 fio 行没有 direct=1，因此内核的缓冲区缓存有可能满足所有 I/O 的要求，这可能是不希望的并且可能会失真结果……

【解决方案2】：

这取决于您的临时数据大小。

如果您的内存比用于数据的内存多得多，那么是的 - shm 将是一个好地方。如果您要编写的内容几乎与可用的一样多，那么您很可能会开始交换——这会破坏一切的性能。

如果您可以将数据放入内存中，那么根据定义，tmpfs 将始终比写入物理磁盘快。如果不是，那么还有更多因素会影响您的环境。在这种情况下，在分析器下运行您的代码将是一个好主意。

【讨论】：