在python中使用多线程进行I / O减速

Question

我有一个python脚本，它适用于以下方案：读取一个大文件（例如，电影） - 将选定的信息组合成一些小的临时文件 - 在子进程中生成a {{1应用程序执行文件处理/计算（单独为每个文件） - 读取应用程序输出。为了加快脚本，我使用了多处理。但是，它有一个主要缺点：每个进程都必须在RAM中维护大输入文件的整个副本，因此我只能运行几个进程，因为我的内存不足。因此，我决定尝试多线程（或多处理和多线程的某种组合），因为线程共享地址空间。由于C++部分大部分时间都在使用文件python或等待I/O应用程序完成，因此我认为C++一定不是问题。然而，主要由于GIL部分，我观察到了急剧减速，而不是表现上的一些增长。

我用以下代码（保存为I/O）来说明问题：

test.py

当我使用不同数量的线程运行它时，我得到了这个：

import sys, threading, tempfile, time

nthreads = int(sys.argv[1])

class IOThread (threading.Thread):
    def __init__(self, thread_id, obj):
        threading.Thread.__init__(self)
        self.thread_id = thread_id
        self.obj = obj
    def run(self):
        run_io(self.thread_id, self.obj)

def gen_object(nlines):
    obj = []
    for i in range(nlines):
        obj.append(str(i) + '\n')
    return obj

def run_io(thread_id, obj):
    ntasks = 100 // nthreads + (1 if thread_id < 100 % nthreads else 0)
    for i in range(ntasks):
        tmpfile = tempfile.NamedTemporaryFile('w+')
        with open(tmpfile.name, 'w') as ofile:
            for elem in obj:
                ofile.write(elem)
        with open(tmpfile.name, 'r') as ifile:
            content = ifile.readlines()
        tmpfile.close()

obj = gen_object(100000)
starttime = time.time()
threads = []
for thread_id in range(nthreads):
    threads.append(IOThread(thread_id, obj))
    threads[thread_id].start()
for thread in threads:
    thread.join()
runtime = time.time() - starttime
print('Runtime: {:.2f} s'.format(runtime))

有人可以向我解释结果，并提供一些建议，如何使用多线程有效地并行化$ python3 test.py 1 Runtime: 2.84 s $ python3 test.py 1 Runtime: 2.77 s $ python3 test.py 1 Runtime: 3.34 s $ python3 test.py 2 Runtime: 6.54 s $ python3 test.py 2 Runtime: 6.76 s $ python3 test.py 2 Runtime: 6.33 s ？

修改

减速不是由于硬盘性能，因为：

1）无论如何文件都会缓存到RAM中

2）多处理（不是多线程）的相同操作确实变得更快（几乎与CPU数量相关）

Answer 1

当我深入研究这个问题时，我为4种不同的并行化方法制作了比较基准，其中3种使用python，1种使用java（测试的目的不是为了比较不同语言之间的I / O机制，但要看多线程是否可以提升I / O操作）。测试在Ubuntu 14.04.3上进行，所有文件都放在RAM磁盘上。

虽然数据非常嘈杂，但明显的趋势是显而易见的（参见图表;每个条形n = 5，误差条代表SD）：python多线程无法提升I / O性能。最可能的原因是GIL，因此无法绕过它。

Answer 2

我认为你的绩效指标不是谎言：你要求你的硬盘同时做很多事情。关闭文件时读取，写入，fsync，以及同时在多个文件上读取。它会触发大量硬件物理操作。你同时写的文件越多，你得到的争论就越多。

所以CPU正在等待磁盘操作完成......

此外，也许您没有SSD硬盘，因此同步实际上意味着一些物理移动。

编辑：这可能是GIL问题。当你在run_io中的obj中迭代elem时，你会在每次写入之间执行python代码。 ofile.write可能会释放GIL，因此IO不会阻塞其他线程，但每次迭代都会释放/获取锁。所以也许你的写作并不真正“同时”运行。

EDIT2：测试您可以尝试替换的假设：

for elem in obj:
    ofile.write(elem)

使用：

ofile.write("".join(obj))

并查看perf是否变得更好