マルチプロセッシングでメモリ使用量が着実に増えています.Pool.imap_unordered

Question

大きなファイルを処理するにつれて私のプログラムがますます多くのメモリを使用していることに気付きました。しかし、一度に1行しか処理していないので、なぜより多くのメモリを使用し続けるのかわかりませんでした。

1. ロードのデータを一度に1行：
   は、掘削の多くの後、私はプログラムは三つの部分を持っていることを実感しました。
2. multiprocessing.Poolの各行をimap_unordered()を使用して処理します。
3. 各行を1つのスレッドで処理します。

ステップ1および2がステップ3より速い場合、プールワーカーの結果がキューに入れられ、メモリが消費されます。

手順2でプールにフィードしたデータを絞り込むことで、手順3でコンシューマーより先に進まないのはなぜですか？

これはanother multiprocessing questionと似ていますが、遅れがどこにあるのかはわかりません。ここで

は、問題を示し小さな例です：それが実行されると

import logging 
import os 
import multiprocessing 
from time import sleep 

logging.basicConfig(level=logging.INFO, 
        format='%(asctime)s:%(process)d:%(thread)d:%(message)s') 
logger = logging.getLogger() 

def process_step1(): 
    data = 'a' * 100000 
    for i in xrange(10000): 
     sleep(.001) # Faster than step 3. 
     yield data 
     if i % 1000 == 0: 
      logger.info('Producing %d.', i) 
    logger.info('Finished producing.') 


def process_step2(data): 
    return data.upper() 


def process_step3(up_data): 
    assert up_data == 'A' * 100000 
    sleep(.005) # Slower than step 1. 


def main(): 
    pool = multiprocessing.Pool(processes=10) 
    logger.info('Starting.') 
    loader = process_step1() 
    processed = pool.imap_unordered(process_step2, loader) 
    for i, up_data in enumerate(processed): 
     process_step3(up_data) 
     if i % 500 == 0: 
      logger.info('Consuming %d, using %0.1f MB.', i, get_memory()) 
    logger.info('Done.') 


def get_memory(): 
    """ Look up the memory usage, return in MB. """ 
    proc_file = '/proc/{}/status'.format(os.getpid()) 
    scales = {'KB': 1024.0, 'MB': 1024.0 * 1024.0} 
    with open(proc_file, 'rU') as f: 
     for line in f: 
      if 'VmSize:' in line: 
       fields = line.split() 
       size = int(fields[1]) 
       scale = fields[2].upper() 
       return size*scales[scale]/scales['MB'] 
    return 0.0 # Unknown 

main() 

、私は、ステップ1が終了するまでメモリの使用が着実に増加を参照してください。それ以降十分に長く走らせてしまうと、メモリ使用量が減少し始めるでしょう。

2016-12-01 15:37:50,859:6414:139712380557056:Starting. 
2016-12-01 15:37:50,861:6414:139712266237696:Producing 0. 
2016-12-01 15:37:50,868:6414:139712380557056:Consuming 0, using 255.0 MB. 
2016-12-01 15:37:52,054:6414:139712266237696:Producing 1000. 
2016-12-01 15:37:53,244:6414:139712266237696:Producing 2000. 
2016-12-01 15:37:53,421:6414:139712380557056:Consuming 500, using 383.0 MB. 
2016-12-01 15:37:54,446:6414:139712266237696:Producing 3000. 
2016-12-01 15:37:55,635:6414:139712266237696:Producing 4000. 
2016-12-01 15:37:55,976:6414:139712380557056:Consuming 1000, using 511.2 MB. 
2016-12-01 15:37:56,831:6414:139712266237696:Producing 5000. 
2016-12-01 15:37:58,019:6414:139712266237696:Producing 6000. 
2016-12-01 15:37:58,529:6414:139712380557056:Consuming 1500, using 703.2 MB. 
2016-12-01 15:37:59,209:6414:139712266237696:Producing 7000. 
2016-12-01 15:38:00,406:6414:139712266237696:Producing 8000. 
2016-12-01 15:38:01,084:6414:139712380557056:Consuming 2000, using 831.5 MB. 
2016-12-01 15:38:01,602:6414:139712266237696:Producing 9000. 
2016-12-01 15:38:02,802:6414:139712266237696:Finished producing. 
2016-12-01 15:38:03,640:6414:139712380557056:Consuming 2500, using 959.5 MB. 
2016-12-01 15:38:06,199:6414:139712380557056:Consuming 3000, using 959.5 MB. 

Answer 1

Pool.imap_unordered()は、ステップ1で生成された入力シーケンスを反復するために、新しいスレッドを起動するように思えるので、我々は​​は、1つを制限するために設計されてステップ3を実行しているメインスレッドからそのスレッドを絞る必要があります私たちが各行を生成する前にacquire()と呼び、各行を消費するときはrelease()と呼びます。セマフォを100などの任意の値で開始すると、ブロックして消費者が追いつくのを待つ前に100行のバッファが生成されます。

ここで、プロデューサがコンシューマよりもはるかに先に進まないため、メモリ使用量は安定しています。

2016-12-01 15:52:13,833:6695:140124578850560:Starting. 
2016-12-01 15:52:13,835:6695:140124535109376:Producing 0. 
2016-12-01 15:52:13,841:6695:140124578850560:Consuming 0, using 255.0 MB. 
2016-12-01 15:52:16,424:6695:140124578850560:Consuming 500, using 255.0 MB. 
2016-12-01 15:52:18,498:6695:140124535109376:Producing 1000. 
2016-12-01 15:52:19,015:6695:140124578850560:Consuming 1000, using 255.0 MB. 
2016-12-01 15:52:21,602:6695:140124578850560:Consuming 1500, using 255.0 MB. 
2016-12-01 15:52:23,675:6695:140124535109376:Producing 2000. 
2016-12-01 15:52:24,192:6695:140124578850560:Consuming 2000, using 255.0 MB. 
2016-12-01 15:52:26,776:6695:140124578850560:Consuming 2500, using 255.0 MB. 
2016-12-01 15:52:28,846:6695:140124535109376:Producing 3000. 
2016-12-01 15:52:29,362:6695:140124578850560:Consuming 3000, using 255.0 MB. 
2016-12-01 15:52:31,951:6695:140124578850560:Consuming 3500, using 255.0 MB. 
2016-12-01 15:52:34,022:6695:140124535109376:Producing 4000. 
2016-12-01 15:52:34,538:6695:140124578850560:Consuming 4000, using 255.0 MB. 
2016-12-01 15:52:37,128:6695:140124578850560:Consuming 4500, using 255.0 MB. 
2016-12-01 15:52:39,193:6695:140124535109376:Producing 5000. 
2016-12-01 15:52:39,704:6695:140124578850560:Consuming 5000, using 255.0 MB. 
2016-12-01 15:52:42,291:6695:140124578850560:Consuming 5500, using 255.0 MB. 
2016-12-01 15:52:44,361:6695:140124535109376:Producing 6000. 
2016-12-01 15:52:44,878:6695:140124578850560:Consuming 6000, using 255.0 MB. 
2016-12-01 15:52:47,465:6695:140124578850560:Consuming 6500, using 255.0 MB.