0

こんにちは、人工呼吸器/ワーカー/シンク パターンを使用して、ZeroMQ で大きなパケットを送信しようとしています。

ワーカーを追加してみます。そのたびに、シンク プロセスのメモリ使用量が少しずつ増加します。その後、約 6 または 7 個のワーカーで転換点に達し、突然メモリが指数関数的に増加し、次のように終了します。

> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug Assertion failed: (msg_->flags | ZMQ_MSG_MASK) == 0xff (zmq.cpp:211)
> Python(42410,0xaccb8a28) malloc: *** mmap(size=3559424) failed (error
> code=12)

コードは次のとおりです (ワーカー/シンク パターンのみを表示)。

import sys
import resource
import zmq
import time

context = zmq.Context()


if sys.argv[1] == 'worker':
    # Socket to send messages to

    sender = context.socket(zmq.PUSH)
    sender.connect("tcp://localhost:5558")

    while True:
        msg = 'x' * 3559333
        time.sleep(.01)
        sender.send(msg)
else:
    # Socket to receive messages on

    receiver = context.socket(zmq.PULL)
    receiver.bind("tcp://*:5558")
    while True:
        msg = receiver.recv()

        print msg[0:5], len(msg), resource.getrusage(resource.RUSAGE_SELF).ru_maxrss

これは単なるハードウェア リソースの不足ですか? データのバックログ？または、これを回避する方法はありますか？

OSX Mountain Lion を 16 GB メモリで、Python 2.7 を zmq 2.2.0.1 で実行しています。

ありがとう

4

1 に答える 1

2

これは単なるハードウェア リソースの不足ですか?

さて、計算してみましょう。各ワーカーは 10 ミリ秒ごとに 3.3MB を送信しています。または約 300 mb/秒。次にワーカーを追加します。最大 5 ワーカーになるまでに、1 秒あたり約 1.5GB を送信しています。

お使いのマシンのパフォーマンスの限界を発見したと思います。シンク プロセスがすべてのワーカーと同じマシンで実行されている場合、1 秒あたり 1 ～ 2 GB の消費が可能です。データがそれよりも速く入ってくると、キューが空になるよりも速くシンクプロセスに蓄積され、メモリが不足します。

または、これを回避する方法はありますか？

小さいメッセージを送信しますか? あまり頻繁に？:) または、ワーカーとシンク プロセスを別のマシンに配置します。ワーカーがシンクから CPU リソースを盗んでいることに注意してください。これがクアッド コア マシンの場合、シンクと最大 3 つのワーカーを使用すると、OS はおそらくプロセッサ コアのほぼすべてを各プロセスに割り当てます。

4 番目、5 番目、6 番目のワーカーを追加すると、OS はコアの 100% をどのプロセスにも与えることができなくなります。共有を開始する必要があるため、メッセージの速度が速くなってもシンクは遅くなります。これは、メモリ使用量が指数関数的に増加する転換点を説明しています。

うーん、これは興味深い実験を示唆しています。シンク プロセスが非常に高い優先度で実行されるように、Mac を構成できますか? その方が良い結果が得られるかもしれません。私はこれを自分で試したことはありませんが、アイデアについては次のリンクを参照してください... https://discussions.apple.com/thread/1491812?start=0&tstart=0

于 2012-12-04T16:56:44.297 に答える