問題タブ [dispy]

Centos6.5 サーバーのクラスターで作業しています。ここでは、1 つのヘッド ノードがあり、残りはスレーブ ノードです。ノードは、外部からは見えないローカル ネットワーク 192.168.1.x 上のスイッチを介して接続されています。

ヘッド ノードで Python Dispy を使用して、Python スクリプトをスレーブ ノードに配布しようとしています。スレーブ ノードはすべて dispynode.py を実行しており、クライアント ノードで Dispy プログラムを起動すると、dispynode.py を実行しているスレーブは「192.168.1.1 からの ping を無視します」を返します。その後、ハングします。dispynode を実行しているスレーブがジョブを無視して実行していない理由について何か考えはありますか?

ありがとう！

マルチプロセッシングのドキュメントを読みました。Pythonで、タスクを異なるCPUコアに割り当てることができることがわかりました。次のコードを (最初に) 並列で実行するのが好きです。

今、私は出力を1 2 3、次に1 ....6として取得します。しかし、私は 1 1 2 2 として動作する必要があります。つまり、proc1 と proc2 を並行して (次々にではなく) 実行したいのです。

dispy ノードの setup() メソッドに変数を渡す必要があるので、構成ファイルからロードするデータセットをノードに伝えることができます。そうしないと、データセットごとに特定のスクリプトを作成する必要があり、これは面倒です。

"file.dat"したがって、各ノードがデータを一度インスタンス化できるように、文字列をセットアップに渡したいと思います(大きいため)。

dispy を使用して作業を ec2 インスタンスに分散しようとしています。

私は従った：

ssh トンネル経由のポート転送で dispy を使用する

http://dispy.sourceforge.net/dispy.html#cloud

しかし、それはどこにも行きません。クライアント スクリプトはハングし、サーバー ノードは何も受信しません。

私が今持っているのは：

私のマシンから：

次に、リモートマシンで：

そして私は得る：

私が実行するクライアントマシンで：

何も起こらず、ただ立ち往生しています。ありがとう

私は現在、タスクをさまざまなノードに「分散」するdispy を使用して、10 個の乱数の階乗の計算を実行しています。ただし、計算の 1 つが大きな数の階乗である場合、たとえばfactorial(100)とします。そのタスクに非常に長い時間がかかる場合でも、dispy は単一のノードでのみ実行します。

dispy がこのタスクを分解して他のノードに分散し、それほど時間がかからないようにするにはどうすればよいですか?

これまでに私が思いついたコードは次のとおりです。ここでは、10 個の乱数の階乗が計算され、5 番目の計算は常に factorial(100) です:-

私は、dispy と並列実行で動作するプログラムを使用しています。dispy を使用してタスクを作成し、それを別の CPU に分散して実行しています。

私は標準ライブラリを持っており、ライブラリ (データと接続) を開発しました。

コードは次のようになります。

`

問題は、メインの定義でデータと接続を操作する場合、それがすべて正常に機能する場合、また dispy ライブラリを使用する代わりに関数として計算を呼び出す場合に必要なことです。しかし、私がそのように作業し、計算手順でデータ関数を呼び出すと、データが定義されていないという例外がスローされ、例外なしが出力されます。

何か助けはありますか？ドキュメントはセットアップの使用を示唆していますが、それがどのように機能するかわかりません。

TL;DR:最も基本的なdispyサンプル コードを正しく実行することができません。なぜだめですか？

詳細:

私は Python で分散処理を始めようとしていますが、包括的な機能セットがあるため、 dispyライブラリは興味深いと思いました。

しかし、私は彼らの基本的な正規プログラムの例に従おうとしてきましたが、どこにも行き着きません。

• dispy をインストールしました ( python -m pip install dispy)
• 私は同じサブネットアドレスを持つ別のマシンに行き、実行しましたpython dispynode.py. 次の出力が得られるので、うまくいくようです：

  2016-06-14 10:33:38 dispynode - dispynode バージョン 4.6.14 2016-06-14 10:33:38 asyncoro - epoll
  I/O 通知機能を備えたバージョン 4.1
  10.0.48.54:51348 で 8 CPU

  「quit」または「exit」を入力して dispynode を終了し、「stop」を入力して
  サービスを停止し、「start」を入力してサービスを再起動し、「cpus」を入力して使用する CPU を変更し、その他を入力
  してステータスを取得します。

• クライアント マシンに戻り、 http://dispy.sourceforge.net/_downloads/sample.pyからダウンロードしたサンプル コードを実行します。

これを実行すると ( python sample.py)、ハングします。pdb を介してデバッグすると、最終的に でハングしていることがわかりますdispy/__init__.py(117)__call__()。行は読み取りますself.finish.wait()。finish は単なる python スレッドであり、wait()次にlib/python3.5/threading.py(531)wait(). 待機に達するとハングします。

クライアント マシンで dispynode を実行してみましたが、同じ結果が得られました。クラスターの作成にノードを渡す多くのバリアントを試しました。

cluster.wait()行のコメントを外して実行してみましたが、同じ結果が得られました。

ロギング ( cluster = dispy.JobCluster(compute, loglevel = 10)) を追加すると、クライアント側で次の出力が得られました。

2016-06-14 10:27:01 asyncoro - epoll I/O notifier を使用したバージョン 4.1
2016-06-14 10:27:01 dispy - :51347 の dispy クライアント"_dispy_20160614102701" の障害復旧情報
2016-06-14 10:27:01 dispy - 保留中のジョブ: 0
2016-06-14 10:27:01 dispy - 保留中のジョブ: 1
2016-06-14 10:27:01 dispy - 保留中のジョブ: 2
2016-06-14 10:27:01 dispy - 保留中のジョブ: 3
2016-06-14 10:27:01 dispy - 保留中のジョブ: 4
2016-06-14 10:27:01 dispy - 保留中ジョブ: 5
2016-06-14 10:27:01 dispy - 保留中のジョブ: 6
2016-06-14 10:27:01 dispy - 保留中のジョブ: 7
2016-06-14 10:27:01 dispy - 保留中のジョブ: 8
2016-06-14 10:27:01 dispy - 保留中のジョブ: 9
2016-06-14 10:27:01 dispy - 保留中のジョブ: 10

これは予想外ではないように思えますが、ジョブが実行されていない理由を理解するのには役立ちません。

価値があるのは、_dispy_20160614102701.bak です。

'_cluster', (0, 207)
'compute_1465918021755', (512, 85)

同様に、_dispy_20160614102701.dir:

'_cluster', (0, 207)
'compute_1465918021755', (512, 85)

不安定なバージョンを使用していない限り、私は推測できません。

dispy の依存機能を介して送信される python モジュールのパッケージ名を保持する方法はありますか? これにより、dispy コンテキストの有無にかかわらず、同じ方法でパッケージ/モジュールを使用できます。

簡単な例:

モジュール mypackage.dispytestDepends:

私が望むようにメインモジュール（動作しません）：

書き直さなければならないコードがたくさんあるので、動作しますが、醜いバージョンです。