How to speed up communication with subprocesses

后端 未结 5 845
佛祖请我去吃肉
佛祖请我去吃肉 2021-01-02 02:11

I am using Python 2 subprocess with threading threads to take standard input, process it with binaries A, B, and C<

5条回答
  •  既然无缘
    2021-01-02 02:37

    TL;DR If your program runs slower than expected, it is probably due to the details of what the intermediate functions do rather than due to IPC or threading. Test with mock functions and processes (as simple as possible) to isolate just the overhead of passing data to/from subprocesses. In a benchmark based closely on your code (below), the performance when passing data to/from subprocesses seems to be roughly equivalent to using shell pipes directly; python is not particularly slow at this task.

    What is going on with the original code

    The general form of the original code is:

    def produceB(from_stream, to_stream):
        while True:
            buf = from_stream.read()
            processed_buf = do_expensive_calculation(buf)
            to_stream.write(processed_buf)
    

    Here the calculation between read and write takes about 2/3 of the total cpu time of all processes (main and sub) combined - this is cpu time, not wall clock time btw.

    I think that this prevents the I/O from running at full speed. Reads and writes and the calculation each need to have their own thread, with queues to provide buffering between the read and calculation and between the calculation and write (since the amount of buffering that pipes provide is insufficient, I believe).

    I show below that if there is no processing in between read and write (or equivalently: if the intermediate processing is done in separate thread), then the throughput from threads + subprocess is very high. It is also possible to have separate threads for reads and writes; this adds a bit of overhead but makes writes not block reads and vice versa. Three threads (read, write and processing) is even better, then neither step blocks the others (within the limits of the queue sizes, of course).

    Some benchmarks

    All benchmarking below is on python 2.7.6 on Ubuntu 14.04LTS 64bit (Intel i7, Ivy Bridge, quad core). The test is to transfer approx 1GB of data in 4KB blocks between two dd processes, and pass the data through python as an intermediary. The dd processes use medium sized (4KB) blocks; typical text I/O would be smaller (unless it is cleverly buffered by the interpreter, etc), typical binary I/O would of course be much larger. I have one example based on exactly how you did this, and one example based on an alternate approach I had tried some time ago (which turns out to be slower). By the way, thanks for posting this question, it is useful.

    Threads and blocking I/O

    First, let's convert the original code in the question into a slightly simpler self-contained example. This is just two processes communicating with a thread that pumps data from one to the other, doing blocking reads and writes.

    import subprocess, threading
    
    A_process = subprocess.Popen(["dd", "if=/dev/zero", "bs=4k", "count=244140"], stdout=subprocess.PIPE)
    B_process = subprocess.Popen(["dd", "of=/dev/null", "bs=4k"], stdin=subprocess.PIPE)
    
    def convert_A_to_B(src, dst):
        read_size = 8*1024
        while True:
            try:
                buf = src.read(read_size)
                if len(buf) == 0:  # This is a bit hacky, but seems to reliably happen when the src is closed
                    break
                dst.write(buf)
            except ValueError as e: # Reading or writing on a closed fd causes ValueError, not IOError
                print str(e)
                break
    
    convert_A_to_B_thread = threading.Thread(target=convert_A_to_B, args=(A_process.stdout, B_process.stdin))
    
    convert_A_to_B_thread.start()
    
    # Here, watch out for the exact sequence to clean things up
    convert_A_to_B_thread.join()
    
    A_process.wait()
    B_process.stdin.close()
    B_process.wait()
    

    Results:

    244140+0 records in
    244140+0 records out
    999997440 bytes (1.0 GB) copied, 0.638977 s, 1.6 GB/s
    244140+0 records in
    244140+0 records out
    999997440 bytes (1.0 GB) copied, 0.635499 s, 1.6 GB/s
    
    real    0m0.678s
    user    0m0.657s
    sys 0m1.273s
    

    Not bad! It turns out that the ideal read size in this case is roughly 8k-16KB, much smaller and much larger sizes are somewhat slower. This is probably related to the 4KB block size we asked dd to use.

    Select and non-blocking I/O

    When I was looking at this type of problem before, I headed in the direction of using select(), nonblocking I/O, and a single thread. An example of that is in my question here: How to read and write from subprocesses asynchronously?. That was for reading from two processes in parallel, which I have extended below to reading from one process and writing to another. The nonblocking writes are limited to PIPE_BUF or less in size, which is 4KB on my system; for simplicity, the reads are also 4KB although they could be any size. This has a few weird corner cases (and inexplicable hangs, depending on the details) but in the form below it works reliably.

    import subprocess, select, fcntl, os, sys
    
    p1 = subprocess.Popen(["dd", "if=/dev/zero", "bs=4k", "count=244140"], stdout=subprocess.PIPE)
    p2 = subprocess.Popen(["dd", "of=/dev/null", "bs=4k"], stdin=subprocess.PIPE)
    
    def make_nonblocking(fd):
        flags = fcntl.fcntl(fd, fcntl.F_GETFL)
        fcntl.fcntl(fd, fcntl.F_SETFL, flags | os.O_NONBLOCK)
    
    make_nonblocking(p1.stdout)
    make_nonblocking(p2.stdin)
    
    print "PIPE_BUF = %d" % (select.PIPE_BUF)
    
    read_size = select.PIPE_BUF
    max_buf_len = 1 # For reasons which I have not debugged completely, this hangs sometimes when set > 1
    bufs = []
    
    while True:
        inputready, outputready, exceptready = select.select([ p1.stdout.fileno() ],[ p2.stdin.fileno() ],[]) 
    
        for fd in inputready: 
            if fd == p1.stdout.fileno():
                if len(bufs) < max_buf_len:
                    data = p1.stdout.read(read_size)
                    bufs.append(data)
        for fd in outputready: 
            if fd == p2.stdin.fileno() and len(bufs) > 0:
                data = bufs.pop(0)
                p2.stdin.write(data)
    
        p1.poll()
        # If the first process is done and there is nothing more to write out
        if p1.returncode != None and len(bufs) == 0:
            # Again cleanup is tricky.  We expect the second process to finish soon after its input is closed
            p2.stdin.close()
            p2.wait()
            p1.wait()
            break
    

    Results:

    PIPE_BUF = 4096
    244140+0 records in
    244140+0 records out
    999997440 bytes (1.0 GB) copied, 3.13722 s, 319 MB/s
    244133+0 records in
    244133+0 records out
    999968768 bytes (1.0 GB) copied, 3.13599 s, 319 MB/s
    
    real    0m3.167s
    user    0m2.719s
    sys 0m2.373s
    

    This is however significantly slower than the version above (even if the read/write size is made 4KB in both for an apples-to-apples comparison). I'm not sure why.

    P.S. Late addition: It appears that it is ok to ignore or exceed PIPE_BUF. This causes an IOError exception to be thrown much of the time from p2.stdin.write() (errno=11, temporarily unavailable), presumably when there is enough room in the pipe to write something, but less than the full size we are requesting. The same code above with read_size = 64*1024, and with that exception caught and ignored, runs at 1.4GB/s.

    Pipe directly

    Just as a baseline, how fast is it to run this using the shell version of pipes (in subprocess)? Let's have a look:

    import subprocess
    subprocess.call("dd if=/dev/zero bs=4k count=244140 | dd of=/dev/null bs=4k", shell=True)
    

    Results:

    244140+0 records in
    244140+0 records out
    244140+0 records in
    244140+0 records out
    999997440 bytes (1.0 GB) copied, 0.425261 s, 2.4 GB/s
    999997440 bytes (1.0 GB) copied, 0.423687 s, 2.4 GB/s
    
    real    0m0.466s
    user    0m0.300s
    sys 0m0.590s
    

    This is notably faster than the threaded python example. However, this is just one copy, while the threaded python version is doing two (into and out of python). Modifying the command to "dd if=/dev/zero bs=4k count=244140 | dd bs=4k | dd of=/dev/null bs=4k" bring the performance to 1.6GB, in line with the python example.

    How to run a comparison in a complete system

    Some additional thoughts on how to run a comparison in a complete system. Again for simplicity this is just two processes, and both scripts have the exact same convert_A_to_B() function.

    Script 1: Pass data in python, as above

    A_process = subprocess.Popen(["A", ...
    B_process = subprocess.Popen(["B", ...
    convert_A_to_B_thread = threading.Thread(target=convert_A_to_B, ...
    

    Script 2: Comparison script, pass data in shell

    convert_A_to_B(sys.stdin, sys.stdout)
    

    run this in the shell with: A | python script_2.py | B

    This allows an apples-to-apples comparison in a complete system, without using mock functions/processes.

    How does block read size affect the results

    For this test, the code from the first (threaded) example above is used, and both dd and the python script are set to use the same block size reads/writes.

    | Block size | Throughput |
    |------------|------------|
    | 1KB | 249MB/s |
    | 2KB | 416MB/s |
    | 4KB | 552MB/s |
    | 8KB | 1.4GB/s |
    | 16KB | 1.8GB/s |
    | 32KB | 2.9GB/s |
    | 64KB | 3.0GB/s |
    | 128KB | 1.0GB/s |
    | 256KB | 600MB/s |
    

    In theory there should be better performance with larger buffers (perhaps up to cache effects) but in practice Linux pipes slow down with very large buffers, even when using pure shell pipes.

提交回复
热议问题