2016-08-25 14 views
1

Iは、(すべてのノードがない NFSとg2.2xlarge Amazon EC2インスタンスである)host47host0からなる48ノードのクラスタを作成しました。 https://ipyparallel.readthedocs.io/en/latest/process.htmlによると、コントローラhost0とエンジン47台がhost1host47に作成されています。私はStarClusterプロジェクトからsshipyparallelクラスタの構成のほとんどを複製しました(しかし、私が言ったように、NFSなし)。 クラスタが正常に動作しているように見えますが、モジュールの読み込みには時間がかかることがあります。それが終了するまで、例えば 、クラスタ上Ipyparallelモジュール負荷非常に遅い

import ipyparallel as ipp 
client = ipp.Client('/path/to/ipcontroller-client.json',sshkey='mykey') 
view = client[:] 
view.block=True 

with view.sync_imports(): 
    import time 
    import numpy 
    from keras.models import Sequential 
    from keras.layers import Dense, Dropout 
    from keras.regularizers import l1 
    from keras.optimizers import SGD 
    from subprocess import check_output 

は30分以上かかります。 block=Falseview.wait()に変更してもこれは変わりません。また、view.execute("import time; import numpy; import keras.models ...")を使用しても役に立ちません。私は、kerasモジュールのロードがやや遅いことを知っていますが、ローカルマシンでは通常1分以内で完了します。私はpicklejson(un)パッキングの両方を試みました。 同じクラスタを別の計算に使用すると、モジュールの読み込みが正常に機能することに言及する必要があります。私はロードされたモジュールがどこかにキャッシュされていると思います。しかし、インスタンスを終了して新しいインスタンスを作成し、新しいipyparallelクラスタを構成すると、モジュール読み込みで同じ問題が発生します。

ipcontrollerログを見ると、私はsync_imports

2016-08-25 12:12:02.310 [IPControllerApp] queue::client '\x00"_\x0b\x0b' 
submitted request '46244cf0-ad0a-4748-a84c-8d3d69d8252c' to 0 

に対応する要求のほとんどは、数分以内に完了し得ることを見つけることができます。しかし、それらのいくつかは約30分かかります。 ipcontrollerログから派生した次のヒストグラムcomplete_time - submit_timeを参照してください。

enter image description here

私はつい最近のpythonを使用し始めていると私はこの問題は、ここで何ができるかわかりません。完全な時間と提出時間との間の最大時間差は、クラスタ・サイズとともに増加すると思われる。 可能性のある問題への指針は大歓迎です。

はところで: - 時々少し遅くなることがあります私は、Python 2.7.6と5.1.1 Ipyparallel

答えて

0

を使用しています今の私の最高の推測では、問題がEBSボリュームの初期化によって引き起こされたということです。 クラスタインスタンスは常にイメージから開始され、計算が完了した直後に終了しました。スナップショットから作成されたEBSボリュームはS3からデータを取得する必要があります。 AWS EBS documentation

新しいEBSボリュームが最大のパフォーマンス彼ら が利用可能であり、(以前は 前温暖化として知られている)の初期化を必要としない瞬間を受け取る参照してください。ただし、スナップショットから復元されたボリュームのストレージブロックは、ブロックにアクセスする前に初期化(ボリュームに書き込まれたAmazon S3および からプルダウン)する必要があります。この 予備アクションには時間がかかり、最初に各ブロックにアクセスするときにI/O操作の待ち時間が大幅に増加する可能性があります。 ほとんどのアプリケーションでは、このコストを ボリュームの有効期間にわたって償却することは容認されます。データが に一度アクセスされると、パフォーマンスが復元されます。

関連する問題